Latest working kernel version: 2.6.25 Earliest failing kernel version: ? 2.6.26~rc5 (previous RCs not tested). Distribution: Debian/testing Hardware Environment: Thinkpad T60 (Intel video chipset) Software Environment: Kernel from http://kernel-archive.buildserver.net/debian-kernel/ Problem Description: If I close my laptop's panel when I have an external monitor attached and enabled, my laptop freeze... i have to power it off. Steps to reproduce: Plug an external screen to a Thinkpad T60 laptop (based on intel 945 chipset). Then boot the laptop, and log into gnome. Make sure that : 1. Both screen are enabled (xrandr --auto). 2. Gnome power setting has : "When laptop lid is closed" = "Blank Screen" 3. Close the laptop's panel. => The laptop is now frozen. It occurs when : using linux-image-2.6.26-rc5, rc6 or rc7. Does not occurs with : linux-image-2.6.24 , 2.6.25 from Debian/testing. Occurs if gnome has "When laptop lid is closed" = "Blank Screen" Doesn't occur if it's set to "Do nothing" Occurs on my T60, with : Intel 945GM/PM/GMS Express Memory Controller Hub [8086:27a0] Intel 945GM/GMS Express Integrated Graphics Controller [8086:27a2] Does NOT occur on a T61, with Intel GM965/GL960 Integrated Graphics Controller [8086:2a02] Intel GM965/GL960 Integrated Graphics Controller [8086:2a03] Occurs when both output are enable (crt=on + lvds=on) Doen not occurs when only one of the screens are enabled (crt=on + lvds=off OR crt=off + lvds=on). Note : The laptop can suspend or hibernate, then resumes correctly. Running gnome screensaver is ok (but gnome doesn't seems to want to put the screens in powersave mode). More information about that bug is available at http://bugs.debian.org/487672
This entry is being used for tracking a regression from 2.6.25. Please don't close it until the problem is fixed in the mainline.
Do you have CONFIG_DRM_I915=m and the i915 driver loaded? Does this failure also occur with CONFIG_ACPI_VIDEO=n?
On some platforms, the BIOS will try to access disabled pipes when lid events occur. To work around this problem, you can try using the Intel X driver's "ForceEnablePipeA" option, can you give that a try?
(In reply to comment #3) > On some platforms, the BIOS will try to access disabled pipes when lid events > occur. To work around this problem, you can try using the Intel X driver's > "ForceEnablePipeA" option, can you give that a try? > It works. What should I do next ? Section "Device" Identifier "Configured Video Device" Driver "intel" Option "ForceEnablePipeA" "true" EndSection
Please file a bug at freedesktop.org for it. Check out the intel man page (the ForceEnablePipeA section) for what you need to attach to the bug. Thanks for testing.
(In reply to comment #2) > Do you have > CONFIG_DRM_I915=m > and the i915 driver loaded? > > Does this failure also occur with CONFIG_ACPI_VIDEO=n? > Yes, i915 module was loaded. I've recompiled my (rc7) kernel with CONFIG_ACPI_VIDEO=n, but it didn't help.
(In reply to comment #5) > Please file a bug at freedesktop.org for it. Check out the intel man page > (the > ForceEnablePipeA section) for what you need to attach to the bug. Done. https://bugs.freedesktop.org/show_bug.cgi?id=16494 Thanks for your help, Franklin
Thanks for the quick suggestion Jesse, and quick testing Franklin. Clearly this one has nothing to do with ACPI, so I'm moving it to the drivers section of bugzilla.
Franklin, since you have a good workaround now, I wonder if you could try to narrow down when this started failing. 2.6.25 included support for kernel based suspend/resume of Intel graphics devices, and so does 2.6.26, so it seems like that's not the problem. Maybe something in the way your machine handles lid events changed?
(In reply to comment #9) > Franklin, since you have a good workaround now, I wonder if you could try to > narrow down when this started failing. 2.6.25 included support for kernel > based suspend/resume of Intel graphics devices, and so does 2.6.26, so it > seems > like that's not the problem. Maybe something in the way your machine handles > lid events changed? > Hello, I had started doing some git-bisecting, but it really is [CPU] time consuming... still within 11 hops, I should be down to the very one patch. I don't know any extra test I could make, do you have any ?
Yeah, bisecting is tedious, but it's the best method I can think of for this. Thanks!
Since this is fixed in the upstream X driver (,08903abe4dc0295c7ed7d1ff1a22e0e579540c15 of xf86-video-intel) I'm closing this out. If your bisect finds anything, please let me know. Thanks.