Permalink
Commits on Feb 20, 2011
  1. fix merge conflict

    Oleksandr Natalenko committed Feb 20, 2011
  2. Merge branch 'configs-2.6.37' into pf-2.6.37

    Oleksandr Natalenko committed Feb 20, 2011
  3. Merge branch 'bfq-2.6.37' into pf-2.6.37

    Oleksandr Natalenko committed Feb 20, 2011
  4. ck-2.6.37: add patched 2.6.37-ck2 patchset

    Oleksandr Natalenko committed Feb 20, 2011
Commits on Feb 19, 2011
  1. configs-2.6.37: update Dell Inspiron 1525 laptop config

    Oleksandr Natalenko committed Feb 19, 2011
  2. version-2.6.37: bump to v2.6.37-pf3

    Oleksandr Natalenko committed Feb 19, 2011
Commits on Feb 18, 2011
  1. Merge branch 'stable' into combined

    Nigel Cunningham committed Feb 18, 2011
    Conflicts:
    	mm/vmscan.c
Commits on Feb 17, 2011
  1. Linux 2.6.37.1

    gregkh committed Feb 17, 2011
  2. xhci: Use GFP_NOIO during device reset.

    Sarah Sharp committed with gregkh Dec 28, 2010
    commit a6d940d 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 <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. usb: Realloc xHCI structures after a hub is verified.

    Sarah Sharp committed with gregkh Dec 23, 2010
    commit 653a39d 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 <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. xhci: Do not run xhci_cleanup_msix with irq disabled

    zhang-rui committed with gregkh Dec 17, 2010
    commit 40a9fb1 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]  [<ffffffff8104156a>] __might_sleep+0xeb/0xf0
    [  134.882921]  [<ffffffff814763dc>] mutex_lock+0x24/0x50
    [  134.884229]  [<ffffffff810a745c>] free_desc+0x2e/0x5f
    [  134.885538]  [<ffffffff810a74c8>] irq_free_descs+0x3b/0x71
    [  134.886853]  [<ffffffff8102584d>] free_irq_at+0x31/0x36
    [  134.888167]  [<ffffffff8102723f>] destroy_irq+0x69/0x71
    [  134.889486]  [<ffffffff8102747a>] native_teardown_msi_irq+0xe/0x10
    [  134.890820]  [<ffffffff8124c382>] default_teardown_msi_irqs+0x57/0x80
    [  134.892158]  [<ffffffff8124be46>] free_msi_irqs+0x8b/0xe9
    [  134.893504]  [<ffffffff8124cd46>] pci_disable_msix+0x35/0x39
    [  134.894844]  [<ffffffffa01b444a>] xhci_cleanup_msix+0x31/0x51 [xhci_hcd]
    [  134.896186]  [<ffffffffa01b4b3a>] xhci_stop+0x3a/0x80 [xhci_hcd]
    [  134.897521]  [<ffffffff81341dd4>] usb_remove_hcd+0xfd/0x14a
    [  134.898859]  [<ffffffff813500ae>] usb_hcd_pci_remove+0x5c/0xc6
    [  134.900193]  [<ffffffff8123c606>] pci_device_remove+0x3f/0x91
    [  134.901535]  [<ffffffff812e7ea4>] __device_release_driver+0x83/0xd9
    [  134.902899]  [<ffffffff812e8571>] driver_detach+0x86/0xad
    [  134.904222]  [<ffffffff812e7d56>] bus_remove_driver+0xb2/0xd8
    [  134.905540]  [<ffffffff812e8633>] driver_unregister+0x6c/0x74
    [  134.906839]  [<ffffffff8123c8e4>] pci_unregister_driver+0x44/0x89
    [  134.908121]  [<ffffffffa01b940e>] xhci_unregister_pci+0x15/0x17 [xhci_hcd]
    [  134.909396]  [<ffffffffa01bd7d2>] xhci_hcd_cleanup+0xe/0x10 [xhci_hcd]
    [  134.910652]  [<ffffffff8107fcd1>] sys_delete_module+0x1ca/0x23b
    [  134.911882]  [<ffffffff81123932>] ? path_put+0x22/0x26
    [  134.913104]  [<ffffffff8109a800>] ? audit_syscall_entry+0x2c/0x148
    [  134.914333]  [<ffffffff8100ac82>] 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 <rui.zhang@intel.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. xHCI: synchronize irq in xhci_suspend()

    Andiry Xu committed with gregkh Dec 27, 2010
    commit 0029227 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 <mjg@redhat.com>
    Signed-off-by: Andiry Xu <andiry.xu@amd.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. xhci: Resume bus on any port status change.

    Sarah Sharp committed with gregkh Dec 14, 2010
    commit 7111ebc 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 <sarah.a.sharp@linux.intel.com>
    Reported-by: Jon 'maddog' Hall <maddog@li.org>
    Tested-by: Andiry Xu <andiry.xu@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. drm/i915: Only bind to function 0 of the PCI device

    ickle committed with gregkh Feb 1, 2011
    commit 5fe49d8 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 934f992 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 <wferi@niif.hu>
    Tested-by: Ferenc Wágner <wferi@niif.hu>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28012
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. agp: ensure GART has an address before enabling it

    skitt committed with gregkh Jan 31, 2011
    commit a70b95c 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 96576a9 ("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 <steve@sk2.org>
    Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
    Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
    Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
    Cc: Kulikov Vasiliy <segooon@gmail.com>
    Cc: Florian Mickler <florian@mickler.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. drm: Only set DPMS ON when actually configuring a mode

    keith-packard committed with gregkh Feb 4, 2011
    commit 811aaa5 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 <keithp@keithp.com>
    Reported-and-tested-by: Carlos R. Mafra <crmafra2@gmail.com>
    Tested-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask…

    Suresh Siddha committed with gregkh Feb 3, 2011
    … after switching mm
    
    commit 831d52b 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 <suresh.b.siddha@intel.com>
    Acked-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. drm/i915: Recognise non-VGA display devices

    ickle committed with gregkh Jan 20, 2011
    commit 934f992 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 <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. drm/i915: Add dependency on CONFIG_TMPFS

    ickle committed with gregkh Jan 20, 2011
    commit f7ab9b4 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:  [<c1074061>] ? do_read_cache_page+0x71/0x160
    Jan 19 22:52:26 harlie kernel:  [<c107416f>] ? read_cache_page_gfp+0x1f/0x30
    Jan 19 22:52:26 harlie kernel:  [<f8d620ed>] ? i915_gem_object_get_pages+0xad/0x1d0 [i915]
    Jan 19 22:52:26 harlie kernel:  [<f8d637ab>] ? i915_gem_object_bind_to_gtt+0xeb/0x2d0 [i915]
    Jan 19 22:52:26 harlie kernel:  [<f8d65961>] ? i915_gem_object_pin+0x151/0x190 [i915]
    Jan 19 22:52:26 harlie kernel:  [<c11e16ed>] ? drm_gem_object_init+0x3d/0x60
    Jan 19 22:52:26 harlie kernel:  [<f8d65aa5>] ? i915_gem_init_ringbuffer+0x105/0x1e0 [i915]
    Jan 19 22:52:26 harlie kernel:  [<f8d571b7>] ? i915_driver_load+0x667/0x1160 [i915]
    
    Reported-by: John J. Stimson-III <john@idsfa.net>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. drm/i915/lvds: Add AOpen i915GMm-HFS to the list of false-positive LVDS

    knupero committed with gregkh Jan 14, 2011
    commit 22ab70d upstream.
    
    Signed-off-by: Knut Petersen <knut_petersen@t-online.de>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. drm/i915/panel: The backlight is enabled if the current value is non-…

    Indanz committed with gregkh Jan 12, 2011
    …zero
    
    commit c8303e7 upstream.
    
    ... and not if the maximum is non-zero. This fixes the typo introduced
    in 47356eb 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 <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. drm/i915/panel: Only record the backlight level when it is enabled

    ickle committed with gregkh Jan 11, 2011
    commit 47356eb 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 <raa.lkml@gmail.com>
    Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. drm/i915: fix calculation of eDP signal levels on Sandybridge

    Yuanhan Liu committed with gregkh Jan 6, 2011
    commit 3c5a62b 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 <yuanhan.liu@linux.intel.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. drm/i915/crt: Check for a analog monitor in case of DVI-I

    David Müller committed with gregkh Jan 6, 2011
    commit f5afcd3 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 <d.mueller@elsoft.ch>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. drm/i915/sdvo: Defer detection of output capabilities until probing

    ickle committed with gregkh Jan 4, 2011
    commit 97aaf91 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 <alex@eyeos.org>
    Tested-by: Alex Fiestas <alex@eyeos.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32828
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. drm/i915: check eDP encoder correctly when setting modes

    jbarnes993 committed with gregkh Jan 4, 2011
    commit 858bc21 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 <jbarnes@virtuousgeek.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31988
    Tested-by: Jan-Hendrik Zab <jan@jhz.name>
    Tested-by: Christoph Lukas <christoph.lukas@gmx.net>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. drm: Restore the old_fb upon modeset failure

    ickle committed with gregkh Jan 8, 2011
    commit 0ba41e4 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:[<f86fda5e>] 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]  [<f87045d8>] ? intel_crtc_disable+0x36/0x41 [i915]
    [ 6033.229012]  [<f7fd8091>] ?  drm_helper_disable_unused_functions+0xcd/0xf9 [drm_kms_helper]
    [ 6033.229012]  [<f7fd9377>] ? drm_crtc_helper_set_config+0x62a/0x7f7 [drm_kms_helper]
    [ 6033.229012]  [<c04daa10>] ? __slab_free+0x1b/0xa4
    [ 6033.229012]  [<f7fd7e62>] ? drm_fb_helper_initial_config+0x466/0x497 [drm_kms_helper]
    [ 6033.229012]  [<f7fd7ea3>] ? drm_fb_helper_restore+0x10/0x2a [drm_kms_helper]
    [ 6033.229012]  [<f86f2577>] ? i915_driver_lastclose+0x2a/0x57 [i915]
    [ 6033.229012]  [<f7f1989f>] ? drm_lastclose+0x45/0x23e [drm]
    [ 6033.229012]  [<f7f1a0b4>] ? drm_release+0x462/0x4d7 [drm]
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. drm/radeon/kms: fix s/r issues with bios scratch regs

    Alex Deucher committed with gregkh Feb 3, 2011
    commit 8736476 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 <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. drm/radeon/kms/evergreen: always set certain VGT regs at CP init

    Alex Deucher committed with gregkh Feb 2, 2011
    commit 18ff84d 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 <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. drm/radeon: remove 0x4243 pci id

    Alex Deucher committed with gregkh Feb 2, 2011
    commit 63a5078 upstream.
    
    0x4243 is a PCI bridge, not a GPU.
    
    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=33815
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. drm/radeon/kms: Enable new pll calculation for avivo+ asics

    Alex Deucher committed with gregkh Jan 31, 2011
    commit 619efb1 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 <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. drm/radeon/kms: add new pll algo for avivo asics

    Alex Deucher committed with gregkh Jan 31, 2011
    commit f523f74 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 <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. drm/radeon/kms: add pll debugging output

    Alex Deucher committed with gregkh Jan 31, 2011
    commit 51d4bf8 upstream.
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. drm/radeon/kms: switch back to min->max pll post divider iteration

    Alex Deucher committed with gregkh Jan 31, 2011
    commit a6f9761 upstream.
    
    Seems more reliable.  Fixes:
    https://bugzilla.kernel.org/show_bug.cgi?id=26552
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>