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.
okay, so according to ubuntu
is the kernel that fails.
Can you reproduce this with an upstream-built kernel?
If so, can you bisect where the breakage first started?
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.
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...
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:
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).
Probably fixed by commits from Chris Wilson available in xf86-video-intel 2.20.9.
Also requires commit 5bb61643f6a70d48de9cfe91ad0fee0d618b6816
Author: Chris Wilson <firstname.lastname@example.org>
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.