LAPTOP: DELL LATITUDE E6400 This problem happens when I'm in Xorg, close the laptop lid and then open it: the screen remains completely black until I hit CTRL-ALT-F1 and wait some seconds. Then if I switch back to ALT-F7 I see a notification saying "culd not set the configuration for CRTC64" This is in my .xsession-errors ../../../libdrm/intel/intel_bufmgr_gem.c:893: Error setting memory domains 2 (00000040 00000000): Input/output error . ../../../libdrm/intel/intel_bufmgr_gem.c:893: Error setting memory domains 150 (00000040 00000000): Input/output error . ../../../libdrm/intel/intel_bufmgr_gem.c:893: Error setting memory domains 1 (00000040 00000000): Input/output error . ../../../libdrm/intel/intel_bufmgr_gem.c:893: Error setting memory domains 2 (00000040 00000000): Input/output error . ../../../libdrm/intel/intel_bufmgr_gem.c:893: Error setting memory domains 150 (00000040 00000000): Input/output error . ../../../libdrm/intel/intel_bufmgr_gem.c:893: Error setting memory domains 1 (00000040 00000000): Input/output error . ../../../libdrm/intel/intel_bufmgr_gem.c:893: Error setting memory domains 2 (00000040 00000000): Input/output error . ../../../libdrm/intel/intel_bufmgr_gem.c:893: Error setting memory domains 150 (00000040 00000000): Input/output error . ../../../libdrm/intel/intel_bufmgr_gem.c:893: Error setting memory domains 1 (00000040 00000000): Input/output error .
I forgot to say that each message is connected to a laptop open/close. So these messages are printed after 9 open/close
Since which kernel version did we regress? 2.6.31? Thanks.
I thought 2.6.31, but I've just tried it and found out that my screen does not shut off when I close the lid in that kernel
Hi, Nicol Will you please try the following patch on the 2.6.32 kernel and see whether the issue still exists? >http://lists.freedesktop.org/archives/intel-gfx/2009-December/005143.html Thanks.
Well, unfortunately I don't think I have enough space to compile my kernel... Anyway I had a look at the patch comments in the mailing list and it seems to be related to suspend/resume, while my system is not set to suspend on lid close, and does not. I'm instead downloading a precompiled 2.6.33 kernel, to see if it has the same problems
Will you please attach the output of acpidump on your box? The latest acpidump tool(pmtools-20071116) can be found in http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ Please add the boot option of "nomodeset" and attach the output of "cat /proc/acpi/button/lid/LID/state" after the LID is closed and reopened. Please also attach the output of dmidecode. thanks.
First of all, kernel 2.6.23-rc2 has the same problem.
Created attachment 24368 [details] acpidump
Created attachment 24369 [details] dmidecode
I've noi booted with "nomodeset" makes this bug is disappeared. That file contains "state: open" after a close/open
Will you please add the boot option of "nomodeset" and do the following test? 1. kill the process using /proc/acpi/event(use the command of "lsof /proc/acpi/event") 2. cat /proc/acpi/event >lid_state 3. close and reopen the lid several times 4. press "ctrl + C" and attach the output of lid_state. thanks.
Created attachment 24420 [details] lid_state Maybe I wasn't clear in my previous message, since I wrote in bad english, sorry: the boot option "nomodeset" solves this bug. Anyway I attached the output of the commands (I closed and opened the lid 3 times)
Created attachment 24508 [details] diff logs pre-after crash Hello again. This bug become worse now, because after some updates (I think to libdrm) I can't recover the brightness anymore, so I decided to add informations to this bug. I installed openssh (to have access to the machine after the crash) and I did a test: I saved the /var/log directory before and after the crash, then I made a diff of every log file. I obtained this diff file
Created attachment 24509 [details] dmesg after crash I also attach the dmesg obtained from ssh after the crash. I hope this informations are helpful
I've tested kernel 26.31.11 and it works here, so the regression is since that kernel.
OK, so most probably the problem was introduced during the 2.6.32 merge window. Would you be able to bisect the commits between 2.6.31 and 2.6.32 to check which one of them introduces the problem?
Ok, I've created some space in my hard disk. Can you tell me how to do this thing? Thanks
bisecting ended with: 11ed50ec2a316928c2bacc1149bded86c6a96068 is the first bad commit commit 11ed50ec2a316928c2bacc1149bded86c6a96068 Author: Ben Gamari <bgamari.foss@gmail.com> 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 <oga@openbsd.org> Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> :040000 040000 b692598aa1c95929f7ccfdba078c497161c70e06 edcb7cbb5473940449b517c0950a316d4c7989d3 M drivers
I might have mixed up things. Sorry. The second part of the bug is not related to this, and it was caused by another package. The only valid part of the bug is the one described in the first post. Anyway the bisect (not done by me) fixes this bug.
Looks like a dupe. *** This bug has been marked as a duplicate of bug 14997 ***