Bug 43090

Summary: [snb] Resume fails - black screen and movable mouse cursor after opening the laptop lid -
Product: Drivers Reporter: M8R-bs3gdy
Component: Video(DRI - Intel)Assignee: Jesse Barnes (jbarnes)
Status: RESOLVED CODE_FIX    
Severity: high CC: acpi-bugzilla, chris, daniel, drspinderwalf, e.a.b.piel, lenb
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.2.0-22.35 and 3.4.0-030400rc2.201204072235 Subsystem:
Regression: Yes Bisected commit-id:

Description M8R-bs3gdy 2012-04-11 16:05:34 UTC
As the summary says, the sleep does not work anymore. The screen either stays black or the wallpaper can be seen with the mouse cursor, but nothing else shows up. I can change to a different console with ctrl+alt+f1 after opening the lid and reboot the machine from there.

Older 3.0.0-17 kernel works as expected.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/977135
Comment 1 Len Brown 2012-04-24 02:59:19 UTC
okay, so according to ubuntu
3.2.0-22-generic x86_64
is the kernel that fails.
Can you reproduce this with an upstream-built kernel?
If so, can you bisect where the breakage first started?
Comment 2 M8R-bs3gdy 2012-05-02 18:13:49 UTC
3.4.0-030400rc2 was also broken and it happens every time with the new 3.2.0-24. For some reason suspending works about 70% of the time with 3.2.0-23. Only 3.0.0-17 works perfectly.
Comment 3 Éric Piel 2012-05-02 21:42:43 UTC
As mentioned in the ubuntu bug report, it seems it's related to the intel driver. In addition, I've also experienced this bug and IIRC it happened also just after a screen blanking. So I'd suggest to reassign to intel/i965. Actually the bug might be in the xorg intel driver and/or compiz...
Comment 4 Daniel Vetter 2012-06-05 17:22:30 UTC
Ok, this needs a bit of an infodump:
- please boot with drm.debug=0xe attached to the kernel, reproduce the issue and attach the complete dmesg to this bug. Please do this in the latest upstream kernel you can get your hands on.
- it sounds like only the backlight went dead and everything else still works. Can you please confirm that Xorg doesn't crash (check Xorg.log) or that anything else bad happens? Also, is there anyway to unblack the screen (vt-switching, hotplugging a new connector, running xrandr --output LVDS1 --auto blind, ...)?
- as Len Brown already said, bisect highly appreciated. Although if 3.2 only sometimes reproduces the issue, it might be hard to pinpoint it exactly.
- I have a new git branch with some backlight patches which might apply:

http://cgit.freedesktop.org/~danvet/drm/log/?h=backlight-confusion
Comment 5 Daniel Vetter 2012-08-28 09:02:22 UTC
Ping for the info-dump. Also please retest on a more recent kernel, preferrably the latest 3.6-rc (since that contains a few fixes in this area).
Comment 6 Éric Piel 2012-10-04 12:45:21 UTC
Probably fixed by commits from Chris Wilson available in xf86-video-intel 2.20.9.

See:
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=5a45cbacb777e478d8fbda9223b0fb5c705d7249
Comment 7 Chris Wilson 2012-10-18 14:26:08 UTC
Also requires commit 5bb61643f6a70d48de9cfe91ad0fee0d618b6816
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Sep 27 21:25:58 2012 +0100

    drm/i915: Flush the pending flips on the CRTC before modification
    
    This was meant to be the purpose of the
    intel_crtc_wait_for_pending_flips() function which is called whilst
    preparing the CRTC for a modeset or before disabling. However, as Ville
    Syrjala pointed out, we set the pending flip notification on the old
    framebuffer that is no longer attached to the CRTC by the time we come
    to flush the pending operations. Instead, we can simply wait on the
    pending unpin work to be finished on this CRTC, knowning that the
    hardware has therefore finished modifying the registers, before proceeding
    with our direct access.