commit 6bcd6d778419101dd96cbbdf03eeab8d779b1d66 Author: Greg Kroah-Hartman Date: Sat Oct 18 10:57:22 2008 -0700 Linux 2.6.27.2 commit 6505670551fa3deeb6e5d7cab6983514384c7220 Author: Matthew Wilcox Date: Tue Aug 12 07:13:14 2008 -0600 netdrvr: atl1e: Don't take the mdio_lock in atl1e_probe commit f382a0a8e9403c6d7f8b2cfa21e41fefb5d0c9bd upstream Lockdep warns about the mdio_lock taken with interrupts enabled then later taken from interrupt context. Initially, I considered changing these to spin_lock_irq/spin_unlock_irq, but then I looked at atl1e_phy_init() and saw that it calls msleep(). Sleeping while holding a spinlock is not allowed either. In the probe path, we haven't registered the interrupt handler, so it can't poke at this card yet. It's before we call register_netdev(), so I don't think any other threads can reach this card either. If I'm right, we don't need a spinlock at all. Signed-off-by: Matthew Wilcox Cc: Jay Cliburn Signed-off-by: Jeff Garzik Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0018d3e671060d5576fe99a2fe1985db4b1ea946 Author: Rafael J. Wysocki Date: Sun Oct 12 20:59:48 2008 -0700 sky2: Fix WOL regression commit 9d731d77c9794bb0a264f58d35949a1ab6dcc41c upstream Since dev->power.should_wakeup bit is used by the PCI core to decide whether the device should wake up the system from sleep states, set/unset this bit whenever WOL is enabled/disabled using sky2_set_wol(). Remove an open-coded reference to the standard PCI PM registers that is not used any more. Signed-off-by: Rafael J. Wysocki Cc: Tino Keitel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f558a0f3f28dcdb969d56ce9bad1391d001c3b31 Author: Thomas Gleixner Date: Mon Oct 13 17:15:23 2008 +0000 x86: improve UP kernel when CPU-hotplug and SMP is enabled commit 649c6653fa94ec8f3ea32b19c97b790ec4e8e4ac upstream num_possible_cpus() can be > 1 when disabled CPUs have been accounted. Disabled CPUs are not in the cpu_present_map, so we can use num_present_cpus() as a safe indicator to switch to UP alternatives. Reported-by: Chuck Ebbert Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e87898fdba90f9a270ae6bdb8ce98da91338a951 Author: Andreas Herrmann Date: Sun Oct 12 19:40:11 2008 +0000 x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC commit 33fb0e4eb53f16af312f9698f974e2e64af39c12 upstream On some HP nx6... laptops (e.g. nx6325) BIOS reports an IRQ0 override but the SB450 chipset is configured such that timer interrupts goe to INT0 of IOAPIC. Check IRQ0 routing and if it is routed to INT0 of IOAPIC skip the timer override. [ This more generic PCI ID based quirk should alleviate the need for dmi_ignore_irq0_timer_override DMI quirks. ] Signed-off-by: Andreas Herrmann Acked-by: "Maciej W. Rozycki" Tested-by: Dmitry Torokhov Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit d344a53f2e264ea07c950691c1451a4ff355694b Author: Alan Cox Date: Sun Oct 12 19:40:08 2008 +0000 x86, early_ioremap: fix fencepost error commit c613ec1a7ff3714da11c7c48a13bab03beb5c376 upstream The x86 implementation of early_ioremap has an off by one error. If we get an object which ends on the first byte of a page we undermap by one page and this causes a crash on boot with the ASUS P5QL whose DMI table happens to fit this alignment. The size computation is currently last_addr = phys_addr + size - 1; npages = (PAGE_ALIGN(last_addr) - phys_addr) (Consider a request for 1 byte at alignment 0...) Closes #11693 Debugging work by Ian Campbell/Felix Geyer Signed-off-by: Alan Cox Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 432283d2c4e674181b892d77d9ac757b0f9899ea Author: Larry Finger Date: Sat Oct 11 16:55:21 2008 +0000 b43legacy: Fix failure in rate-adjustment mechanism commit c6a2afdacccd56cc0be8e9a7977f0ed1509069f6 upstream Date: Sat, 6 Sep 2008 16:51:22 -0500 Subject: b43legacy: Fix failure in rate-adjustment mechanism A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit a273874b531262d699d4fc1fdc0037798997a123 Author: Dan Williams Date: Sat Oct 11 16:55:19 2008 +0000 libertas: clear current command on card removal commit 71b35f3abeb8f7f7e0afd7573424540cc5aae2d5 upstream If certain commands were in-flight when the card was pulled or the driver rmmod-ed, cleanup would block on the work queue stopping, but the work queue was in turn blocked on the current command being canceled, which didn't happen. Fix that. Signed-off-by: Dan Williams Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 95a3690291668508570c593ccc8b69af1f0e3f3f Author: Henrique de Moraes Holschuh Date: Sat Oct 11 16:55:13 2008 +0000 rfkill: update LEDs for all state changes commit 417bd25ac4c6f76c8aafe8a584f3620f4a936b72 upstream The LED state was not being updated by rfkill_force_state(), which will cause regressions in wireless drivers that had old-style rfkill support and are updated to use rfkill_force_state(). The LED state was not being updated when a change was detected through the rfkill->get_state() hook, either. Move the LED trigger update calls into notify_rfkill_state_change(), where it should have been in the first place. This takes care of both issues above. Signed-off-by: Henrique de Moraes Holschuh Acked-by: Ivo van Doorn Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 92fa67e9260a65f69d868c4fcc92c9cee428c6f9 Author: Steve French Date: Sat Oct 11 16:55:11 2008 +0000 CIFS: make sure we have the right resume info before calling CIFSFindNext commit 0752f1522a9120f731232919f7ad904e9e22b8ce upstream When we do a seekdir() or equivalent, we usually end up doing a FindFirst call and then call FindNext until we get to the offset that we want. The problem is that when we call FindNext, the code usually doesn't have the proper info (mostly, the filename of the entry from the last search) to resume the search. Add a "last_entry" field to the cifs_search_info that points to the last entry in the search. We calculate this pointer by using the LastNameOffset field from the search parms that are returned. We then use that info to do a cifs_save_resume_key before we call CIFSFindNext. This patch allows CIFS to reliably pass the "telldir" connectathon test. Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 074555fe0e36c1bde7795e8f3f7350d228b9dd1c Author: Alan Cox Date: Mon Oct 13 10:38:46 2008 +0100 tty: Termios locking - sort out real_tty confusions and lock reads commit 8f520021837d45c47d0ab57e7271f8d88bf7f3a4 upstream (only the tty_io.c portion of this commit) This moves us towards sanity and should mean our termios locking is now complete and comprehensive. Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 769b0455c1ec257b9e5067129accab1a6052de4c Author: Christoph Hellwig Date: Fri Oct 10 17:28:29 2008 +1100 Fix barrier fail detection in XFS commit 73f6aa4d44ab6157badc456ddfa05b31e58de5f0 upstream. Currently we disable barriers as soon as we get a buffer in xlog_iodone that has the XBF_ORDERED flag cleared. But this can be the case not only for buffers where the barrier failed, but also the first buffer of a split log write in case of a log wraparound. Due to the disabled barriers we can easily get directory corruption on unclean shutdowns. So instead of using this check add a new buffer flag for failed barrier writes. This is a regression vs 2.6.26 caused by patch to use the right macro to check for the ORDERED flag, as we previously got true returned for every buffer. Thanks to Toei Rei for reporting the bug. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Reviewed-by: David Chinner Signed-off-by: Tim Shimmin Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 60b216fffd66fc2ad2824a05d6838aff6b59d827 Author: Johannes Berg Date: Fri Oct 10 17:52:49 2008 +0200 mac80211: fix two issues in debugfs Not in trees above 2.6.27 as it is fixed differently in .28. This fixes RHBZ 466264, whenever the master interface is renamed this code would BUG_ON. Also fixes a separately reported bug with the debugfs dir being NULL. This patch is not applicable to the next kernel version because both these issues have been fixed, the first one by not having the master interface have a ieee80211_ptr at all, and the second one by also leaving the function early. Signed-off-by: Johannes Berg Cc: John Linville Signed-off-by: Greg Kroah-Hartman commit 7ae3a769f9cbde6564b7335b0ea45d19066c7f7c Author: Stefan Bader Date: Sat Sep 27 11:07:30 2008 -0400 x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap. Not in upstream above 2.6.27 due to change in the way this code works (has been fixed differently there.) Someone from the community found out, that after repeatedly unloading and loading a device driver that uses MSI IRQs, the system eventually assigned the vector initially reserved for IRQ0 to the device driver. The reason for this is, that although IRQ0 is tied to the FIRST_DEVICE_VECTOR when declaring the irq_vector table, the corresponding bit in the used_vectors map is not set. So, if vectors are released and assigned often enough, the vector will get assigned to another interrupt. This happens more often with MSI interrupts as those are exclusively using a vector. Fix this by setting the bit for the FIRST_DEVICE_VECTOR in the bitmap. Signed-off-by: Stefan Bader Acked-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit d49d50a98a807e9322bc287e5da26d70168cd4c0 Author: Dario Faggioli Date: Fri Oct 10 20:15:02 2008 +0000 sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream While working on the new version of the code for SCHED_SPORADIC I noticed something strange in the present throttling mechanism. More specifically in the throttling timer handler in sched_rt.c (do_sched_rt_period_timer()) and in rt_rq_enqueue(). The problem is that, when unthrottling a runqueue, rt_rq_enqueue() only asks for rescheduling if the runqueue has a sched_entity associated to it (i.e., rt_rq->rt_se != NULL). Now, if the runqueue is the root rq (which has a rt_se = NULL) rescheduling does not take place, and it is delayed to some undefined instant in the future. This imply some random bandwidth usage by the RT tasks under throttling. For instance, setting rt_runtime_us/rt_period_us = 950ms/1000ms an RT task will get less than 95%. In our tests we got something varying between 70% to 95%. Using smaller time values, e.g., 95ms/100ms, things are even worse, and I can see values also going down to 20-25%!! The tests we performed are simply running 'yes' as a SCHED_FIFO task, and checking the CPU usage with top, but we can investigate thoroughly if you think it is needed. Things go much better, for us, with the attached patch... Don't know if it is the best approach, but it solved the issue for us. Signed-off-by: Dario Faggioli Signed-off-by: Michael Trimarchi Acked-by: Peter Zijlstra Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman