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)
Status:	RESOLVED DUPLICATE
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	Subsystem:
Regression:	Yes	Bisected commit-id:
Bug Depends on:
Bug Blocks:	13615
Attachments:	acpidump dmidecode lid_state diff logs pre-after crash dmesg after crash

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

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 .

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?

Thanks.

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?
    >http://lists.freedesktop.org/archives/intel-gfx/2009-December/005143.html

Thanks.

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 
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.

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]
acpidump

Comment 9 Nicolo' Chieffo 2009-12-29 23:33:15 UTC

Created attachment 24369 [details]
dmidecode

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.

thanks.

Comment 12 Nicolo' Chieffo 2010-01-03 17:32:07 UTC

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)

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?
Thanks

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 ***