kernel/linux.git, branch v2.6.37.1

Linux 2.6.37.1

2011-02-17T23:44:35+00:00

xhci: Use GFP_NOIO during device reset.

2011-02-17T23:15:22+00:00

commit a6d940dd759bf240d28624198660ed34582a327b upstream. When xhci_discover_or_reset_device() is called after a host controller power loss, the virtual device may need to be reallocated. Make sure xhci_alloc_dev() uses GFP_NOIO. This avoid causing a deadlock by allowing the kernel to flush pending I/O while reallocating memory for a virtual device for a USB mass storage device that's holding the backing store for dirty memory buffers. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

usb: Realloc xHCI structures after a hub is verified.

2011-02-17T23:15:22+00:00

commit 653a39d1f61bdc9f277766736d21d2e9be0391cb upstream. When there's an xHCI host power loss after a suspend from memory, the USB core attempts to reset and verify the USB devices that are attached to the system. The xHCI driver has to reallocate those devices, since the hardware lost all knowledge of them during the power loss. When a hub is plugged in, and the host loses power, the xHCI hardware structures are not updated to say the device is a hub. This is usually done in hub_configure() when the USB hub is detected. That function is skipped during a reset and verify by the USB core, since the core restores the old configuration and alternate settings, and the hub driver has no idea this happened. This bug makes the xHCI host controller reject the enumeration of low speed devices under the resumed hub. Therefore, make the USB core re-setup the internal xHCI hub device information by calling update_hub_device() when hub_activate() is called for a hub reset resume. After a host power loss, all devices under the roothub get a reset-resume or a disconnect. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

xhci: Do not run xhci_cleanup_msix with irq disabled

2011-02-17T23:15:22+00:00

commit 40a9fb17f32dbe54de3d636142a59288544deed7 upstream. when unloading xhci_hcd, I got: [ 134.856813] xhci_hcd 0000:02:00.0: remove, state 4 [ 134.858140] usb usb3: USB disconnect, address 1 [ 134.874956] xhci_hcd 0000:02:00.0: Host controller not halted, aborting reset. [ 134.876351] BUG: sleeping function called from invalid context at kernel/mutex.c:85 [ 134.877657] in_atomic(): 0, irqs_disabled(): 1, pid: 1451, name: modprobe [ 134.878975] Pid: 1451, comm: modprobe Not tainted 2.6.37-rc5+ #162 [ 134.880298] Call Trace: [ 134.881602] [] __might_sleep+0xeb/0xf0 [ 134.882921] [] mutex_lock+0x24/0x50 [ 134.884229] [] free_desc+0x2e/0x5f [ 134.885538] [] irq_free_descs+0x3b/0x71 [ 134.886853] [] free_irq_at+0x31/0x36 [ 134.888167] [] destroy_irq+0x69/0x71 [ 134.889486] [] native_teardown_msi_irq+0xe/0x10 [ 134.890820] [] default_teardown_msi_irqs+0x57/0x80 [ 134.892158] [] free_msi_irqs+0x8b/0xe9 [ 134.893504] [] pci_disable_msix+0x35/0x39 [ 134.894844] [] xhci_cleanup_msix+0x31/0x51 [xhci_hcd] [ 134.896186] [] xhci_stop+0x3a/0x80 [xhci_hcd] [ 134.897521] [] usb_remove_hcd+0xfd/0x14a [ 134.898859] [] usb_hcd_pci_remove+0x5c/0xc6 [ 134.900193] [] pci_device_remove+0x3f/0x91 [ 134.901535] [] __device_release_driver+0x83/0xd9 [ 134.902899] [] driver_detach+0x86/0xad [ 134.904222] [] bus_remove_driver+0xb2/0xd8 [ 134.905540] [] driver_unregister+0x6c/0x74 [ 134.906839] [] pci_unregister_driver+0x44/0x89 [ 134.908121] [] xhci_unregister_pci+0x15/0x17 [xhci_hcd] [ 134.909396] [] xhci_hcd_cleanup+0xe/0x10 [xhci_hcd] [ 134.910652] [] sys_delete_module+0x1ca/0x23b [ 134.911882] [] ? path_put+0x22/0x26 [ 134.913104] [] ? audit_syscall_entry+0x2c/0x148 [ 134.914333] [] system_call_fastpath+0x16/0x1b [ 134.915658] xhci_hcd 0000:02:00.0: USB bus 3 deregistered [ 134.916465] xhci_hcd 0000:02:00.0: PCI INT A disabled and the same issue when xhci_suspend is invoked. (Note from Sarah: That's fixed by Andiry's patch before this, by synchronizing the irqs rather than freeing them on suspend.) Do not run xhci_cleanup_msix with irq disabled. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Zhang Rui Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

xHCI: synchronize irq in xhci_suspend()

2011-02-17T23:15:22+00:00

commit 0029227f1bc30b6c809ae751f9e7af6cef900997 upstream. Synchronize the interrupts instead of free them in xhci_suspend(). This will prevent a double free when the host is suspended and then the card removed. Set the flag hcd->msix_enabled when using MSI-X, and check the flag in suspend_common(). MSI-X synchronization will be handled by xhci_suspend(), and MSI/INTx will be synchronized in suspend_common(). This patch should be queued for the 2.6.37 stable tree. Reported-by: Matthew Garrett Signed-off-by: Andiry Xu Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

