linux/drivers, branch v2.6.26.4

sata_mv: don't issue two DMA commands concurrently

2008-09-08T11:44:32Z

commit 4bdee6c5103696a2729d3db2f235d202191788e4 upstream sata_mv allowed issuing two DMA commands concurrently which the hardware allows. Unfortunately, libata core layer isn't ready for this yet and spews ugly warning message and malfunctions on this. Don't allow concurrent DMA commands for now. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik Cc: Martin Michlmayr Cc: Mark Lord Cc: Artem Bokhan Signed-off-by: Greg Kroah-Hartman

r8169: balance pci_map / pci_unmap pair

2008-09-08T11:44:30Z

commit a866bbf6aacf95f849810079442a20be118ce905 upstream The leak hurts with swiotlb and jumbo frames. Fix http://bugzilla.kernel.org/show_bug.cgi?id=9468. Heavily hinted by Ilpo Järvinen . Signed-off-by: Francois Romieu Tested-by: Alistair John Strachan Tested-by: Timothy J Fontaine Cc: Edward Hsu Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

tg3: Fix firmware event timeouts

2008-09-08T11:44:30Z

patch 4ba526ced990f4d61ee8d65fe8a6f0745e8e455c upstream The git commit 7c5026aa9b81dd45df8d3f4e0be73e485976a8b6 ("tg3: Add link state reporting to UMP firmware") introduced code that waits for previous firmware events to be serviced before attempting to submit a new event. Unfortunately that patch contained a bug that cause the driver to wait 2.5 seconds, rather than 2.5 milliseconds as intended. This patch fixes that bug. This bug revealed that not all firmware versions service driver events though. Since we do not know which versions of the firmware do and don't service these events, the driver needs some way to minimize the effects of the delay. This patch solves the problem by recording a jiffies timestamp when it submits an event to the hardware. If the jiffies counter shows that 2.5 milliseconds have already passed, a wait is not needed and the driver can proceed to submit a new event. Signed-off-by: Matt Carlson Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

8250: improve workaround for UARTs that don't re-assert THRE correctly

2008-09-08T11:44:20Z

commit 363f66fe06c75270b669c88e321e6b354ba0201e upstream Recent changes to tighten the check for UARTs that don't correctly re-assert THRE (01c194d9278efc15d4785ff205643e9c0bdcef53: "serial 8250: tighten test for using backup timer") caused problems when such a UART was opened for the second time - the bug could only successfully be detected at first initialization. For users of this version of this particular UART IP it is fatal. This patch stores the information about the bug in the bugs field of the port structure when the port is first started up so subsequent opens can check this bit even if the test for the bug fails. David Brownell: "My own exposure to this is that the UART on DaVinci hardware, which TI allegedly derived from its original 16550 logic, has periodically gone from working to unusable with the mainline 8250.c ... and back and forth a bunch. Currently it's "unusable", a regression from some previous versions. With this patch from Will, it's usable." Signed-off-by: Will Newton Acked-by: Alex Williamson Cc: Alan Cox Cc: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

rtc_time_to_tm: fix signed/unsigned arithmetic

2008-09-08T11:44:20Z

