drm-intel-next: 96451cf38c42026ded809c29858fa1b95e1d4d7d (+ a few "harmless" patches which haven't affected the issue) xserver-xorg-video-intel 2:2.10.0~git20100104.09103514-0ubuntu0sarvatt libdrm libdrm-2.4.17+git20091230.c5c503b5 (+ a patch to avoid a mode-set probe crash, that hasn't affected the behaviour) Something "recently" has caused my machine to lock-up / hang / leave its backlight off when the lid is opened. HP are awful on ACPI bios stuff as far as I can tell, and some of the recent changes to lid handling seem to have upset it. I don't have my machine set to suspend on lid close. Should I attach my DSDT? Symptoms vary - sometimes it works fine, other times the backlight doesn't shut off when closing the lid, only to blink and mode-set when I re-open the lid. Other times, closing the lid causes the screen to go black and stay black. (Although Sys-Req worked). At least one occasion, I've seen it leave the LVDS active, but not enable the backlight. I know this is an awful bug report, containing no substance with which to identify the problem, but I thought I'd mention the issue as a heads-up.. I'll try to get round to debugging / bisecting it when I have some time.
Created attachment 32471 [details] dmesg after a lid close / reopen I just tried it now, and managed to get my screen back (after some fiddling with the video button / brightness keys). I got a load of glyph corruption, + various nastiness in Xorg.0.log and dmesg.
Created attachment 32472 [details] Xorg.0.log following lid close / reopen
Created attachment 32473 [details] Xorg.0.log from a lock (machine was still SSH'able)
Created attachment 32474 [details] GPU dump following lock on lid close
More information.. With plain non-compositing window manager: I close the lid -> screen off I open the lid -> screen stays off Press Fn+F4 (video button) -> Screen blinks, and comes back on With compiz: I close the lid -> screen off I open the lid -> screen stays off, and somewhere along the line things lockup. Press Fn+F4 (video button) -> No effect. (Although admitedly, _sometimes_ I've managed to get it back, even whilst running compiz)
More analysis... Noting in the Xorg.0.log, the: [ 4580.611329] (II) PM Event received: Capability Changed I830PMEvent: Capability change Lines.. I looked at the 2D driver (and Xorg server). It would seem that the APM capability change event (coming from "somewhere" on these lid events), is triggering the SaveScreens driver hook, which calls xf86SaveScreens, and is calling driver dpms functions on the output, presumably eventually calling KMS ioctls (but I'm guessing here). By hard-wiring the KMS intel_lvds_detect function tol return LvDS as always connected, things are better - but not correct. When I close the lid, the screen blanks, but shortly after, it powers back up. (somtimes). It doesn't seem to be "just" a DPMS blank though, as wiggling the mouse whilst the screen is closed doesn't light it up again. When I lift the lid, the screen lights, blanks and re-lights (possibly a number of times), before settling down. The issue sounds very similar to those in: http://bugzilla.kernel.org/show_bug.cgi?id=14484 Including the relation to compiz, some of the lockups etc.. only I'm not actually suspending / resuming at all, just operating the lid. I blame HP personally.. my last HP laptop had a real dogs dinner of a DSDT when it came to lid events, and I bet this one is crazy too.
With a little bit of instrumentation added (so you will spot the lid events), you can see I also get the corrupted modes: dmesg | grep -v 480i | grep drm [ 2.139406] [drm] Initialized drm 1.1.0 20060810 [ 2.162702] [drm] set up 63M of stolen space [ 2.285999] [drm] lid notifier registered [ 2.757593] fb0: inteldrmfb frame buffer device [ 2.762934] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 2.840180] [drm] LVDS-8: set mode 1680x1050 1f [ 19.932528] [drm] LVDS-8: set mode 1680x1050 1f [ 93.325157] [drm] Called connector->funcs->detect(), and we got 1 [ 93.325335] [drm] Lid closed, setting modeset_on_lid=1 [ 94.000217] [drm] LVDS-8: set mode 24 [ 97.789221] [drm] Called connector->funcs->detect(), and we got 1 [ 97.789433] [drm] About to drm_helper_resume_force_mode() [ 98.012328] [drm] LVDS-8: set mode 24 [ 98.984828] [drm] LVDS-8: set mode 25 [ 102.268289] [drm] LVDS-8: set mode 26 [ 124.325183] [drm] Called connector->funcs->detect(), and we got 1 [ 124.325361] [drm] Lid closed, setting modeset_on_lid=1 [ 124.984174] [drm] LVDS-8: set mode 27 [ 130.009012] [drm] Called connector->funcs->detect(), and we got 1 [ 130.009223] [drm] About to drm_helper_resume_force_mode() [ 130.232311] [drm] LVDS-8: set mode 27 [ 134.152269] [drm] LVDS-8: set mode 28 [ 135.216335] [drm] LVDS-8: set mode 29 [ 839.297174] [drm] Called connector->funcs->detect(), and we got 1 [ 839.297357] [drm] Lid closed, setting modeset_on_lid=1 [ 846.148107] [drm] Called connector->funcs->detect(), and we got 1 [ 846.148308] [drm] About to drm_helper_resume_force_mode() [ 846.244226] [drm] LVDS-8: set mode 29 [ 846.884234] [drm] LVDS-8: set mode 2a [ 851.437250] [drm] Called connector->funcs->detect(), and we got 1 [ 851.437431] [drm] Lid closed, setting modeset_on_lid=1 [ 852.144257] [drm] LVDS-8: set mode 2b [ 854.508766] [drm] Called connector->funcs->detect(), and we got 1 [ 854.508874] [drm] About to drm_helper_resume_force_mode() [ 854.756292] [drm] LVDS-8: set mode 2b [ 857.281007] [drm] Called connector->funcs->detect(), and we got 1 [ 857.281190] [drm] Lid closed, setting modeset_on_lid=1 [ 857.960326] [drm] LVDS-8: set mode 2c [ 859.497235] [drm] Called connector->funcs->detect(), and we got 1 [ 859.497442] [drm] About to drm_helper_resume_force_mode() [ 859.720217] [drm] LVDS-8: set mode 2c [ 860.764252] [drm] LVDS-8: set mode 2d [ 864.181250] [drm] Called connector->funcs->detect(), and we got 1 [ 864.181437] [drm] Lid closed, setting modeset_on_lid=1 [ 871.681211] [drm] Called connector->funcs->detect(), and we got 1 [ 871.681416] [drm] About to drm_helper_resume_force_mode() [ 871.800191] [drm] LVDS-8: set mode 2d [ 872.472339] [drm] LVDS-8: set mode 2e [ 873.556216] [drm] LVDS-8: set mode 2f [ 875.112277] [drm] LVDS-8: set mode 30 [ 876.168221] [drm] LVDS-8: set mode 31 [ 877.752314] [drm] LVDS-8: set mode 32 [ 878.856116] [drm] LVDS-8: set mode 33
Would it be worth instrumenting various entry-points (including interrupts?) into the KMS driver, with incrementing numerals, (printing enter and leave with the numer), such that any race between them can be identified?
Hm, wonder if we need the PM event stuff at all anymore... Does this work around the issue? Might explain some of the other lid bugs we've been seeing recently... diff --git a/src/i830_driver.c b/src/i830_driver.c index e94a60c..71b881a 100644 --- a/src/i830_driver.c +++ b/src/i830_driver.c @@ -1633,13 +1633,6 @@ static Bool I830PMEvent(int scrnIndex, pmEvent event, Boo SaveScreens(SCREEN_SAVER_FORCER, ScreenSaverReset); } break; - /* This is currently used for ACPI */ - case XF86_APM_CAPABILITY_CHANGED: - ErrorF("I830PMEvent: Capability change\n"); - - SaveScreens(SCREEN_SAVER_FORCER, ScreenSaverReset); - - break; default: ErrorF("I830PMEvent: received APM event %d\n", event); }
No discernable change I'm afraid. With compiz running, my computer hard-locked on lid-open (I think, but can't be sure - as I didn't have anything to log in via SSH from at the time). With no compiz, the display didn't light up when I opened the lid, but _did_ when I changed to VT1. When switching back to X on VT7, the gnome-randr properties thing had popped up a notification message saying something along the lines "Couldn't set display on CRT 64"
This might help... If I echo 7 > /proc/acpi/video/GFX0/DOS then the issue goes away (with / without compiz). NB: I'm still running the above patch, if that makes a difference. The default DOS value is 4.
And by "default", I mean.. the Ubuntu Kernel patches video.c to default _DOS to 4. Upstream default is 0 I think.
Yeah it sounds like you're getting all sorts of lid events that may or may not have correct status associated with them. What if you blacklist your machine to both ignore LID events *and* current status? Presumably that brings things back to the old, working behavior?
Not the info requested, I know.. but a change. I've popped off Chris Wilson's patches to try and gather GPU crash dumps - and I don't get a complete lockup now, even with Compiz. I just get a GPU hang. Switching ot VT1 and back "fixes" the problem, with this in dmesg: [47154.320220] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47154.320234] render error detected, EIR: 0x00000000 [47154.320600] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943643 at 8943642) [47154.652223] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47154.652237] render error detected, EIR: 0x00000000 [47154.652360] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943650 at 8943642) [47154.976224] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47154.976238] render error detected, EIR: 0x00000000 [47154.976363] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943651 at 8943642) [47155.308205] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47155.308219] render error detected, EIR: 0x00000000 [47155.308538] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943663 at 8943642) [47155.636212] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47155.636225] render error detected, EIR: 0x00000000 [47155.636575] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943668 at 8943642) [47155.960223] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47155.960237] render error detected, EIR: 0x00000000 [47155.960289] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943673 at 8943642) [47156.288222] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47156.288235] render error detected, EIR: 0x00000000 [47156.288276] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943689 at 8943642) [47156.328433] Skipping EDID probe due to cached edid [47156.612226] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47156.612240] render error detected, EIR: 0x00000000 [47157.084224] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47157.084238] render error detected, EIR: 0x00000000 [47157.084286] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943710 at 8943642) [47157.408176] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47157.408189] render error detected, EIR: 0x00000000 [47157.408227] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943713 at 8943642) [47157.744220] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47157.744234] render error detected, EIR: 0x00000000 [47157.744272] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943728 at 8943642) [47158.068220] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47158.068233] render error detected, EIR: 0x00000000 [47158.068271] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943729 at 8943642) [47158.404219] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47158.404233] render error detected, EIR: 0x00000000 [47158.404297] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943743 at 8943642) [47158.740217] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47158.740231] render error detected, EIR: 0x00000000 [47158.740292] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943745 at 8943642) [47159.064216] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47159.064229] render error detected, EIR: 0x00000000 [47159.064281] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943755 at 8943642) [47159.412221] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47159.412235] render error detected, EIR: 0x00000000 [47159.412287] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943756 at 8943642) [47159.740209] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47159.740222] render error detected, EIR: 0x00000000 [47159.740285] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943777 at 8943642) [47160.068230] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47160.068243] render error detected, EIR: 0x00000000 [47160.068613] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943780 at 8943642) [47160.684224] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [47160.684238] render error detected, EIR: 0x00000000 [47160.684367] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 8943782 at 8943642)
Are you still having lid related issues and hangs?
I'm not seeing it hang any more. I just tried a couple of open/close cycles, and things seem to be better. I'm running (basically) git HEAD 2D driver, c374c94e41d6e7d677334171e3255778d77cbe18 (with a couple of patches to fix a graphics corruption due to pixman not blitting in some cases). Kernel wise, I'm using what Ubuntu have back-ported, plus this patch: commit c36a2a6de59e4a141a68b7575de837d3b0bd96b3 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Apr 17 15:12:03 2010 +0200 drm/i915: fix tiling limits for i915 class hw v2 However - I'm not certain things are 100% correct, since I still sometimes have a lag between shutting the screen and the backlight reacting, and again opening it, there is often a lot of blinking as if there are mode-sets going on. Sometimes after closing / re-opening the lid, there is an intermittent glitch / tear towards the bottom of the screen (I noticed it on the left hand edge). Perhaps there still needs to be more locking around the DRM ioctls for mode-setting.
(And I should point out.. this is Ubuntu Lucid RC, so 2.6.32 with DRM stack from 2.6.33 AIUI.
The extra flicker you saw may have been due to extra mode sets. At open time we used to send an event to userspace, which may have triggered the GNOME display system to reset things to a new (probably identical) state. We don't send the event anymore, but we still try to force the mode back to what it was before because some laptop BIOSes will shut things off at close time. If that's what you're seeing, we could add a whitelist to avoid forcing a mode set for your laptop, assuming it's unnecessary.
Any news on the last comment? Did you try removing the force modeset at lid time?
I guess this is fixed now.
Yes, sorry Jesse - I've been snowed under with other things, but had meant to follow up on this. With the latest drivers, I'm not seeing too much of a problem. Perhaps an extra mode-set which isn't required, but nothing too disruptive. Thanks for looking at the problem.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.