xhci: Resume bus on any port status change.

2011-02-17T23:15:21+00:00

commit 7111ebc97ed53a32314011c85a6f235f0dab8ae8 upstream. The original code that resumed the USB bus on a port status change would only do so when there was a device connected to the port. If a device was just disconnected, the event would be queued for khubd, but khubd wouldn't run. That would leave the connect status change (CSC) bit set. If a USB device was plugged into that same port, the xHCI host controller would set the current connect status (CCS) bit. But since the CSC bit was already set, it would not generate an interrupt for a port status change event. That would mean the user could "Safely Remove" a device, have the bus suspend, disconnect the device, re-plug it in, and then the device would never be enumerated. Plugging in a different device on another port would cause the bus to resume, and khubd would notice the re-connected device. Running lsusb would also resume the bus, leading users to report the problem "went away" when using diagnostic tools. The solution is to resume the bus when a port status change event is received, regardless of the port status. Thank you very much to Maddog for helping me track down this Heisenbug. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp Reported-by: Jon 'maddog' Hall Tested-by: Andiry Xu Signed-off-by: Greg Kroah-Hartman

drm/i915: Only bind to function 0 of the PCI device

2011-02-17T23:15:21+00:00

commit 5fe49d86f9d01044abf687a8cd21edef636d58aa upstream. Early chipsets (gen2/3) used function 1 as a placeholder for multi-head. We used to ignore these since they were not assigned to PCI_CLASS_DISPLAY_VGA. However with 934f992c7 we attempt to bind to all Intel PCI_CLASS_DISPLAY devices (and functions) to work in multi-gpu systems. This fails hard on gen2/3. Reported-by: Ferenc Wágner Tested-by: Ferenc Wágner Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28012 Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman

agp: ensure GART has an address before enabling it

2011-02-17T23:15:20+00:00

commit a70b95c017e8b518e1e069853355e4e497453dbb upstream. Some BIOSs (eg. the AMI BIOS on the Asus P4P800 motherboard) don't initialise the GART address, and pcibios_assign_resources() can ignore it because it can be marked as a host bridge (see https://bugzilla.kernel.org/show_bug.cgi?id=24392#c5 for details). This was handled correctly up to 2.6.35, but the pci_enable_device() cleanup in 2.6.36 96576a9e1a0cdb8 ("agp: intel-agp: do not use PCI resources before pci_enable_device()") means that the kernel tries to enable the GART before assigning it an address; in such cases the GART overlaps with other device assignments and ends up being disabled. This patch fixes https://bugzilla.kernel.org/show_bug.cgi?id=24392 Note that I imagine efficeon-agp.c probably has the same problem, but I can't test that and I'd like to make sure this patch is suitable for -stable (since 2.6.36 and 2.6.37 are affected). Signed-off-by: Stephen Kitt Cc: Bjorn Helgaas Cc: Maciej Rutecki Cc: "Rafael J. Wysocki" Cc: Kulikov Vasiliy Cc: Florian Mickler Signed-off-by: Andrew Morton Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm: Only set DPMS ON when actually configuring a mode

2011-02-17T23:15:20+00:00

commit 811aaa55ba21ab37407018cfc01770d6b037d3fb upstream. In drm_crtc_helper_set_config, instead of always forcing all outputs to DRM_MODE_DPMS_ON, only set them if the CRTC is actually getting a mode set, as any mode set will turn all outputs on. This fixes https://lkml.org/lkml/2011/1/24/457 Signed-off-by: Keith Packard Reported-and-tested-by: Carlos R. Mafra Tested-by: Takashi Iwai Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm

2011-02-17T23:15:20+00:00

commit 831d52bc153971b70e64eccfbed2b232394f22f8 upstream. Clearing the cpu in prev's mm_cpumask early will avoid the flush tlb IPI's while the cr3 is still pointing to the prev mm. And this window can lead to the possibility of bogus TLB fills resulting in strange failures. One such problematic scenario is mentioned below. T1. CPU-1 is context switching from mm1 to mm2 context and got a NMI etc between the point of clearing the cpu from the mm_cpumask(mm1) and before reloading the cr3 with the new mm2. T2. CPU-2 is tearing down a specific vma for mm1 and will proceed with flushing the TLB for mm1. It doesn't send the flush TLB to CPU-1 as it doesn't see that cpu listed in the mm_cpumask(mm1). T3. After the TLB flush is complete, CPU-2 goes ahead and frees the page-table pages associated with the removed vma mapping. T4. CPU-2 now allocates those freed page-table pages for something else. T5. As the CR3 and TLB caches for mm1 is still active on CPU-1, CPU-1 can potentially speculate and walk through the page-table caches and can insert new TLB entries. As the page-table pages are already freed and being used on CPU-2, this page walk can potentially insert a bogus global TLB entry depending on the (random) contents of the page that is being used on CPU-2. T6. This bogus TLB entry being global will be active across future CR3 changes and can result in weird memory corruption etc. To avoid this issue, for the prev mm that is handing over the cpu to another mm, clear the cpu from the mm_cpumask(prev) after the cr3 is changed. Marking it for -stable, though we haven't seen any reported failure that can be attributed to this. Signed-off-by: Suresh Siddha Acked-by: Ingo Molnar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman