Closing lid results in kernel panic visible on VT-1

Thanks, I'll prepare the pipe A quirk for this.

I notice that also a similar model has issues with the TV out interfering with the automatically selected resolution (perhaps sometimes messing up the GNOME toolbars). Can you let me know if the tv-out quirk is needed as well? To check this, if you've had any resolution related problems run `xrandr` and see if your tv-out is enabled, and if those problems go away if you turn it off via `xrandr --output TV --off`. (You might need to change "TV" to 'S-Video" or something; look at the output of `xrandr` to see what it's called.)

Important: the information in the description field of this bugid is incorrect (!). I thought that enabling the "ForceEnablePipeA" option resolved the issue, but I always performed the tests right after X started. It now seems that after keeping the lid closed for a while or "closing/opening" the lid a couple of times, X will eventually hang anyway.

Bryce, this might have impact on freedesktop-bugs #15885 (!!). Sorry!

Scenarios tested, all resulting in X hanging eventually.

a) "ForceEnablePipeA" = true + autologin is enabled
b) "ForceEnablePipeA" = true + autologin is disabled
c) "ForceEnablePipeA" = false + autologin is enabled
d) "ForceEnablePipeA" = false + autologin is disabled
e) a) + Control-Alt-Backspace
f) b) + Control-Alt-Backspace
g) c) + Control-Alt-Backspace
h) d) + Control-Alt-Backspace

Again, I'm terribly sorry for the confusion I might have caused.

Bryce, I don't have resolution related issues with my laptop.

This is the output of `xrandr` is this:

<snip>
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1400 x 1050
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800 59.9*+ 60.0
   1280x768 60.0
   1024x768 60.0
   800x600 60.3
   640x480 59.9
TV disconnected (normal left inverted right x axis y axis)
</snip>

Something you might be interested in: HP/Compaq replaced my laptop once, because I had hardware issues. They returned me a new laptop with exactly the same model number (Compaq 6710b). When I switched it on, I noticed it had a different screen compared to the "old" one, which (of course) resulted in a resolution issue when I copied back my backupped OS. See http://www.oetz.nl/~pkuijven/ddcprobe-laptop.diff for the difference in screens.

Erk, ok thanks for letting me know swiftly. I've notified upstream to revert the change.

The hardware change sounds pretty significant - from your diff it appears the entire display has changed. Putting your old backed up os on top of this hardware probably resulted in an incorrect config file being used.

Please refer to wiki.ubuntu.com/X/Reporting for information of what files to include.

I tried to make a full backtrace when I was logged in remotely. I noticed that the laptop hangs in total. This issue isn't X related.

I think it's best to just close this bug, and create a new one?

I booted my laptop, did a Control-Alt-F1 and closed the lid. This resulted in a kernel panic. Attached you'll find the logfiles/screenshots.

I also tried with a 2.6.24-16 kernel, which resulted in a kernel panic as well.

I also tried to boot with a Ubuntu 7.10 live CD. This runs kernel 2.6.22-14 (Ubuntu 2.6.22-14.46). Closing the lid did not result in "hanging" laptop (!).

Hi petski,

