linux, branch v2.6.13.2

Linux 2.6.13.2

2005-09-17T01:02:12Z

[PATCH] USB: ftdi_sio: custom baud rate fix

2005-09-17T01:01:59Z

ftdi_sio: I messed up the baud_base for custom baud rate support in 2.6.13. The attached one-liner patch fixes it. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright

[PATCH] Fix up more strange byte writes to the PCI_ROM_ADDRESS config word

2005-09-17T01:01:58Z

It's a dword thing, and the value we write is a dword. Doing a byte write to it is nonsensical, and writes only the low byte, which only contains the enable bit. So we enable a nonsensical address (usually zero), which causes the controller no end of problems. Trivial fix, but nasty to find. Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] Fix MPOL_F_VERIFY

2005-09-17T01:01:58Z

There was a pretty bad bug in there that the code would always check the full VMA, not the range the user requested. When the VMA to be checked was merged with the previous VMA this could lead to spurious failures. Signed-off-by: Andi Kleen Signed-off-by: Chris Wright

[PATCH] jfs: jfs_delete_inode must call clear_inode

2005-09-17T01:01:58Z

JFS: jfs_delete_inode should always call clear_inode. > From Chuck Ebbert: I'm submitting this patch for -stable: - it reportedly fixes an oops - it's already in 2.6.13-git Signed-off-by: Dave Kleikamp Signed-off-by: Chris Wright

[PATCH] Fix DHCP + MASQUERADE problem

2005-09-17T01:01:57Z

In 2.6.13-rcX the MASQUERADE target was changed not to exclude local packets for better source address consistency. This breaks DHCP clients using UDP sockets when the DHCP requests are caught by a MASQUERADE rule because the MASQUERADE target drops packets when no address is configured on the outgoing interface. This patch makes it ignore packets with a source address of 0. Thanks to Rusty for this suggestion. Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright

[PATCH] Sun HME: enable and map PCI ROM properly

2005-09-17T01:01:57Z

This ports the Sun GEM ROM mapping/enable fixes it sunhme (which used the same PCI ROM mapping code). Without this, I get NULL MAC addresses for all 4 ports (it's a SUN QFE). With it, I get the correct addresses (the ones printed on the label on the card). Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] Sun GEM ethernet: enable and map PCI ROM properly

2005-09-17T01:01:57Z

This same patch was reported to fix the MAC address detection on sunhme (next patch). Most people seem to be running this on Sparcs or PPC machines, where we get the MAC address from their respective firmware rather than from the (previously broken) ROM mapping routines. Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] hpt366: write the full 4 bytes of ROM address, not just low 1 byte

2005-09-17T01:01:56Z

This is one heck of a confused driver. It uses a byte write to a dword register to enable a ROM resource that it doesn't even seem to be using. "Lost and wandering in the desert of confusion" Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] forcedeth: Initialize link settings in every nv_open()

2005-09-17T01:01:56Z

R�diger found a bug in nv_open that explains some of the reports with duplex mismatches: nv_open calls nv_update_link_speed for initializing the hardware link speed registers. If current link setting matches the values in np->linkspeed and np->duplex, then the function does nothing. Usually, doing nothing is the right thing, but not in nv_open: During nv_open, the registers must be initialized because the nic was reset. The attached patch fixes that by setting np->linkspeed to an invalid value before calling nv_update_link_speed from nv_open. Signed-Off-By: Manfred Spraul Signed-off-by: Jeff Garzik Signed-off-by: Chris Wright