[gm45] "*ERROR* Execbuf while wedged" when closing laptop lid with compiz running

dmesg after opening the lid again

This may be a duplicate of https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/503255, but since I can't reproduce this by running xrandr, I filed a new bug.

I followed the instructions on https://wiki.ubuntu.com/X/Troubleshooting/Freeze on how to get a batchbuffer dump, unfortunately i915_batchbuffers is empty.
I inserted "export INTEL_DEBUG=batch into /etc/init/gdm.conf, right before "exec gdm-binary $CONFIG_FILE", does this suffice?

It's recoverable with xorg-edgers (either that, or the update to kernel 2.6.32-10)! The display is still blank (backlight off) after opening the lid again, but vt-switching makes the display usable again, with compiz and everything.
Attaching dmesg output and Xorg.0.log.

xserver-xorg-video-intel 2.10.0+git20100108.4902f546-0ubuntu0sarvatt

Alright, crashing with 2.9.1-1ubuntu1 as usual, recoverable with 2.10.0+git20100108.4902f546-0ubuntu0sarvatt by switching VTs.

the update to kernel 2.6.32-10 does not fix it in my case, I will try to install xorg edgers ppa to confirm the workaround

Unfortunately the xorg edgers ppa does not fix the problem in my case, even if we have the same laptop and the same error.
There's still the same error and dmesg output, not recoverable with vt switches.
did you install anything else?
thanks

I was testing the 2.6.33 kernel from the mainline kernel-ppa yesterday, but have since reverted back to 2.6.32. The funny thing is that I was also testing xorg-edgers yesterday and IIRC I also tried vt-switching to enable my display again, which didn't work.

I have no idea why it is working today, but it did so consistently across several reboots.

I tried it several times more, sometimes the vt-switching workaround was working, sometimes it wasn't. I tried opening the lid immediately after closing it, waiting a bit before opening it and even tried running glxgears while I was closing it, I couldn't find a pattern.
I even got 2.9.1-1ubuntu1 to work with the vt-switching :/ This is also happening on a fresh and up-to-date installation of Lucid I did for reference.

It's a kernel bug. It works fine with 2.6.31 but not with 2.6.32.

I tried to narrow it down using the daily builds:
http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2009-09-12/
http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2009-10-01/

2.6.31 from 2009-09-12 works, 2.6.32-rc1 from 2009-10-01 doesn't. Unfortunately there don't seem to be builds in between.

I'm not sure it's caused by the kernel, because when I boot with
2.6.31 the screen does not blank when I close the lid (please check if
yours does).
Mine only does a flash, then if I look in the little space between the
lid and the laptop body I see it's still on and bright.

My screen blanks and stays off, but I'm currently running a self-compiled version of 2.6.31 (I'm trying to bisect), so I don't know how the stock 2.6.31 behaves here. I can try it later, it's compiling at the moment :)

I have to confirm: I have downloaded from the mainline kernel archive
2.6.31.11 and booted it. It has no problems.
I have also tried 2.6.33rc3, 2.6.32.3 and 2.6.32.0, but they are the same

I also discovered that when the bug occurs, Xorg is at 99% of cpu.
Killing xorg fixes the problem. So I'll add Xorg package to the bug.
I could not obtain a backtrace because ubuntu does not find dbg
symbols, although I have installed the corresponding -dbg packages

dmesg with drm debug = 1 after (only the lid has been opened)

xorg partial bt (debugging symbols were not detected, but installed).

OT: did you file another bug for the VT switch problem?

No, I didn't, just this one.

OT: this is the bug I filed, please confirm it
https://bugs.launchpad.net/linux/+bug/488328

Okay, bisecting ended with:

11ed50ec2a316928c2bacc1149bded86c6a96068 is the first bad commit
commit 11ed50ec2a316928c2bacc1149bded86c6a96068
Author: Ben Gamari <email address hidden>
Date: Mon Sep 14 17:48:45 2009 -0400

    drm/i915: Implement GPU reset on i965

    This patch puts in place the machinery to attempt to reset the GPU. This
    will be used when attempting to recover from a GPU hang.

    Signed-off-by: Owain G. Ainsworth <email address hidden>
    Signed-off-by: Ben Gamari <email address hidden>
    Signed-off-by: Jesse Barnes <email address hidden>

:040000 040000 b692598aa1c95929f7ccfdba078c497161c70e06 edcb7cbb5473940449b517c0950a316d4c7989d3 M drivers

So.. Could it be that the driver erroneously thinks that the GPU hangs, although it doesn't?