Just to see if it will make a difference, care to test the Intrepid Ibex 8.10 kernel? It was most recently rebased with the upstream 2.6.25 kernel (which contains the patch you've referenced) and is currently available in the following PPA:

https://edge.launchpad.net/~kernel-ppa/+archive

If you are not familiar with how to install packages from a PPA basically do the following . . .

Create the file /etc/apt/sources.list.d/kernel-ppa.list to include the following two lines:

deb http://ppa.launchpad.net/kernel-ppa/ubuntu hardy main
deb-src http://ppa.launchpad.net/kernel-ppa/ubuntu hardy main

Then run the command:

sudo apt-get update

You should then be able to install the linux-image-2.6.25 kernel package. After you've finished testing you can remove the kernel-ppa.list file and run 'sudo apt-get update' once more. Please let us know your results. Thanks.

Hi Leann,

Thanks for taking the time to send me a reply.

The bug is also reproducible with a 2.6.25 kernel that came from the PPA.

Version information:

Linux workmate 2.6.25-1-generic #1 SMP Tue May 13 02:19:02 UTC 2008 x86_64 GNU/Linux
Ubuntu 2.6.25-1.2ubuntu4-generic

Attached you'll find a screenshot of the kernel panic (when booted with the PPA-kernel).

P.S. I didn't reference any patch in this bug-id, so you might confuse me with someone else.

I have the same laptop model. And the same bug. And I get a kernel panic when the lid is closed. Set the bug to confirmed?
Probably won't help much but here is another kernel panic photo... messages are a bit different to the above.

I haven't got the time to check... but I don't recall the bug existing with 64bit Ubuntu, just 32bit.

I have the same laptop model. And the same bug. And I get a kernel panic when the lid is closed. I do get the same kernel panic message like petski.

This bug is probably related to LP #157691

Al small summary of LP #157691 : After booting, /proc/acpi/video/C098/DOS by default is set to '0'. If I close the lid of my laptop (which is a HP/Compaq 6710b), this results in a kernel panic. When I set /proc/acpi/video/C098/DOS to '7' it won't.

I have got HP 550 laptop and the same bug (kernel panic after close/open the lid) with ubuntu 8.04 "Hardy Heron" and kernel 2.6.24-19-generic. When I set boot option acpi=off it works fine. But acpi=off option is not good solution.

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

I have tested with the current 64bit Intrepid, using the kernel 2.6.27-4, and there is no problem. I'll try with the 32bit Intrepid when beta 1 livecd is released.

I've just tried to reproduce this issue on "Linux workmate 2.6.27-7-generic #1 SMP". There is still a kernel panic when I close the lid (see attached screenshot).

Because I noticed the error could be SMP-related, I disabled one of the CPU's (sudo sh -c 'echo 0 > /sys/devices/system/cpu/cpu1/online') and closed the lid again. No kernel panic this time!

HTH

P.S. Again, I would like to point out that this bug might be related to LP#157691

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Hi petski,

Would you be willing to test with the latest pre-release of Jaunty 9.04 (currently Alpha4). It contains a newer 2.6.28 based kernel. It would be great to know if this issue remains. I imagine you should be able to test using a LiveCD. Also note that Jaunty Alpha5 is expected to come out within the next few days so you may want to test with this even newer Alpha - http://cdimage.ubuntu.com/releases/jaunty/ . Please let us know your results. Thanks.

Leann,

I'm using9.04 since alpha2... problem is still there. But not as reproductable as in 8.10. I'll have a look next time for more debug information.

Could those of you affected by this bug try reproducing this from VT-1. Before reproducing could you run the following command which should reduce the font size sidnificantly so that the entire panic is visible:

    consolechars -f /usr/share/consolefonts/Uni1-VGA8.psf.gz

You may need to install console-tools package as below:

    sudo apt-get install console-tools

Please report any panics back here.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Let's start with a brief introduction:

* In my case, lid-closures do not result in a kernel panic anymore since these
  lines were added to /etc/init.d/hotkey-setup:

    39 for x in /proc/acpi/video/*/DOS; do
    40 if [ -e "$x" ]; then
    41 echo -n 7 >$x;
    42 fi
    43 done

  This patch was made in hotkey-setup 0.1-22. The package "hotkey-setup" is a
  dependency for the meta-package "ubuntu-desktop" (not for "ubuntu-standard" or
  "ubuntu-minimal"). IMHO the patch to "hotkey-setup" should be considered as a
  workaround, not as a bugfix.

* There could be a relation between #157691 and #228399

* The panic isn't triggered when SMP is disabled
  (sudo sh -c 'echo 0 > /sys/devices/system/cpu/cpu1/online')

Enough introduction :) ..

* I've commented out lines 39-43 in /etc/init.d/hotkey-setup and rebooted.

* I'm running cutting-edge Jaunty:

  $ uname -a
  Linux workmate 2.6.28-8-generic #26-Ubuntu SMP
   Wed Feb 25 04:27:53 UTC 2009 x86_64 GNU/Linux

* By default, the DOS setting is "0":

  $ cat /proc/acpi/video/C098/DOS
  DOS setting: <0>

Attached you'll find a picture containing the last couple of lines of the
"oops", right after I've closed the lid.

I hope the picture and the information I provided contain enough information to
work on this bug. I really really have a lack of time, else I would have made a
new picture because this one is a bit vague. Maybe someone else can try to
reproduce the bug with netconsole running
(https://wiki.ubuntu.com/KernelTeam/Netconsole) or when booted from a vanilla
kernel (https://wiki.ubuntu.com/KernelMainlineBuilds).

HTH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmsMioACgkQts9hyuTDB0XXywCfX2kwmVPPjw52e632mfRjxup4
8OYAni51ROwxPOxvyJcHnjdAuHpiuY+u
=QqNU
-----END PGP SIGNATURE-----

There might also be a relation with http://bugzilla.kernel.org/show_bug.cgi?id=11259

FYI: There's an update at [1]. Patch available at [2].

[1] http://bugzilla.kernel.org/show_bug.cgi?id=11259
[2] http://patchwork.kernel.org/patch/13147/

Patch was accepted into acpi-test

Seems the patch has since been accepted upstream. Pasting the upstream git commit id below. Thanks.

ogasawara@yoji:~/linux-2.6$ git log 74a365b3f354fafc537efa5867deb7a9fadbfe27
commit 74a365b3f354fafc537efa5867deb7a9fadbfe27
Author: Matthew Garrett <email address hidden>
Date: Thu Mar 19 21:35:39 2009 +0000

    ACPI: Populate DIDL before registering ACPI video device on Intel

    Intel graphics hardware that implements the ACPI IGD OpRegion spec
    requires that the list of display devices be populated before any ACPI
    video methods are called. Detect when this is the case and defer
    registration until the opregion code calls it. Fixes crashes on HP
    laptops.

    http://bugzilla.kernel.org/show_bug.cgi?id=11259

    Signed-off-by: Matthew Garrett <email address hidden>
    Acked-by: Eric Anholt <email address hidden>
    Signed-off-by: Len Brown <email address hidden>

Ok there seems to be good feedback on this patch for mainline, so I have pulled a copy of this patch back to Jaunty to confirm it is the fix for the issue. I have backported this change (removing the KMS support) and built some test kernels. If those of you who are affected by this issue on Jaunty could test these kernels and report back here that would be very helpful. Those kernels can be found at the URL below:

    http://people.ubuntu.com/~apw/lp228399-jaunty/

As a "null-test" I've commented out lines 30-34, which contain a workaround for this bug, in /etc/init.d/hotkey-setup and rebooted to 2.6.28-11-generic, which is currently in jaunty-main. Closing lid caused a panic again (as expected).

I've installed Andy's amd64 deb's afterwards and rebooted to "2.6.28-13-generic #44~lp228399apw1". Closed lid; no panic this time!

IMHO hotkey-setup needs an extra condition just before line 30 in case Andy's fix will hit the archive (pseudo-code: if kernel-version < 2.6.28-13; then <apply workaround>).

Thanks for your time and effort Andy! Great job!

As petski points out, this is very likely the same issue as https://bugs.launchpad.net/bugs/157691 because:

  - it affects the HP 6710b (comment #3)
  - "nosmp" avoids the bug (comment #20)
  - crash is related to lid event

User-mode code changes are not a fix for a kernel panic, so any hotkey-setup or similar changes are at best a band-aid.

There is a kernel fix upstream:
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=74b5820808215f65b70b05a099d6d3c969b82689

I also ported this patch to 2.6.24-24-generic. The patched file is in https://bugs.launchpad.net/ubuntu/+source/hotkey-setup/+bug/157691/comments/58

@Bjorn Helgass -- thanks for the pointer. That does indeed sounds possible. Could those of you afffected please test the latest Karmic kernel 2.6.31-6.25 as that is based on v2.6.31-rc6 upstream which contains the fix indicated above. Please report back here. Thanks.

Bah didn't spot that we had a more specific fix for this specific issue. Seems there are two issues out there. If the first patch does not fix you then the second test is useful.

For this specific bug it seems that the original fix is good. I will therefore close this off for Karmic as it is already fixed there either way.

For Jaunty it has been proposed for SRU and already applied to the tree.

@Andy, if the "more specific fix" you refer to is a hotkey-setup change, that is only a workaround and not a sufficient fix. The kernel should never panic or hang, no matter what user-mode applications do. If you pick up the kernel change from comment #32, the hotkey-setup change should not be necessary.

Accepted linux into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I've disabled the "hack" in /etc/init.d/hotkey-setup by commenting out lines 28-36. After I did that I booted with the new kernel.

$ cat /proc/version
Linux version 2.6.28-15-generic (buildd@crested) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #51-Ubuntu SMP Mon Aug 31 13:39:06 UTC 2009

Closed lid, and no panic :) Good work guys :)

Two remaining questions:
- What happens to LP #157691 ?
- IMHO hotkey-setup needs some extra code as suggested in comment #31 of this bug

The patch had to get reverted as it caused regressions for Intel video cards (see bug #423296). The problem is that without the KMS code, the patch just causes the acpi video driver never to get initialized and by that prevents backlight control. The fix of this bug was unfortunately just coincidental. Without te acpi video driver being initialized it could not cause a panic.

As for this bug, I remember some other cases which could be avoided by playing around with the contents of /proc/acpi/video/*/DOS. This controls whether the BIOS switches video modes and how.

Bit 1:0
        0: The system BIOS should not automatically switch (toggle) the active display output,
           but instead just save the desired state change for the display output devices in
           variables associated with each display output, and generate the display switch event.
           OSPM can query these state changes by calling the _DGS method.
        1: The system BIOS should automatically switch (toggle) the active display output, with
           no interaction required on the OS part. The display switch event should not be
           generated in this case.
        2: The _DGS values should be locked. It’s highly recommended that the system BIOS
           do nothing when hotkey pressed. No switch, no notification.
        3: The system BIOS should not automatically switch (toggle) the active display output,
           but instead generate the display switch event notify codes 0x82, 0x83, or 0x84.
           OSPM will determine what display output state should be set, and change the display
           output state without further involvement from the system BIOS.
Bit 2
        0: The system BIOS should automatically control the brightness level of the LCD when
           the power changes from AC to DC.
        1: The system BIOS should not automatically control the brightness level of the LCD
           when the power changes from AC to DC.

The documentation (ACPI spec 3.0a) states 1 the default state, but it might depend on the card.

This bug was nominated against a series that is no longer supported, ie jaunty. The bug task representing the jaunty nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.