From d5c0f46911fce228f41eaaf3d715c2c8eaff2f34 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 15 Feb 2011 12:51:14 -0800 Subject: [PATCH] .36 patches --- ...rt-has-an-address-before-enabling-it.patch | 85 ++++++++++++++++++ ...bind-to-function-0-of-the-pci-device.patch | 45 ++++++++++ queue-2.6.36/series | 5 ++ ...i-structures-after-a-hub-is-verified.patch | 73 +++++++++++++++ ...-xhci_cleanup_msix-with-irq-disabled.patch | 88 +++++++++++++++++++ ...hci-use-gfp_noio-during-device-reset.patch | 42 +++++++++ 6 files changed, 338 insertions(+) create mode 100644 queue-2.6.36/agp-ensure-gart-has-an-address-before-enabling-it.patch create mode 100644 queue-2.6.36/drm-i915-only-bind-to-function-0-of-the-pci-device.patch create mode 100644 queue-2.6.36/usb-realloc-xhci-structures-after-a-hub-is-verified.patch create mode 100644 queue-2.6.36/xhci-do-not-run-xhci_cleanup_msix-with-irq-disabled.patch create mode 100644 queue-2.6.36/xhci-use-gfp_noio-during-device-reset.patch diff --git a/queue-2.6.36/agp-ensure-gart-has-an-address-before-enabling-it.patch b/queue-2.6.36/agp-ensure-gart-has-an-address-before-enabling-it.patch new file mode 100644 index 00000000000..a4e04001e4e --- /dev/null +++ b/queue-2.6.36/agp-ensure-gart-has-an-address-before-enabling-it.patch @@ -0,0 +1,85 @@ +From a70b95c017e8b518e1e069853355e4e497453dbb Mon Sep 17 00:00:00 2001 +From: Stephen Kitt +Date: Mon, 31 Jan 2011 14:25:43 -0800 +Subject: agp: ensure GART has an address before enabling it + +From: Stephen Kitt + +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 + +--- + drivers/char/agp/intel-agp.c | 27 ++++++++++++++++----------- + 1 file changed, 16 insertions(+), 11 deletions(-) + +--- a/drivers/char/agp/intel-agp.c ++++ b/drivers/char/agp/intel-agp.c +@@ -927,20 +927,14 @@ static int __devinit agp_intel_probe(str + dev_info(&pdev->dev, "Intel %s Chipset\n", intel_agp_chipsets[i].name); + + /* +- * If the device has not been properly setup, the following will catch +- * the problem and should stop the system from crashing. +- * 20030610 - hamish@zot.org +- */ +- if (pci_enable_device(pdev)) { +- dev_err(&pdev->dev, "can't enable PCI device\n"); +- agp_put_bridge(bridge); +- return -ENODEV; +- } +- +- /* + * The following fixes the case where the BIOS has "forgotten" to + * provide an address range for the GART. + * 20030610 - hamish@zot.org ++ * This happens before pci_enable_device() intentionally; ++ * calling pci_enable_device() before assigning the resource ++ * will result in the GART being disabled on machines with such ++ * BIOSs (the GART ends up with a BAR starting at 0, which ++ * conflicts a lot of other devices). + */ + r = &pdev->resource[0]; + if (!r->start && r->end) { +@@ -951,6 +945,17 @@ static int __devinit agp_intel_probe(str + } + } + ++ /* ++ * If the device has not been properly setup, the following will catch ++ * the problem and should stop the system from crashing. ++ * 20030610 - hamish@zot.org ++ */ ++ if (pci_enable_device(pdev)) { ++ dev_err(&pdev->dev, "can't enable PCI device\n"); ++ agp_put_bridge(bridge); ++ return -ENODEV; ++ } ++ + /* Fill in the mode register */ + if (cap_ptr) { + pci_read_config_dword(pdev, diff --git a/queue-2.6.36/drm-i915-only-bind-to-function-0-of-the-pci-device.patch b/queue-2.6.36/drm-i915-only-bind-to-function-0-of-the-pci-device.patch new file mode 100644 index 00000000000..eacd1325a12 --- /dev/null +++ b/queue-2.6.36/drm-i915-only-bind-to-function-0-of-the-pci-device.patch @@ -0,0 +1,45 @@ +From 5fe49d86f9d01044abf687a8cd21edef636d58aa Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Tue, 1 Feb 2011 19:43:02 +0000 +Subject: drm/i915: Only bind to function 0 of the PCI device +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Chris Wilson + +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 + +--- + drivers/gpu/drm/i915/i915_drv.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/gpu/drm/i915/i915_drv.c ++++ b/drivers/gpu/drm/i915/i915_drv.c +@@ -414,6 +414,14 @@ int i965_reset(struct drm_device *dev, u + static int __devinit + i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) + { ++ /* Only bind to function 0 of the device. Early generations ++ * used function 1 as a placeholder for multi-head. This causes ++ * us confusion instead, especially on the systems where both ++ * functions have the same PCI-ID! ++ */ ++ if (PCI_FUNC(pdev->devfn)) ++ return -ENODEV; ++ + return drm_get_pci_dev(pdev, ent, &driver); + } + diff --git a/queue-2.6.36/series b/queue-2.6.36/series index f00dacd1163..13160f709b5 100644 --- a/queue-2.6.36/series +++ b/queue-2.6.36/series @@ -169,3 +169,8 @@ drm-i915-lvds-add-aopen-i915gmm-hfs-to-the-list-of-false-positive-lvds.patch drm-i915-add-dependency-on-config_tmpfs.patch drm-i915-recognise-non-vga-display-devices.patch x86-mm-avoid-possible-bogus-tlb-entries-by-clearing-prev-mm_cpumask-after-switching-mm.patch +agp-ensure-gart-has-an-address-before-enabling-it.patch +drm-i915-only-bind-to-function-0-of-the-pci-device.patch +xhci-do-not-run-xhci_cleanup_msix-with-irq-disabled.patch +usb-realloc-xhci-structures-after-a-hub-is-verified.patch +xhci-use-gfp_noio-during-device-reset.patch diff --git a/queue-2.6.36/usb-realloc-xhci-structures-after-a-hub-is-verified.patch b/queue-2.6.36/usb-realloc-xhci-structures-after-a-hub-is-verified.patch new file mode 100644 index 00000000000..225c698211f --- /dev/null +++ b/queue-2.6.36/usb-realloc-xhci-structures-after-a-hub-is-verified.patch @@ -0,0 +1,73 @@ +From 653a39d1f61bdc9f277766736d21d2e9be0391cb Mon Sep 17 00:00:00 2001 +From: Sarah Sharp +Date: Thu, 23 Dec 2010 11:12:42 -0800 +Subject: usb: Realloc xHCI structures after a hub is verified. + +From: Sarah Sharp + +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 + +--- + drivers/usb/core/hub.c | 21 +++++++++++++++++++++ + 1 file changed, 21 insertions(+) + +--- a/drivers/usb/core/hub.c ++++ b/drivers/usb/core/hub.c +@@ -677,6 +677,8 @@ static void hub_init_func3(struct work_s + static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) + { + struct usb_device *hdev = hub->hdev; ++ struct usb_hcd *hcd; ++ int ret; + int port1; + int status; + bool need_debounce_delay = false; +@@ -715,6 +717,25 @@ static void hub_activate(struct usb_hub + usb_autopm_get_interface_no_resume( + to_usb_interface(hub->intfdev)); + return; /* Continues at init2: below */ ++ } else if (type == HUB_RESET_RESUME) { ++ /* The internal host controller state for the hub device ++ * may be gone after a host power loss on system resume. ++ * Update the device's info so the HW knows it's a hub. ++ */ ++ hcd = bus_to_hcd(hdev->bus); ++ if (hcd->driver->update_hub_device) { ++ ret = hcd->driver->update_hub_device(hcd, hdev, ++ &hub->tt, GFP_NOIO); ++ if (ret < 0) { ++ dev_err(hub->intfdev, "Host not " ++ "accepting hub info " ++ "update.\n"); ++ dev_err(hub->intfdev, "LS/FS devices " ++ "and hubs may not work " ++ "under this hub\n."); ++ } ++ } ++ hub_power_on(hub, true); + } else { + hub_power_on(hub, true); + } diff --git a/queue-2.6.36/xhci-do-not-run-xhci_cleanup_msix-with-irq-disabled.patch b/queue-2.6.36/xhci-do-not-run-xhci_cleanup_msix-with-irq-disabled.patch new file mode 100644 index 00000000000..1e50bd49c98 --- /dev/null +++ b/queue-2.6.36/xhci-do-not-run-xhci_cleanup_msix-with-irq-disabled.patch @@ -0,0 +1,88 @@ +From 40a9fb17f32dbe54de3d636142a59288544deed7 Mon Sep 17 00:00:00 2001 +From: Zhang Rui +Date: Fri, 17 Dec 2010 13:17:04 -0800 +Subject: xhci: Do not run xhci_cleanup_msix with irq disabled + +From: Zhang Rui + +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 + +--- + drivers/usb/host/xhci.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -508,9 +508,10 @@ void xhci_stop(struct usb_hcd *hcd) + spin_lock_irq(&xhci->lock); + xhci_halt(xhci); + xhci_reset(xhci); +- xhci_cleanup_msix(xhci); + spin_unlock_irq(&xhci->lock); + ++ xhci_cleanup_msix(xhci); ++ + #ifdef CONFIG_USB_XHCI_HCD_DEBUGGING + /* Tell the event ring poll function not to reschedule */ + xhci->zombie = 1; +@@ -544,9 +545,10 @@ void xhci_shutdown(struct usb_hcd *hcd) + + spin_lock_irq(&xhci->lock); + xhci_halt(xhci); +- xhci_cleanup_msix(xhci); + spin_unlock_irq(&xhci->lock); + ++ xhci_cleanup_msix(xhci); ++ + xhci_dbg(xhci, "xhci_shutdown completed - status = %x\n", + xhci_readl(xhci, &xhci->op_regs->status)); + } diff --git a/queue-2.6.36/xhci-use-gfp_noio-during-device-reset.patch b/queue-2.6.36/xhci-use-gfp_noio-during-device-reset.patch new file mode 100644 index 00000000000..67a84d7b604 --- /dev/null +++ b/queue-2.6.36/xhci-use-gfp_noio-during-device-reset.patch @@ -0,0 +1,42 @@ +From a6d940dd759bf240d28624198660ed34582a327b Mon Sep 17 00:00:00 2001 +From: Sarah Sharp +Date: Tue, 28 Dec 2010 13:08:42 -0800 +Subject: xhci: Use GFP_NOIO during device reset. + +From: Sarah Sharp + +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 + +--- + drivers/usb/host/xhci.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -2168,8 +2168,12 @@ int xhci_alloc_dev(struct usb_hcd *hcd, + xhci_err(xhci, "Error while assigning device slot ID\n"); + return 0; + } +- /* xhci_alloc_virt_device() does not touch rings; no need to lock */ +- if (!xhci_alloc_virt_device(xhci, xhci->slot_id, udev, GFP_KERNEL)) { ++ /* xhci_alloc_virt_device() does not touch rings; no need to lock. ++ * Use GFP_NOIO, since this function can be called from ++ * xhci_discover_or_reset_device(), which may be called as part of ++ * mass storage driver error handling. ++ */ ++ if (!xhci_alloc_virt_device(xhci, xhci->slot_id, udev, GFP_NOIO)) { + /* Disable slot, if we can do it without mem alloc */ + xhci_warn(xhci, "Could not allocate xHCI USB device data structures\n"); + spin_lock_irqsave(&xhci->lock, flags); -- 2.47.3