commit 73442daf2ea85e2a779396b76b1a39b10188ecb5 upstream commit 945185a69daa457c4c5e46e47f4afad7dcea734f ("rtc: rtc_time_to_tm: use unsigned arithmetic") changed the some types in rtc_time_to_tm() to unsigned: void rtc_time_to_tm(unsigned long time, struct rtc_time *tm) { - register int days, month, year; + unsigned int days, month, year; This doesn't work for all cases, because days is checked for < 0 later on: if (days < 0) { year -= 1; days += 365 + LEAP_YEAR(year); } I think the correct fix would be to keep days signed and do an appropriate cast later on. Signed-off-by: Jan Altenberg Cc: Maciej W. Rozycki Cc: Alessandro Zummo Cc: David Brownell Cc: Dmitri Vorobiev Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

drivers/char/random.c: fix a race which can lead to a bogus BUG()

2008-09-08T11:44:20Z

commit 8b76f46a2db29407fed66cf4aca19d61b3dcb3e1 upstream Fix a bug reported by and diagnosed by Aaron Straus. This is a regression intruduced into 2.6.26 by commit adc782dae6c4c0f6fb679a48a544cfbcd79ae3dc Author: Matt Mackall Date: Tue Apr 29 01:03:07 2008 -0700 random: simplify and rename credit_entropy_store credit_entropy_bits() does: spin_lock_irqsave(&r->lock, flags); ... if (r->entropy_count > r->poolinfo->POOLBITS) r->entropy_count = r->poolinfo->POOLBITS; so there is a time window in which this BUG_ON(): static size_t account(struct entropy_store *r, size_t nbytes, int min, int reserved) { unsigned long flags; BUG_ON(r->entropy_count > r->poolinfo->POOLBITS); /* Hold lock while accounting */ spin_lock_irqsave(&r->lock, flags); can trigger. We could fix this by moving the assertion inside the lock, but it seems safer and saner to revert to the old behaviour wherein entropy_store.entropy_count at no time exceeds entropy_store.poolinfo->POOLBITS. Reported-by: Aaron Straus Cc: Matt Mackall Cc: Theodore Ts'o Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

atl1: disable TSO by default

2008-09-08T11:44:19Z

commit 82c26a9d117f0178b8c1b33429014b6d99c470f6 upstream The atl1 driver is causing stalled connections and file corruption whenever TSO is enabled. Two examples are here: http://lkml.org/lkml/2008/7/15/325 http://lkml.org/lkml/2008/8/18/543 Disable TSO by default until we can determine the source of the problem. Signed-off-by: Jay Cliburn Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

forcedeth: fix checksum flag

2008-09-08T11:44:19Z

commit edcfe5f7e307846e578fb88d69fa27051fded0ab upstream Fix the checksum feature advertised in device flags. The hardware support TCP/UDP over IPv4 and TCP/UDP over IPv6 (without IPv6 extension headers). However, the kernel feature flags do not distinguish IPv6 with/without extension headers. Therefore, the driver needs to use NETIF_F_IP_CSUM instead of NETIF_F_HW_CSUM since the latter includes all IPv6 packets. A future patch can be created to check for extension headers and perform software checksum calculation. Signed-off-by: Ayaz Abdulla Cc: Jeff Garzik Cc: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

S390 dasd: fix data size for PSF/PRSSD command

2008-09-08T11:44:18Z

commit 49fd38bdaa96f093fcad3176a781a4d0de8f8602 upstream The Perform Subsystem Function/Prepare for Read Subsystem Data command requires 12 bytes of parameter data, but the respective data structure dasd_psf_prssd_data has a length of 16 bytes. Current storage servers ignore the obsolete bytes, but older models fail to execute the command and report an incorrect length error. This causes the device initilization for these devices to fail. To fix this problem we need to correct the dasd_psf_prssd_data structure and shorten it to the correct length. Reported-by: Ivan Warren Reviewed-by: Ivan Warren Tested-by: Ivan Warren Signed-off-by: Stefan Weinhuber Signed-off-by: Greg Kroah-Hartman

USB: cdc-acm: don't unlock acm->mutex on error path

2008-09-08T11:44:17Z

commit 74573ee7096a4ffc2f098108d21c85801b9c7434 upstream On Wed, Jul 23, 2008 at 03:52:36PM +0300, Andrei Popa wrote: > I installed gnokii-0.6.22-r2 and gave the command "gnokii --identify" > and the kernel oopsed: > > BUG: unable to handle kernel NULL pointer dereference at 00000458 > IP: [] mutex_unlock+0x0/0xb > [] acm_tty_open+0x4c/0x214 Signed-off-by: Alexey Dobriyan Tested-by: Andrei Popa Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman