Latest working kernel version: 2.6.30-rc3 Earliest failing kernel version: 2.6.30-rc4 Distribution: Debian lenny amd64 Hardware Environment: HP Compaq 6720s When I close laptop lid, I get an oops and a panic. It does not always happen on the first time, but I didn't have to try more than three times. See also bug 11259. The patch from there has fixed the video module in 2.6.29. 2.6.30-rc1 and up to 2.6.30-rc3 are OK. I have bisected the source and have discovered that commit b7f0ab46 "ACPI, i915: Register ACPI video even when not modesetting" broke it now. Unlike bug 11259, I don't get a panic if X.org was not started during that boot. Even if I stop X and then close the lid -- I get a panic. Summary: * 2.6.30-rc3 OK * 2.6.30-rc4 fails * reverting b7f0ab46 on latest HEAD 3218911f (post-2.6.30-rc7) helps * CONFIG_ACPI_VIDEO=n helps * maxcpus=1 helps I can boot with ACPI debugging, just suggest me appropriate debug_level and debug_layer values.
Created attachment 21658 [details] 2.6.30-rc7-3218911f kernel log with an oops and a panic
Created attachment 21659 [details] 2.6.30-3218911f config
Created attachment 21660 [details] lspci -vvv
Created attachment 21661 [details] acpidump
> Distribution: Debian lenny amd64 I'm sorry, I'm running Debian squeeze (testing) amd64 (copy-paste error).
Hi, Dmitri Thanks for your info. I don't think this is a regression. On your box the KMS must be enabled if we expect that it can work well. Before the commit of b7f0ab46 is shipped, acpi video driver is not loaded if KMS is not enabled. If the KMS is enabled, i915 driver will initialize the ACPI opregion and then load the acpi video driver. In such case your box can work well. But unfortunately it will bring that there is no backlight I/F on other boxes if KMS is not enabled. This is unsuitable for other users. After the commit of b7f0ab46 is shipped, the acpi video driver will be loaded by i915 driver regardless whether the KMS is enabled or not. Of course the side effect is that it can't work on your box if KMS is not enabled. It can work well if the KMS is enabled. IMO this bug can be rejected. Thanks.
Yes, CONFIG_DRM_I915_KMS=y helps, thank you for your advice. But there is one new problem with KMS enabled: virtual consoles (Ctrl-Alt-F1) are now broken, there is no text, just five blinking vertical bars.
Please summarize the state of things with the latest git kernel. Does CONFIG_DRM_I915_KMS=n do something sane -- like not oops? Re: CONFIG_DRM_I915_KMS=y breaking virtual consoles -- ACPI is not involved in virtual consoles -- so you'd want to ping the i915 X guys on that one.
Hi Len, My comments #0 -- #5 are about git revision 3218911f (which was latest at the moment of writing). I have re-tested with latest git d9244b5 and same config as before (see comment #2): CONFIG_ACPI_VIDEO=m CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=n Got same results as in initial report: everything works fine until I close the lid. The stack trace from oops if a bit different, though. So, I wouldn't say that CONFIG_DRM_I915_KMS=n is sane for me with latest git.
Created attachment 21700 [details] 2.6.30-rc7-d9244b5 kernel log with an oops Although there is no panic message, the machine was hung after oops.
Everything is OK with X.org packages from Debian unstable (X.org 7.4, Intel drivers 2.7.1): * closing laptop lid doesn't trigger any sort of oops * changing virtual consoles with chvt works without blanking the screen (KMS works) But, changing virtual consoles with Ctrl-Alt-F1 doesn't work (nothing happens), but that's definitely not a kernel's problem.
This is almost certainly the same as bug 13751. Can you please try the patch from comment #30 there and report the results?
*** This bug has been marked as a duplicate of bug 13751 ***