Does this commit break also the other bug (the one solvable with a VT switch?)

Sorry, malformed question: does the kernel without that commit also fix the other bug (the one solvable with a VT switch)?

The kernel without that commit had no problems with either compiz or metacity. Closing the display lid disabled the backlight, opening the lid turned the backlight on again. No error messages from the kernel, everything worked just fine :)

This bug is fixed in my laptop, can you test?

I spoke too early. The bug is still present. It was just a lucky boot

Kal, could you please remove the plymouth package and tell me if this
solves the bug for you?
I have done it and had still had no crashes, but it could be luck.

Nicolò, removing the plymouth package unfortunately doesn't solve it for me. It's still crashing every time I close the lid.

That's very very strange! I've not had crashes anymore (though I have
to switch to the VT to get the image back on the screen).
I will continue to test it. Have you got any additional ppa
repository, or self compiled thing?

I finally had the crash even with plymouth uninstalled, so I was wrong, sorry.

That is not the same bug, please remove the upstream link.

Using xorg-edgers (libdrm 2.4.17+git20100210.4f0f8717-0ubuntu0sarvatt, which contains commit 4f0f871730b76730ca58209181d16725b0c40184) seems to at least partially "fix" it:

- log in to gnome with compiz enabled
- close lid -> backlight turns off
- open lid -> backlight stays off
- switch vts: vt7 -> vt1 (backlight comes back on) -> vt7
- have a working desktop

I have rebooted 3 times to verify that this behavior is consistent, since it was also working this way in the past for some reason.

The reason I write "partially" is not because the backlight isn't being turned on again, but because I still get errors in both dmesg and Xorg.0.log:

[... close lid ...]
[ 35.941034] dell-wmi: Unknown key ffd0 pressed
[...]
[ 46.932531] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[ 46.932541] render error detected, EIR: 0x00000000
[ 46.932544] i915: Waking up sleeping processes
[ 46.932569] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 1568 at 1558)
[ 46.933227] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged
[ 46.933340] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged
[ 46.938810] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged
[ 47.700027] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[ 47.700035] render error detected, EIR: 0x00000000
[ 47.700037] i915: Waking up sleeping processes
[ 47.700069] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 1569 at 1558)
[ 49.090027] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[ 49.090034] render error detected, EIR: 0x00000000
[ 49.090037] i915: Waking up sleeping processes
[ 49.090070] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 1571 at 1558)
[... open lid ...]
[ 49.175642] [drm] LVDS-8: set mode 1440x900 28
[ 49.500086] dell-wmi: Unknown key ffd1 pressed
[...]

and

[...]
(II) intel(0): Modeline "1440x900"x0.0 71.88 1440 1486 1556 1928 900 909 918 932 +hsync -vsync (37.3 kHz)
(EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output error.
(EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output error.
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
[...]

The backlight-not-turning-back-on portion is indeed a separate bug (which Nicolò reported as #488328), it just also happens on lid-closing.

While I was investigating the backlight issue, I found http://bugzilla.kernel.org/show_bug.cgi?id=14997 which indicates that on kernel 2.6.32 not only the display is disabled, but the display is actually being disconnected (in order to save power). This means that X is running with "no attached outputs".
Could it be that, since the error messages seem to only appear when the lid is closed, those are actually a side-effect of X running with no attached outputs?

This is a kernel/libdrm problem. The libdrm side has been fixed as of 2.4.18 which is in lucid and the kernel side is fixed by a patch on the linked bug report that was sent to stable and will be pulled in with the next update.

I tested the upstream patch, in a kernel package compiled by Chase Douglas [1], which you can find in this bug report [2].
It seems to work but does not fix the gnome-settings-daemon notification: "could not switch the monitor configuration / could not set the configuration for CRTC 64", which is present only when using KMS, also without the kernel patch applied.
He decided to wait for the patch to hit the upstream git repo before applying it to lucid.
I also reported it upstream, but I have not received any answers yet.
Anyway this might be a gnome-settings-daemon related problem, since it has some other issues triggered after opening the laptop lid, that I reported in this bug [3]

[1] http://people.canonical.com/~cndougla/488328/linux-image-2.6.32-13-generic_2.6.32-13.19~lp488328_amd64.deb
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/488328
[3] https://bugs.launchpad.net/gnome-settings-daemon/+bug/524830

This is fixed in 2.6.32-19.

Can someone please confirm whether or not this issue still exists in natty? Thanks!

Based on comment #39 form the original bug reporter, I'm marking this Fix Released. Should anyone still be having issues, please open a new bug. Thanks.