18 Feb, 2011
40 commits
-
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 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 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 disabledand 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 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 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 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 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 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 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 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 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:[] 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 22ab70d3262ddb6e69b3c246a34e2967ba5eb1e8 upstream.
Signed-off-by: Knut Petersen
Signed-off-by: Chris Wilson
Signed-off-by: Greg Kroah-Hartman -
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 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 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 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 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 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 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 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=26942Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
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 63a507800c8aca5a1891d598ae13f829346e8e39 upstream.
0x4243 is a PCI bridge, not a GPU.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=33815Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
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=32556Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
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 51d4bf840a27fe02c883ddc6d9708af056773769 upstream.
Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit a6f9761743bf35b052180f4a8bdae4d2cc0465f6 upstream.
Seems more reliable. Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=26552Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
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 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 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 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=32732Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit f598aa7593427ffe3a61e7767c34bd695a5e7ed0 upstream.
Reported-by: 屋国遥
Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
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 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 09c9d4c9b6a2b5909ae3c6265e4cd3820b636863 upstream.
Revert commit 224cb3e981f1b2f9f93dbd49eaef505d17d894c2
dm: Call blk_abort_queue on failed pathsMultipath 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 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.htmlSigned-off-by: Mike Snitzer
Signed-off-by: Mikulas Patocka
Signed-off-by: Alasdair G Kergon
Signed-off-by: Greg Kroah-Hartman -
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 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 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 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 G6After 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 G6Signed-off-by: Naga Chumbalkar
Reviewed-by: Bjorn Helgaas
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
