Bug 14766

Summary: screen brightness won't come back when I open the lid
Product: Drivers Reporter: Nicolo' Chieffo (84yelo3)
Component: Video(DRI - Intel)Assignee: Jesse Barnes (jbarnes)
Severity: normal CC: akpm, bugs, jbarnes, rjw, yakui.zhao
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.32 vanilla, 2.6.32rc3 vanilla Tree: Mainline
Regression: Yes
Bug Depends on:    
Bug Blocks: 13615    
Attachments: acpidump
diff logs pre-after crash
dmesg after crash

Description Nicolo' Chieffo 2009-12-08 15:10:22 UTC

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 .
Comment 1 Nicolo' Chieffo 2009-12-08 15:16:55 UTC
I forgot to say that each message is connected to a laptop open/close. So these messages are printed after 9 open/close
Comment 2 Andrew Morton 2009-12-08 23:20:09 UTC
Since which kernel version did we regress? 2.6.31?

Comment 3 Nicolo' Chieffo 2009-12-09 08:07:33 UTC
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
Comment 4 ykzhao 2009-12-28 16:02:24 UTC
Hi, Nicol
     Will you please try the following patch on the 2.6.32 kernel and see
whether the issue still exists?

Comment 5 Nicolo' Chieffo 2009-12-28 16:28:36 UTC
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
Comment 6 ykzhao 2009-12-29 09:54:34 UTC
Will you please attach the output of acpidump on your box?
The latest acpidump tool(pmtools-20071116) can be found in 

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.

Comment 7 Nicolo' Chieffo 2009-12-29 23:30:47 UTC
First of all, kernel 2.6.23-rc2 has the same problem.
Comment 8 Nicolo' Chieffo 2009-12-29 23:32:32 UTC
Created attachment 24368 [details]
Comment 9 Nicolo' Chieffo 2009-12-29 23:33:15 UTC
Created attachment 24369 [details]
Comment 10 Nicolo' Chieffo 2009-12-29 23:37:25 UTC
I've noi booted with "nomodeset" makes this bug is disappeared.
That file contains "state: open" after a close/open
Comment 11 ykzhao 2010-01-02 14:09:17 UTC
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.

Comment 12 Nicolo' Chieffo 2010-01-03 17:32:07 UTC
Created attachment 24420 [details]

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)
Comment 13 Nicolo' Chieffo 2010-01-11 11:25:29 UTC
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
Comment 14 Nicolo' Chieffo 2010-01-11 11:26:40 UTC
Created attachment 24509 [details]
dmesg after crash

I also attach the dmesg obtained from ssh after the crash.
I hope this informations are helpful
Comment 15 Nicolo' Chieffo 2010-01-13 11:20:00 UTC
I've tested kernel 26.31.11 and it works here, so the regression is since that kernel.
Comment 16 Rafael J. Wysocki 2010-01-13 21:01:36 UTC
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?
Comment 17 Nicolo' Chieffo 2010-01-14 00:24:54 UTC
Ok, I've created some space in my hard disk. Can you tell me how to do this thing?
Comment 18 Nicolo' Chieffo 2010-01-17 00:50:35 UTC
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
Comment 19 Nicolo' Chieffo 2010-01-21 12:15:52 UTC
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.
Comment 20 Jesse Barnes 2010-02-18 23:15:55 UTC
Looks like a dupe.

*** This bug has been marked as a duplicate of bug 14997 ***