commit 638a189440cc2dccf2eddf18f8071253fc705745 Author: Greg Kroah-Hartman Date: Thu Feb 17 15:44:35 2011 -0800 Linux 2.6.37.1 commit 61e1444816df473bb5648541ab6e5d8897972053 Author: Sarah Sharp Date: Tue Dec 28 13:08:42 2010 -0800 xhci: Use GFP_NOIO during device reset. 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 commit 1baa45caa1c0a5aa2075b0be7f8dea1ba35d59ea Author: Sarah Sharp Date: Thu Dec 23 11:12:42 2010 -0800 usb: Realloc xHCI structures after a hub is verified. 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 commit 25b1bef99bf388dec1127f43865600be40b4df05 Author: Zhang Rui Date: Fri Dec 17 13:17:04 2010 -0800 xhci: Do not run xhci_cleanup_msix with irq disabled 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 commit 09302e3286eb76d3d85d117e28bb0c3950163278 Author: Andiry Xu Date: Mon Dec 27 17:39:02 2010 +0800 xHCI: synchronize irq in xhci_suspend() 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 commit 97347262562763e32da386600b3b9e69f7dd724c Author: Sarah Sharp Date: Tue Dec 14 13:24:55 2010 -0800 xhci: Resume bus on any port status change. 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 commit 3e4025ac37f80662d9f2d64377129d80998857e1 Author: Chris Wilson Date: Tue Feb 1 19:43:02 2011 +0000 drm/i915: Only bind to function 0 of the PCI device 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 commit 8a6852fc5a74f999c1a3132db7e856b541928deb Author: Stephen Kitt Date: Mon Jan 31 14:25:43 2011 -0800 agp: ensure GART has an address before enabling it 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 commit f322c1dbf090eb7fe60ed5cb0e40cd55d670b765 Author: Keith Packard Date: Thu Feb 3 16:57:28 2011 -0800 drm: Only set DPMS ON when actually configuring a mode 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 commit 134fee9c4369ad67df2e3f0e6ec66c4fb4fb4e85 Author: Suresh Siddha Date: Thu Feb 3 12:20:04 2011 -0800 x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm 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 commit 1d44f51b29d28d81d20b60fa1f811971b1d0f720 Author: Chris Wilson Date: Thu Jan 20 13:09:12 2011 +0000 drm/i915: Recognise non-VGA display devices commit 934f992c763ae1e5eefcce8af769c16444085df7 upstream. Starting with SandyBridge (though possible with earlier hacked BIOSes), the BIOS may initialise the IGFX as secondary to a discrete GPU. Prior, it would simply disable the integrated GPU. So we adjust our PCI class mask to match any DISPLAY_CLASS device. In such a configuration, the IGFX is not a primary VGA controller and so should not take part in VGA arbitration, and the error return from vga_client_register() is expected. Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 9cc0842a2e742afac0afdafb54062b3b38a3d486 Author: Chris Wilson Date: Thu Jan 20 10:03:24 2011 +0000 drm/i915: Add dependency on CONFIG_TMPFS commit f7ab9b407b3bc83161c2aa74c992ba4782e87c9c upstream. Without tmpfs, shmem_readpage() is not compiled in causing an OOPS as soon as we try to allocate some swappable pages for GEM. Jan 19 22:52:26 harlie kernel: Modules linked in: i915(+) drm_kms_helper cfbcopyarea video backlight cfbimgblt cfbfillrect Jan 19 22:52:26 harlie kernel: Jan 19 22:52:26 harlie kernel: Pid: 1125, comm: modprobe Not tainted 2.6.37Harlie #10 To be filled by O.E.M./To be filled by O.E.M. Jan 19 22:52:26 harlie kernel: EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 3 Jan 19 22:52:26 harlie kernel: EIP is at 0x0 Jan 19 22:52:26 harlie kernel: EAX: 00000000 EBX: f7b7d000 ECX: f3383100 EDX: f7b7d000 Jan 19 22:52:26 harlie kernel: ESI: f1456118 EDI: 00000000 EBP: f2303c98 ESP: f2303c7c Jan 19 22:52:26 harlie kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Jan 19 22:52:26 harlie kernel: Process modprobe (pid: 1125, ti=f2302000 task=f259cd80 task.ti=f2302000) Jan 19 22:52:26 harlie kernel: Stack: Jan 19 22:52:26 harlie udevd-work[1072]: '/sbin/modprobe -b pci:v00008086d00000046sv00000000sd00000000bc03sc00i00' unexpected exit with status 0x0009 Jan 19 22:52:26 harlie kernel: c1074061 000000d0 f2f42b80 00000000 000a13d2 f2d5dcc0 00000001 f2303cac Jan 19 22:52:26 harlie kernel: c107416f 00000000 000a13d2 00000000 f2303cd4 f8d620ed f2cee620 00001000 Jan 19 22:52:26 harlie kernel: 00000000 000a13d2 f1456118 f2d5dcc0 f1a40000 00001000 f2303d04 f8d637ab Jan 19 22:52:26 harlie kernel: Call Trace: Jan 19 22:52:26 harlie kernel: [] ? do_read_cache_page+0x71/0x160 Jan 19 22:52:26 harlie kernel: [] ? read_cache_page_gfp+0x1f/0x30 Jan 19 22:52:26 harlie kernel: [] ? i915_gem_object_get_pages+0xad/0x1d0 [i915] Jan 19 22:52:26 harlie kernel: [] ? i915_gem_object_bind_to_gtt+0xeb/0x2d0 [i915] Jan 19 22:52:26 harlie kernel: [] ? i915_gem_object_pin+0x151/0x190 [i915] Jan 19 22:52:26 harlie kernel: [] ? drm_gem_object_init+0x3d/0x60 Jan 19 22:52:26 harlie kernel: [] ? i915_gem_init_ringbuffer+0x105/0x1e0 [i915] Jan 19 22:52:26 harlie kernel: [] ? i915_driver_load+0x667/0x1160 [i915] Reported-by: John J. Stimson-III Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 8cb3e542b6c839a34db2bb0e4db8fcf0a3d2998a Author: Knut Petersen Date: Fri Jan 14 15:38:10 2011 +0000 drm/i915/lvds: Add AOpen i915GMm-HFS to the list of false-positive LVDS commit 22ab70d3262ddb6e69b3c246a34e2967ba5eb1e8 upstream. Signed-off-by: Knut Petersen Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit b07a47f14ec9a2a6c73da3f3ee856d4cc0b36b1b Author: Indan Zupancic Date: Wed Jan 12 11:59:19 2011 +0000 drm/i915/panel: The backlight is enabled if the current value is non-zero commit c8303e7f3f3093c16ef0fa5f73280637c89d4368 upstream. ... and not if the maximum is non-zero. This fixes the typo introduced in 47356eb6728501452 and preserves the backlight value from boot. [ickle: My thanks also to Indan Zupancic for diagnosing the original regression and suggesting the appropriate fix.] Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 3719e122dd3ae24d3419c261647bada674ff9246 Author: Chris Wilson Date: Tue Jan 11 17:06:04 2011 +0000 drm/i915/panel: Only record the backlight level when it is enabled commit 47356eb67285014527a5ab87543ba1fae3d1e10a upstream. By tracking the current status of the backlight we can prevent recording the value of the current backlight when we have disabled it. And so prevent restoring it to 'off' after an unbalanced sequence of intel_lvds_disable/enable. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=22672 Tested-by: Alex Riesen Tested-by: Larry Finger Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 8cf83d4ebcf7819cfe8c58774afee79462a25a8f Author: Yuanhan Liu Date: Thu Jan 6 18:26:08 2011 +0800 drm/i915: fix calculation of eDP signal levels on Sandybridge commit 3c5a62b5226ca5db993660281e9c2a7275d9fb02 upstream. Some voltage swing/pre-emphasis level use the same value on eDP Sandybridge, like 400mv_0db and 600mv_0db are with the same value of (0x0 << 22). So, fix them, and point out the value if it isn't a supported voltage swing/pre-emphasis level. Signed-off-by: Yuanhan Liu Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 74f14ea690ddd37acebfd20c1b725c16d27c89c3 Author: David Müller Date: Thu Jan 6 12:29:32 2011 +0000 drm/i915/crt: Check for a analog monitor in case of DVI-I commit f5afcd3dd0dca7fe869311c51da54d5a889191ba upstream. Since Linux 2.6.36 the digital output on my system (855GME + DVI-I) is not working any longer. The analog output is always activated regardless of the type of monitor attached. The culprit seems to be intel_crt_detect_ddc(), which returns true as soon as an ACK from the EDID device is received. Obviously this approach does not work with DVI-I where the analog and digital outputs share a common DDC bus. In a similar manner to the shared DDC wire, ala the "Mac Mini Hack", we need an additional check to make sure that there really is an analog device attached to the DDC. Signed-off-by: David Müller Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit d3130c162d2511f1d649b3f415b23b0df92b1c25 Author: Chris Wilson Date: Tue Jan 4 20:10:52 2011 +0000 drm/i915/sdvo: Defer detection of output capabilities until probing commit 97aaf910731b03b27b1c4c8a58006a1dc99dcd9a upstream. Alex Fiestas reported an issue with his HDMI connector being misdetected as DVI unless he had something connected upon boot. By moving the decision as to whether to use HDMI or DVI encoding for the HDMI capable output until we probe the monitor means that we should avoid sending a HDMI signal to a DVI monitor and also correctly detect hardware like Alex's. However, to really determine what connector is soldered onto the wire we need to inspect the VBT sdvo child devices - but can we trust it? Reported-by: Alex Fiestas Tested-by: Alex Fiestas Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32828 Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit a3679352b5b199740081a48858f81365a7a4c5e4 Author: Jesse Barnes Date: Tue Jan 4 10:46:49 2011 -0800 drm/i915: check eDP encoder correctly when setting modes commit 858bc21f0637c407601a05626854ae58b242f75d upstream. We were using a stale pointer in the check which caused us to use CPU attached DP params when we should have been using PCH attached params. Signed-off-by: Jesse Barnes Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31988 Tested-by: Jan-Hendrik Zab Tested-by: Christoph Lukas Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 110b9f69760df6d5ddf734647aaae61d18ca0462 Author: Chris Wilson Date: Sat Jan 8 15:10:41 2011 +0000 drm: Restore the old_fb upon modeset failure commit 0ba41e449fd0f45f5b29c1009020ab1b298bedda upstream. ... or else we may end up disabling the wrong framebuffer, leading to an OOPS, e.g: [ 6033.229012] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3271! [ 6033.229012] invalid opcode: 0000 [#1] SMP [ 6033.229012] last sysfs file: /sys/devices/virtual/backlight/acpi_video0/uevent [ 6033.229012] Modules linked in: sunrpc cpufreq_ondemand acpi_cpufreq mperf snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer thinkpad_acpi ppdev snd r852 sm_common iTCO_wdt uvcvideo i2c_i801 iTCO_vendor_support microcode wmi nand videodev nand_ids nand_ecc snd_page_alloc parport_pc parport mtd soundcore joydev v4l1_compat pcspkr uinput ipv6 sdhci_pci sdhci mmc_core yenta_socket i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] [ 6033.229012] [ 6033.229012] Pid: 4834, comm: Xorg Not tainted 2.6.37-rc8+ #25 7661BL5/7661BL5 [ 6033.229012] EIP: 0060:[] EFLAGS: 00013246 CPU: 0 [ 6033.229012] EIP is at i915_gem_object_unpin+0x23/0x76 [i915] [ 6033.229012] EAX: f68a4000 EBX: f6831f00 ECX: 000600fa EDX: f68a8000 [ 6033.229012] ESI: f68a4014 EDI: f68a42b8 EBP: f2169c44 ESP: f2169c3c [ 6033.229012] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 6033.229012] Process Xorg (pid: 4834, ti=f2168000 task=f21c8000 task.ti=f2168000) [ 6033.229012] Stack: [ 6033.229012] f3a84800 f68a4014 f2169c54 f87045d8 f3a84800 f872d9a8 f2169c68 f7fd8091 [ 6033.229012] f3b952a4 00000000 f68a414c f2169cf0 f7fd9377 00000000 00000000 f7fd98b0 [ 6033.229012] f7fd9f4e 0000000f f7f328a0 00000000 00000000 00000000 f2169ca4 f68a414c [ 6033.229012] Call Trace: [ 6033.229012] [] ? intel_crtc_disable+0x36/0x41 [i915] [ 6033.229012] [] ? drm_helper_disable_unused_functions+0xcd/0xf9 [drm_kms_helper] [ 6033.229012] [] ? drm_crtc_helper_set_config+0x62a/0x7f7 [drm_kms_helper] [ 6033.229012] [] ? __slab_free+0x1b/0xa4 [ 6033.229012] [] ? drm_fb_helper_initial_config+0x466/0x497 [drm_kms_helper] [ 6033.229012] [] ? drm_fb_helper_restore+0x10/0x2a [drm_kms_helper] [ 6033.229012] [] ? i915_driver_lastclose+0x2a/0x57 [i915] [ 6033.229012] [] ? drm_lastclose+0x45/0x23e [drm] [ 6033.229012] [] ? drm_release+0x462/0x4d7 [drm] Signed-off-by: Chris Wilson Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit c318dcf6609661f7ad0979a85f87d6777f934a70 Author: Alex Deucher Date: Wed Feb 2 19:46:06 2011 -0500 drm/radeon/kms: fix s/r issues with bios scratch regs commit 87364760de5d631390c478fcbac8db1b926e0adf upstream. The accelerate mode bit gets checked by certain atom command tables to set up some register state. It needs to be clear when setting modes and set when not. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=26942 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 9946bb87f3b9766f7d19515af6009cf8dd221fd1 Author: Alex Deucher Date: Wed Feb 2 12:37:41 2011 -0500 drm/radeon/kms/evergreen: always set certain VGT regs at CP init commit 18ff84da29b3f0c073e0ce6e341663cc6bcb0ab7 upstream. These should be handled by the clear_state setup, but set them directly as well just to be sure. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 40219cd8c93ccf10dee7bd9e3aa31bd469fd44d6 Author: Alex Deucher Date: Tue Feb 1 19:06:46 2011 -0500 drm/radeon: remove 0x4243 pci id commit 63a507800c8aca5a1891d598ae13f829346e8e39 upstream. 0x4243 is a PCI bridge, not a GPU. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=33815 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 163cee0d4ea22e1051407ad5f73025c778522f09 Author: Alex Deucher Date: Mon Jan 31 16:48:53 2011 -0500 drm/radeon/kms: Enable new pll calculation for avivo+ asics commit 619efb105924d8cafa0c1dd9389e9ab506f5425d upstream. New algo is used for r5xx+ and legacy is used for r1xx-r4xx, rv515. I've tested on all relevant GPUs and monitors that I have access to and have found no problems. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=26562 https://bugzilla.kernel.org/show_bug.cgi?id=26552 May fix: https://bugs.freedesktop.org/show_bug.cgi?id=32556 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 272d41549df1b1ce8970424ab1d3ed538823e2a8 Author: Alex Deucher Date: Mon Jan 31 16:48:52 2011 -0500 drm/radeon/kms: add new pll algo for avivo asics commit f523f74eac1897b13c05c88ce6e5de0a7c34578b upstream. Based on the vbios code. This should hopefully fix the pll problems on a number of avivo asics once it's enabled. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 3b4d27565ca5df9943b8f8a8dda3e15651f67f8f Author: Alex Deucher Date: Mon Jan 31 16:48:51 2011 -0500 drm/radeon/kms: add pll debugging output commit 51d4bf840a27fe02c883ddc6d9708af056773769 upstream. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit f9cd80c2ac92c8579eb229641bce1958490844d2 Author: Alex Deucher Date: Mon Jan 31 16:48:50 2011 -0500 drm/radeon/kms: switch back to min->max pll post divider iteration commit a6f9761743bf35b052180f4a8bdae4d2cc0465f6 upstream. Seems more reliable. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=26552 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 175eea80b075a4ef77be400e4299d1d80c0fb8e9 Author: Alex Deucher Date: Thu Jan 27 17:01:52 2011 -0500 drm/radeon/kms: re-emit full context state for evergreen blits commit 1e644d6dce366a7bae22484f60133b61ba322911 upstream. clear state doesn't seem to work properly in some cases Fixes hangs in heavy 3D on some evergreen cards reported on IRC. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=33381 possibly others. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit c2292251cb106ee742b70f215aa721e056cd4a7b Author: Jerome Glisse Date: Wed Jan 26 17:51:03 2011 -0500 radeon/kms: fix dp displayport mode validation commit 6bba2e116808ca12e30c8d88dfedabf8b8d67390 upstream. Check if there is a big enough dp clock & enough dp lane to drive the video mode provided. Signed-off-by: Jerome Glisse Reviewed-By: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e3a409e3ef6b4ac321bb060d8ae5236e4ce06998 Author: Alex Deucher Date: Tue Jan 18 18:26:11 2011 +0000 drm/radeon/kms: make the mac rv630 quirk generic commit be23da8ad219650517cbbb7acbeaeb235667113a upstream. Seems some other boards do this as well. Reported-by: Andrea Merello Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit cd5e6b6c98e203af86f8414ffbcfa22f1345e76c Author: Alex Deucher Date: Tue Jan 4 17:42:20 2011 -0500 drm/radeon/kms: adjust quirk for acer laptop commit 2f299d5de02da3ffb1f9e1a05c91dcd1173ebd3c upstream. Acer laptop (TravelMate 5730G) has an HDMI connector on the laptop and a DVI connector on the docking station and both share the same encoder, hpd pin, and ddc line. The bios connector table reflects this and is technically correct, however, we drop the DVI connector here since xrandr has no concept of encoders (only crtcs and connectors) and will try and drive both connectors with different crtcs which isn't possible on the hardware side and leaves no crtcs for LVDS or VGA. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=32732 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 6dd6b21b4739d2b908cad860ca5bbb1f9082ab0e Author: Alex Deucher Date: Tue Jan 4 00:43:39 2011 -0500 drm/radeon/kms: add quirk for Mac Radeon HD 2600 card commit f598aa7593427ffe3a61e7767c34bd695a5e7ed0 upstream. Reported-by: 屋国遥 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit ff3aa02aba272558c0abaadc6f6641dadbc7ae95 Author: Shawn Guo Date: Wed Jan 5 21:13:09 2011 +0000 net/fec: fix MMFR_OP type in fec_enet_mdio_write commit 862f0982eadcea0e114576c57ea426d3d51a69a6 upstream. FEC_MMFR_OP_WRITE should be used than FEC_MMFR_OP_READ in a mdio write operation. It's probably a typo introduced by commit: e6b043d512fa8d9a3801bf5d72bfa3b8fc3b3cc8 netdev/fec.c: add phylib supporting to enable carrier detection (v2) Signed-off-by: Shawn Guo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 13aab0a062f776fca48b17645ed53eb02d0bdcd4 Author: Ari Kauppi Date: Thu Jan 20 13:57:19 2011 -0500 ARM: oprofile: Fix backtraces in timer mode commit d14dd7e20d5e526557f5d3cfef4046a642f80924 upstream. Always allow backtraces when using oprofile on ARM, even if a PMU isn't present. Restores functionality originally introduced in commit 1b7b56982fdcd9d85effd76f3928cf5d6eb26155 ("oprofile: Always allow backtraces on ARM") by Richard Purdie. It is not that obvious, but there is now only one oprofile_arch_init() function. So the .backtrace callback is available also in timer mode. Implemented by removing code and using stubs for oprofile_perf_{init, exit} provided by . This allows cleaning of other architecture specific implementations too. Signed-off-by: Ari Kauppi Acked-by: Will Deacon Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit 67e1549447167da4607654e78a51834b36aaef86 Author: Mike Snitzer Date: Thu Jan 13 19:59:46 2011 +0000 dm mpath: disable blk_abort_queue commit 09c9d4c9b6a2b5909ae3c6265e4cd3820b636863 upstream. Revert commit 224cb3e981f1b2f9f93dbd49eaef505d17d894c2 dm: Call blk_abort_queue on failed paths Multipath began to use blk_abort_queue() to allow for lower latency path deactivation. This was found to cause list corruption: the cmd gets blk_abort_queued/timedout run on it and the scsi eh somehow is able to complete and run scsi_queue_insert while scsi_request_fn is still trying to process the request. https://www.redhat.com/archives/dm-devel/2010-November/msg00085.html Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Cc: Mike Anderson Cc: Mike Christie Signed-off-by: Greg Kroah-Hartman commit 0311355e3bbc5b3af2b54d59552ea4d36e15cb79 Author: Mike Snitzer Date: Thu Jan 13 19:53:46 2011 +0000 dm: dont take i_mutex to change device size commit c217649bf2d60ac119afd71d938278cffd55962b upstream. No longer needlessly hold md->bdev->bd_inode->i_mutex when changing the size of a DM device. This additional locking is unnecessary because i_size_write() is already protected by the existing critical section in dm_swap_table(). DM already has a reference on md->bdev so the associated bd_inode may be changed without lifetime concerns. A negative side-effect of having held md->bdev->bd_inode->i_mutex was that a concurrent DM device resize and flush (via fsync) would deadlock. Dropping md->bdev->bd_inode->i_mutex eliminates this potential for deadlock. The following reproducer no longer deadlocks: https://www.redhat.com/archives/dm-devel/2009-July/msg00284.html Signed-off-by: Mike Snitzer Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit f5830d2d1a26ac45938cd4de63a567400c2de3da Author: Amitkumar Karwar Date: Tue Jan 11 16:14:24 2011 -0800 ieee80211: correct IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK macro commit 8d661f1e462d50bd83de87ee628aaf820ce3c66c upstream. It is defined in include/linux/ieee80211.h. As per IEEE spec. bit6 to bit15 in block ack parameter represents buffer size. So the bitmask should be 0xFFC0. Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Reviewed-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit dc43a25f4bdf3189f03a06f75943f3c0121c4e11 Author: Dan Carpenter Date: Thu Jan 6 17:05:36 2011 +0300 mtd: pxa3xx_nand: NULL dereference in pxa3xx_nand_probe commit 52d039fdaa78c5a9f9bc2940ad58d7ed76b8336d upstream. "info->cmdset" gets dereferenced in __readid() so it needs to be initialized earlier in the function. This bug was introduced in 18c81b1828f8 "mtd: pxa3xx_nand: remove the flash info in driver structure". Reported-and-tested-by: Sven Neumann Signed-off-by: Dan Carpenter Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 874349687931814d5afa98081795a77ce3cd5231 Author: Thomas Gleixner Date: Sat Feb 12 11:51:03 2011 +0100 x86: Readd missing irq_to_desc() in fixup_irq() commit 5117348dea5e3ecbb785cfa1271386fb49332b41 upstream. commit a3c08e5d(x86: Convert irq_chip access to new functions) accidentally zapped desc = irq_to_desc(irq); in the vector loop. So we lock some random irq descriptor. Add it back. Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 359a11e2bb0010e60679be4f0c1415e8b1749bd7 Author: Naga Chumbalkar Date: Mon Feb 14 22:47:17 2011 +0000 x86, dmi, debug: Log board name (when present) in dmesg/oops output commit 84e383b322e5348db03be54ff64cc6da87003717 upstream. The "Type 2" SMBIOS record that contains Board Name is not strictly required and may be absent in the SMBIOS on some platforms. ( Please note that Type 2 is not listed in Table 3 in Sec 6.2 ("Required Structures and Data") of the SMBIOS v2.7 Specification. ) Use the Manufacturer Name (aka System Vendor) name. Print Board Name only when it is present. Before the fix: (i) dmesg output: DMI: /ProLiant DL380 G6, BIOS P62 01/29/2011 (ii) oops output: Pid: 2170, comm: bash Not tainted 2.6.38-rc4+ #3 /ProLiant DL380 G6 After the fix: (i) dmesg output: DMI: HP ProLiant DL380 G6, BIOS P62 01/29/2011 (ii) oops output: Pid: 2278, comm: bash Not tainted 2.6.38-rc4+ #4 HP ProLiant DL380 G6 Signed-off-by: Naga Chumbalkar Reviewed-by: Bjorn Helgaas LKML-Reference: <20110214224423.2182.13929.sendpatchset@nchumbalkar.americas.hpqcorp.net> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 9784434d04e56b3f37b378bec9b4582dbbb781aa Author: Ari Kauppi Date: Thu Jan 20 13:57:18 2011 -0500 oprofile: Fix usage of CONFIG_HW_PERF_EVENTS for oprofile_perf_init and friends commit 1ea1bdf7faa4d0b5293e605f2e1ef1c2c59f6b53 upstream. The implementations are flagged in Makefile with CONFIG_HW_PERF_EVENTS instead of CONFIG_PERF_EVENTS. Signed-off-by: Ari Kauppi Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit a59429bcfb8ef9b44478a37eafa560fe39c3f177 Author: Andy Whitcroft Date: Mon Jan 24 09:31:38 2011 -0800 Input: sysrq - ensure sysrq_enabled and __sysrq_enabled are consistent commit 8c6a98b22b750c9eb52653ba643faa17db8d3881 upstream. Currently sysrq_enabled and __sysrq_enabled are initialised separately and inconsistently, leading to sysrq being actually enabled by reported as not enabled in sysfs. The first change to the sysfs configurable synchronises these two: static int __read_mostly sysrq_enabled = 1; static int __sysrq_enabled; Add a common define to carry the default for these preventing them becoming out of sync again. Default this to 1 to mirror previous behaviour. Signed-off-by: Andy Whitcroft Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 361832885331d935a4023f9645aa5e73cc5f539d Author: Dmitry Torokhov Date: Wed Feb 2 23:04:27 2011 -0800 Revert "Input: do not pass injected events back to the originating handler" commit 9ae4345a46bdb148e32a547e89ff29563a11e127 upstream. This reverts commit 5fdbe44d033d059cc56c2803e6b4dbd8cb4e5e39. Apparently there exist userspace programs that expect to be able to "loop back" and distribute to readers events written into /dev/input/eventX and this change made for the benefit of SysRq handler broke them. Now that SysRq uses alternative method to suppress filtering of the events it re-injects we can safely revert this change. Reported-by: Kristen Carlson Accardi Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 41f834826b678e383146741b30b17c62ce247428 Author: Dmitry Torokhov Date: Wed Feb 2 22:59:54 2011 -0800 Input: sysrq - rework re-inject logic commit 7ab7b5adfb923978a2cab7bd3fac9ccf7d21cc3f upstream. Internally 'disable' the filter when re-injecting Alt-SysRq instead of relying on input core to suppress delivery of injected events to the originating handler. This allows to revert commit 5fdbe44d033d059cc56c2803e6b4dbd8cb4e5e39 which causes problems with existing userspace programs trying to loopback the events via evdev. Reported-by: Kristen Carlson Accardi Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 9e93a2ffc5ae0c527331a3600f93894547df62ec Author: Marcin Slusarz Date: Fri Jan 28 11:00:31 2011 -0500 watchdog: Fix broken nowatchdog logic commit 4135038a582c20ffdadfcf6564852e0b72a20968 upstream. Passing nowatchdog to kernel disables 2 things: creation of watchdog threads AND initialization of percpu watchdog_hrtimer. As hrtimers are initialized only at boot it's not possible to enable watchdog later - for me all watchdog threads started to eat 100% of CPU time, but they could just crash. Additionally, even if these threads would start properly, watchdog_disable_all_cpus was guarded by no_watchdog check, so you couldn't disable watchdog. To fix this, remove no_watchdog variable and use already existing watchdog_enabled variable. Signed-off-by: Marcin Slusarz [ removed another no_watchdog instance ] Signed-off-by: Don Zickus Cc: Stephane Eranian Cc: Peter Zijlstra Cc: Frederic Weisbecker LKML-Reference: <1296230433-6261-1-git-send-email-dzickus@redhat.com> Signed-off-by: Ingo Molnar commit 4cb138966a04517845f625ed142e103a9313eb9b Author: Eric Paris Date: Thu Dec 2 16:13:40 2010 -0500 SELinux: do not compute transition labels on mountpoint labeled filesystems commit 415103f9932d45f7927f4b17e3a9a13834cdb9a1 upstream. selinux_inode_init_security computes transitions sids even for filesystems that use mount point labeling. It shouldn't do that. It should just use the mount point label always and no matter what. This causes 2 problems. 1) it makes file creation slower than it needs to be since we calculate the transition sid and 2) it allows files to be created with a different label than the mount point! # id -Z staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 # sesearch --type --class file --source sysadm_t --target tmp_t Found 1 semantic te rules: type_transition sysadm_t tmp_t : file user_tmp_t; # mount -o loop,context="system_u:object_r:tmp_t:s0" /tmp/fs /mnt/tmp # ls -lZ /mnt/tmp drwx------. root root system_u:object_r:tmp_t:s0 lost+found # touch /mnt/tmp/file1 # ls -lZ /mnt/tmp -rw-r--r--. root root staff_u:object_r:user_tmp_t:s0 file1 drwx------. root root system_u:object_r:tmp_t:s0 lost+found Whoops, we have a mount point labeled filesystem tmp_t with a user_tmp_t labeled file! Signed-off-by: Eric Paris Reviewed-by: Reviewed-by: James Morris Signed-off-by: Greg Kroah-Hartman commit f6685217573ee91085867806cc89dd80fa571f58 Author: Eric Paris Date: Thu Dec 16 11:46:51 2010 -0500 SELinux: define permissions for DCB netlink messages commit 350e4f31e0eaf56dfc3b328d24a11bdf42a41fb8 upstream. Commit 2f90b865 added two new netlink message types to the netlink route socket. SELinux has hooks to define if netlink messages are allowed to be sent or received, but it did not know about these two new message types. By default we allow such actions so noone likely noticed. This patch adds the proper definitions and thus proper permissions enforcement. Signed-off-by: Eric Paris Cc: James Morris Signed-off-by: Greg Kroah-Hartman commit 44489516c52b3b76d9b2a0e670a26b6e64938ddf Author: Stefan Berger Date: Tue Jan 11 14:37:29 2011 -0500 tpm_tis: Use timeouts returned from TPM commit 9b29050f8f75916f974a2d231ae5d3cd59792296 upstream. The current TPM TIS driver in git discards the timeout values returned from the TPM. The check of the response packet needs to consider that the return_code field is 0 on success and the size of the expected packet is equivalent to the header size + u32 length indicator for the TPM_GetCapability() result + 3 timeout indicators of type u32. I am also adding a sysfs entry 'timeouts' showing the timeouts that are being used. Signed-off-by: Stefan Berger Tested-by: Guillaume Chazarain Signed-off-by: Rajiv Andrade Signed-off-by: Greg Kroah-Hartman commit 926636ad472462044f06af264031f4a776504971 Author: Rajiv Andrade Date: Fri Nov 12 22:30:02 2010 +0100 TPM: Long default timeout fix commit c4ff4b829ef9e6353c0b133b7adb564a68054979 upstream. If duration variable value is 0 at this point, it's because chip->vendor.duration wasn't filled by tpm_get_timeouts() yet. This patch sets then the lowest timeout just to give enough time for tpm_get_timeouts() to further succeed. This fix avoids long boot times in case another entity attempts to send commands to the TPM when the TPM isn't accessible. Signed-off-by: Rajiv Andrade Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 719ab9fc03934405d9342239b956b42c1d6a8b9f Author: Olof Johansson Date: Thu Jan 6 21:24:01 2011 -0600 tpm: fix panic caused by "tpm: Autodetect itpm devices" commit e5cce6c13c25d9ac56955a3ae2fd562719848172 upstream. commit 3f0d3d016d89a5efb8b926d4707eb21fa13f3d27 adds a check for PNP device id to the common tpm_tis_init() function, which in some cases (force=1) will be called without the device being a member of a pnp_dev. Oopsing and panics ensue. Move the test up to before the call to tpm_tis_init(), since it just modifies a global variable anyway. Signed-off-by: Olof Johansson Acked-by: Rajiv Andrade Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 468f3e11a872a4f83009e5128e0a3c0e287a5633 Author: Ryusuke Konishi Date: Fri Jan 21 16:40:31 2011 +0900 nilfs2: fix crash after one superblock became unavailable commit 0ca7a5b9ac5d301845dd6382ff25a699b6263a81 upstream. Fixes the following kernel oops in nilfs_setup_super() which could arise if one of two super-blocks is unavailable. > BUG: unable to handle kernel NULL pointer dereference at (null) > Pid: 3529, comm: mount.nilfs2 Not tainted 2.6.37 #1 / > EIP: 0060:[] EFLAGS: 00010202 CPU: 3 > EIP is at memcpy+0xc/0x1b > Call Trace: > [] ? nilfs_setup_super+0x6c/0xa5 [nilfs2] > [] ? nilfs_get_root_dentry+0x81/0xcb [nilfs2] > [] ? nilfs_mount+0x4f9/0x62c [nilfs2] > [] ? kstrdup+0x36/0x3f > [] ? nilfs_mount+0x0/0x62c [nilfs2] > [] ? vfs_kern_mount+0x4d/0x12c > [] ? get_fs_type+0x76/0x8f > [] ? do_kern_mount+0x33/0xbf > [] ? do_mount+0x2ed/0x714 > [] ? copy_mount_options+0x28/0xfc > [] ? sys_mount+0x72/0xaf > [] ? syscall_call+0x7/0xb Reported-by: Wakko Warner Signed-off-by: Ryusuke Konishi Tested-by: Wakko Warner LKML-Reference: <20110121024918.GA29598@animx.eu.org> Signed-off-by: Greg Kroah-Hartman commit 5b33c4a2720e314ac4c23589a301b378c13a6606 Author: Eugene Teo Date: Mon Jan 24 21:05:17 2011 -0800 net: clear heap allocation for ethtool_get_regs() commit b7c7d01aaed1f71d9afe815a569f0a81465a1744 upstream. There is a conflict between commit b00916b1 and a77f5db3. This patch resolves the conflict by clearing the heap allocation in ethtool_get_regs(). Signed-off-by: Eugene Teo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3e3742bc3d042533355fdc13dcec17deb5b584fa Author: Alan Stern Date: Tue Jan 25 20:50:07 2011 +0100 PM / Runtime: Don't enable interrupts while running in_interrupt commit c3810c88788d505d4ffd786addd111b745e42161 upstream. This patch (as1445) fixes a bug in the runtime PM core left over from the addition of the no_callbacks flag. If this flag is set then it is possible for rpm_suspend() to be called in_interrupt, so when releasing spinlocks it's important not to re-enable interrupts. To avoid an unnecessary save-and-restore of the interrupt flag, the patch also inlines a pm_request_idle() call. This fixes Bugzilla #27482. (The offending code was added in 2.6.37, so it's not necessary to apply this to any earlier stable kernels.) Signed-off-by: Alan Stern Reported-by: tim blechmann Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c4a0895efdcbc8eb1799c6f749f1b6ae16159fdc Author: Chris Mason Date: Mon Feb 7 19:21:48 2011 -0500 md_make_request: don't touch the bio after calling make_request commit e91ece5590b3c728624ab57043fc7a05069c604a upstream. md_make_request was calling bio_sectors() for part_stat_add after it was calling the make_request function. This is bad because the make_request function can free the bio and because the bi_size field can change around. The fix here was suggested by Jens Axboe. It saves the sector count before the make_request call. I hit this with CONFIG_DEBUG_PAGEALLOC turned on while trying to break his pretty fusionio card. Signed-off-by: Chris Mason Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 2fd59c6a20ef52c2e59b22a1fa7303ea4dfdc464 Author: Tejun Heo Date: Sun Jan 9 17:48:20 2011 -0500 pata_mpc52xx: inherit from ata_bmdma_port_ops commit 77c5fd19075d299fe820bb59bb21b0b113676e20 upstream. pata_mpc52xx supports BMDMA but inherits ata_sff_port_ops which triggers BUG_ON() when a DMA command is issued. Fix it. Signed-off-by: Tejun Heo Reported-by: Roman Fietze Cc: Sergei Shtylyov Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 9d175349c07facee9bb494c8f8b6ecfea952710d Author: NeilBrown Date: Fri Jan 14 09:14:34 2011 +1100 md: Fix removal of extra drives when converting RAID6 to RAID5 commit bf2cb0dab8c97f00a71875d9b13dbac17a2f47ca upstream. When a RAID6 is converted to a RAID5, the extra drive should be discarded. However it isn't due to a typo in a comparison. This bug was introduced in commit e93f68a1fc6 in 2.6.35-rc4 and is suitable for any -stable since than. As the extra drive is not removed, the 'degraded' counter is wrong and so the RAID5 will not respond correctly to a subsequent failure. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 2758704d68d5676c91b5f42c7d4c8d1f572434ff Author: NeilBrown Date: Fri Jan 14 09:14:33 2011 +1100 md: Ensure no IO request to get md device before it is properly initialised. commit 0ca69886a8273ac1350143d562280bfcbe4760dc upstream. When an md device is in the process of coming on line it is possible for an IO request (typically a partition table probe) to get through before the array is fully initialised, which can cause unexpected behaviour (e.g. a crash). So explicitly record when the array is ready for IO and don't allow IO through until then. There is no possibility for a similar problem when the array is going off-line as there must only be one 'open' at that time, and it is busy off-lining the array and so cannot send IO requests. So no memory barrier is needed in md_stop() This has been a bug since commit 409c57f3801 in 2.6.30 which introduced md_make_request. Before then, each personality would register its own make_request_fn when it was ready. This is suitable for any stable kernel from 2.6.30.y onwards. Signed-off-by: NeilBrown Reported-by: "Hawrylewicz Czarnowski, Przemyslaw" Signed-off-by: Greg Kroah-Hartman commit fbc882cceaaaa04e272225e6d4aa6322c186d48c Author: NeilBrown Date: Fri Jan 14 09:13:53 2011 +1100 md: fix regression resulting in delays in clearing bits in a bitmap commit 6c9879101442b08581e8a0e3ae6b7f643a78fd63 upstream. commit 589a594be1fb (2.6.37-rc4) fixed a problem were md_thread would sometimes call the ->run function at a bad time. If an error is detected during array start up after the md_thread has been started, the md_thread is killed. This resulted in the ->run function being called once. However the array may not be in a state that it is safe to call ->run. However the fix imposed meant that ->run was not called on a timeout. This means that when an array goes idle, bitmap bits do not get cleared promptly. While the array is busy the bits will still be cleared when appropriate so this is not very serious. There is no risk to data. Change the test so that we only avoid calling ->run when the thread is being stopped. This more explicitly addresses the problem situation. This is suitable for 2.6.37-stable and any -stable kernel to which 589a594be1fb was applied. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit ac954cef3547aa90f1f81bad9113c759a8d4bca0 Author: NeilBrown Date: Wed Jan 12 09:03:35 2011 +1100 md: fix regression with re-adding devices to arrays with no metadata commit bf572541ab44240163eaa2d486b06f306a31d45a upstream. Commit 1a855a0606 (2.6.37-rc4) fixed a problem where devices were re-added when they shouldn't be but caused a regression in a less common case that means sometimes devices cannot be re-added when they should be. In particular, when re-adding a device to an array without metadata we should always access the device, but after the above commit we didn't. This patch sets the In_sync flag in that case so that the re-add succeeds. This patch is suitable for any -stable kernel to which 1a855a0606 was applied. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 2636e659162bef783dc21d5cec6f7e06475a08e6 Author: Stanislaw Gruszka Date: Mon Jan 10 12:56:05 2011 +0100 hostap_cs: fix sleeping function called from invalid context commit 4e5518ca53be29c1ec3c00089c97bef36bfed515 upstream. pcmcia_request_irq() and pcmcia_enable_device() are intended to be called from process context (first function allocate memory with GFP_KERNEL, second take a mutex). We can not take spin lock and call them. It's safe to move spin lock after pcmcia_enable_device() as we still hold off IRQ until dev->base_addr is 0 and driver will not proceed with interrupts when is not ready. Patch resolves: https://bugzilla.redhat.com/show_bug.cgi?id=643758 Reported-and-tested-by: rbugz@biobind.com Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit db5ae97dd4056b2f0cfbcb80488ce7f89981341a Author: Anton Blanchard Date: Thu Jan 20 14:44:33 2011 -0800 kernel/smp.c: fix smp_call_function_many() SMP race commit 6dc19899958e420a931274b94019e267e2396d3e upstream. I noticed a failure where we hit the following WARN_ON in generic_smp_call_function_interrupt: if (!cpumask_test_and_clear_cpu(cpu, data->cpumask)) continue; data->csd.func(data->csd.info); refs = atomic_dec_return(&data->refs); WARN_ON(refs < 0); <------------------------- We atomically tested and cleared our bit in the cpumask, and yet the number of cpus left (ie refs) was 0. How can this be? It turns out commit 54fdade1c3332391948ec43530c02c4794a38172 ("generic-ipi: make struct call_function_data lockless") is at fault. It removes locking from smp_call_function_many and in doing so creates a rather complicated race. The problem comes about because: - The smp_call_function_many interrupt handler walks call_function.queue without any locking. - We reuse a percpu data structure in smp_call_function_many. - We do not wait for any RCU grace period before starting the next smp_call_function_many. Imagine a scenario where CPU A does two smp_call_functions back to back, and CPU B does an smp_call_function in between. We concentrate on how CPU C handles the calls: CPU A CPU B CPU C CPU D smp_call_function smp_call_function_interrupt walks call_function.queue sees data from CPU A on list smp_call_function smp_call_function_interrupt walks call_function.queue sees (stale) CPU A on list smp_call_function int clears last ref on A list_del_rcu, unlock smp_call_function reuses percpu *data A data->cpumask sees and clears bit in cpumask might be using old or new fn! decrements refs below 0 set data->refs (too late!) The important thing to note is since the interrupt handler walks a potentially stale call_function.queue without any locking, then another cpu can view the percpu *data structure at any time, even when the owner is in the process of initialising it. The following test case hits the WARN_ON 100% of the time on my PowerPC box (having 128 threads does help :) #include #include #define ITERATIONS 100 static void do_nothing_ipi(void *dummy) { } static void do_ipis(struct work_struct *dummy) { int i; for (i = 0; i < ITERATIONS; i++) smp_call_function(do_nothing_ipi, NULL, 1); printk(KERN_DEBUG "cpu %d finished\n", smp_processor_id()); } static struct work_struct work[NR_CPUS]; static int __init testcase_init(void) { int cpu; for_each_online_cpu(cpu) { INIT_WORK(&work[cpu], do_ipis); schedule_work_on(cpu, &work[cpu]); } return 0; } static void __exit testcase_exit(void) { } module_init(testcase_init) module_exit(testcase_exit) MODULE_LICENSE("GPL"); MODULE_AUTHOR("Anton Blanchard"); I tried to fix it by ordering the read and the write of ->cpumask and ->refs. In doing so I missed a critical case but Paul McKenney was able to spot my bug thankfully :) To ensure we arent viewing previous iterations the interrupt handler needs to read ->refs then ->cpumask then ->refs _again_. Thanks to Milton Miller and Paul McKenney for helping to debug this issue. [miltonm@bga.com: add WARN_ON and BUG_ON, remove extra read of refs before initial read of mask that doesn't help (also noted by Peter Zijlstra), adjust comments, hopefully clarify scenario ] [miltonm@bga.com: remove excess tests] Signed-off-by: Anton Blanchard Signed-off-by: Milton Miller Cc: Ingo Molnar Cc: "Paul E. McKenney" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 044b93a01aaf6450230cd5d006585eda1fe945a8 Author: David Dillow Date: Thu Jan 20 14:44:22 2011 -0800 fs/direct-io.c: don't try to allocate more than BIO_MAX_PAGES in a bio commit 20d9600cb407b0b55fef6ee814b60345c6f58264 upstream. When using devices that support max_segments > BIO_MAX_PAGES (256), direct IO tries to allocate a bio with more pages than allowed, which leads to an oops in dio_bio_alloc(). Clamp the request to the supported maximum, and change dio_bio_alloc() to reflect that bio_alloc() will always return a bio when called with __GFP_WAIT and a valid number of vectors. [akpm@linux-foundation.org: remove redundant BUG_ON()] Signed-off-by: David Dillow Reviewed-by: Jeff Moyer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8e1fbc87e50299cfbb0a8b0943f2e8028d9c9446 Author: Randy Dunlap Date: Thu Jan 20 14:44:31 2011 -0800 backlight: fix 88pm860x_bl macro collision commit 2550326ac7a062fdfc204f9a3b98bdb9179638fc upstream. Fix collision with kernel-supplied #define: drivers/video/backlight/88pm860x_bl.c:24:1: warning: "CURRENT_MASK" redefined arch/x86/include/asm/page_64_types.h:6:1: warning: this is the location of the previous definition Signed-off-by: Randy Dunlap Cc: Haojian Zhuang Cc: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0712c4990d19ec76ae90789e4aac1dacc7ffa79b Author: KAMEZAWA Hiroyuki Date: Tue Jan 11 16:44:01 2011 +0900 memory hotplug: one more lock on memory hotplug commit 925268a06dc2b1ff7bfcc37419a6827a0e739639 upstream. Now, memory_hotplug_(un)lock() is used for add/remove/offline pages for avoiding races with hibernation. But this should be held in online_pages(), too. It seems asymmetric. There are cases where one has to avoid a race with memory hotplug notifier and his own local code, and hotplug v.s. hotplug. This will add a generic solution for avoiding races. In other view, having lock here has no big impacts. online pages is tend to be done by udev script at el against each memory section one by one. Then, it's better to have lock here, too. Reviewed-by: Christoph Lameter Acked-by: David Rientjes Signed-off-by: KAMEZAWA Hiroyuki Signed-off-by: Pekka Enberg Signed-off-by: Greg Kroah-Hartman commit 4c9a57b6e054a139b69fe7757f7e6234170b58d3 Author: Soren Hansen Date: Thu Feb 10 15:01:28 2011 -0800 nbd: remove module-level ioctl mutex commit de1f016f882e52facc3c8609599f827bcdd14af9 upstream. Commit 2a48fc0ab242417 ("block: autoconvert trivial BKL users to private mutex") replaced uses of the BKL in the nbd driver with mutex operations. Since then, I've been been seeing these lock ups: INFO: task qemu-nbd:16115 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. qemu-nbd D 0000000000000001 0 16115 16114 0x00000004 ffff88007d775d98 0000000000000082 ffff88007d775fd8 ffff88007d774000 0000000000013a80 ffff8800020347e0 ffff88007d775fd8 0000000000013a80 ffff880133730000 ffff880002034440 ffffea0004333db8 ffffffffa071c020 Call Trace: [] __mutex_lock_slowpath+0xf7/0x180 [] mutex_lock+0x2b/0x50 [] nbd_ioctl+0x6c/0x1c0 [nbd] [] blkdev_ioctl+0x230/0x730 [] block_ioctl+0x41/0x50 [] do_vfs_ioctl+0x93/0x370 [] sys_ioctl+0x81/0xa0 [] system_call_fastpath+0x16/0x1b Instrumenting the nbd module's ioctl handler with some extra logging clearly shows the NBD_DO_IT ioctl being invoked which is a long-lived ioctl in the sense that it doesn't return until another ioctl asks the driver to disconnect. However, that other ioctl blocks, waiting for the module-level mutex that replaced the BKL, and then we're stuck. This patch removes the module-level mutex altogether. It's clearly wrong, and as far as I can see, it's entirely unnecessary, since the nbd driver maintains per-device mutexes, and I don't see anything that would require a module-level (or kernel-level, for that matter) mutex. Signed-off-by: Soren Hansen Acked-by: Serge Hallyn Acked-by: Paul Clements Cc: Arnd Bergmann Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1abdb48041f30bd8cb8f2b88636de8be88000377 Author: Michael Büsch Date: Fri Feb 4 23:34:45 2011 +0100 ssb-pcmcia: Fix parsing of invariants tuples commit dd3cb633078fb12e06ce6cebbdfbf55a7562e929 upstream. This fixes parsing of the device invariants (MAC address) for PCMCIA SSB devices. ssb_pcmcia_do_get_invariants expects an iv pointer as data argument. Tested-by: dylan cristiani Signed-off-by: Michael Buesch Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit a7c9851a1070ca85e13672c999eb36c59924263e Author: Corey Minyard Date: Thu Feb 10 16:08:38 2011 -0600 char/ipmi: fix OOPS caused by pnp_unregister_driver on unregistered driver commit d2478521afc20227658a10a8c5c2bf1a2aa615b3 upstream. This patch fixes an OOPS triggered when calling modprobe ipmi_si a second time after the first modprobe returned without finding any ipmi devices. This can happen if you reload the module after having the first module load fail. The driver was not deregistering from PNP in that case. Peter Huewe originally reported this patch and supplied a fix, I have a different patch based on Linus' suggestion that cleans things up a bit more. Cc: openipmi-developer@lists.sourceforge.net Reviewed-by: Peter Huewe Cc: Randy Dunlap Signed-off-by: Corey Minyard Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c2e884b07e6f182a66514e21eebe9260dfa20a4e Author: Oleg Nesterov Date: Tue Jan 18 17:10:32 2011 +0100 perf: Validate cpu early in perf_event_alloc() commit 66832eb4baaaa9abe4c993ddf9113a79e39b9915 upstream. Starting from perf_event_alloc()->perf_init_event(), the kernel assumes that event->cpu is either -1 or the valid CPU number. Change perf_event_alloc() to validate this argument early. This also means we can remove the similar check in find_get_context(). Signed-off-by: Oleg Nesterov Acked-by: Peter Zijlstra Cc: Alan Stern Cc: Arnaldo Carvalho de Melo Cc: Frederic Weisbecker Cc: Paul Mackerras Cc: Prasad Cc: Roland McGrath LKML-Reference: <20110118161032.GC693@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ccb6b70738a85a74512d1b74539d22d61120acbf Author: Oleg Nesterov Date: Tue Jan 18 17:10:08 2011 +0100 perf: Find_get_context: fix the per-cpu-counter check commit 22a4ec729017ba613337a28f306f94ba5023fe2e upstream. If task == NULL, find_get_context() should always check that cpu is correct. Afaics, the bug was introduced by 38a81da2 "perf events: Clean up pid passing", but even before that commit "&& cpu != -1" was not exactly right, -ESRCH from find_task_by_vpid() is not accurate. Signed-off-by: Oleg Nesterov Acked-by: Peter Zijlstra Cc: Alan Stern Cc: Arnaldo Carvalho de Melo Cc: Frederic Weisbecker Cc: Paul Mackerras Cc: Prasad Cc: Roland McGrath LKML-Reference: <20110118161008.GB693@redhat.com> Signed-off-by: Ingo Molnar