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
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? 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: http://cgit.freedesktop.org/~danvet/drm/log/?h=backlight-confusion 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. See: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=5a45cbacb777e478d8fbda9223b0fb5c705d7249 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. |