Hardy/Gutsy crashes when the lid is closed on a HP 6710b, HP 6510b and HP 2510p

[Roger Irwin]

I have an HP 6710b that I have installed Gusty Gibbon on and it all works fine until I close the lid and walk away.

When I come back the screen is on as I left it but the system has frozen. This only happens when I leave the lid down and after about 10-20 mins. If I close the lid for a short time it doesn't crash.

Removing acpid seems to stop it from crashing. To do so I also have to uninstall these dependents: acpi-support, powermanagement-interface, ubuntu-desktop

Kernel modules battery and button have to be loaded manually after there packages are uninstalled. They have no effect on it crashing or not. The bug must therefore be in acpid . Tried deleting /etc/acpi/lid.sh and commenting out /etc/acpi/events/lidbtn with no effect.

There are no relevant entries in /var/log/messages or syslog.

/proc/acpi/button/lid/C153/state works correctly showing when the lid is open/closed.
------------------------------
Updated the summary with all the reported models having the problem and added Hardy. -Hans Deragon

[Update]
If you are seeing a crash when the lid is closed and you have an Intel graphics chip, see the Pipe A quirk at https://wiki.ubuntu.com/X/Quirks as a possible way to solve this issue.

[Sleft (sleft)]

See also this thread with more reports http://ubuntuforums.org/showthread.php?p=3661902

[Joonas Koivunen (joonas-koivunen)]

I can confirm this with another HP 6510b.. Only that the crash happens immediatedly after pushing the lid down.. If you open the lid you'll see a frozen screen. However the lid closing doesn't always trigger the crash.. For example I can press the lid button many times and almost randomly it crashes.

Only thing I can think of to help is to add some "sync" commands in to /etc/acpi/lid.sh and power.sh...

[charon79m (charon79m)]

I agree with the above. Below is /var/log/acpid for two button events. The first did not lock the system, the second event did.

[Sun Nov 11 19:08:20 2007] received event "button/lid C153 00000080 00000004"
[Sun Nov 11 19:08:20 2007] notifying client 5146[107:116]
[Sun Nov 11 19:08:20 2007] notifying client 5671[0:0]
[Sun Nov 11 19:08:20 2007] executing action "/etc/acpi/lid.sh"
[Sun Nov 11 19:08:20 2007] BEGIN HANDLER MESSAGES
[Sun Nov 11 19:08:20 2007] END HANDLER MESSAGES
[Sun Nov 11 19:08:20 2007] action exited with status 0
[Sun Nov 11 19:08:20 2007] completed event "button/lid C153 00000080 00000004"
[Sun Nov 11 19:08:21 2007] received event "video C098 00000080 00000000"
[Sun Nov 11 19:08:21 2007] notifying client 5146[107:116]
[Sun Nov 11 19:08:21 2007] notifying client 5671[0:0]
[Sun Nov 11 19:08:21 2007] executing action "/etc/acpi/videobtn.sh"
[Sun Nov 11 19:08:21 2007] BEGIN HANDLER MESSAGES
[Sun Nov 11 19:08:21 2007] END HANDLER MESSAGES
[Sun Nov 11 19:08:21 2007] action exited with status 0
[Sun Nov 11 19:08:21 2007] completed event "video C098 00000080 00000000"

I have confirmed this issue on the two units I have at my office.

[Roger Irwin (rogirwin)]

I have found a solution that completely stops it from crashing. It's not an Ideal solution but it works for me.

Remove the acpid by typing this: sudo apt-get remove acpid

I have been running my computer like this for a few weeks now without it crashing at all.

This still loads the acpi module when booting and you can prove this by looking in /proc/acpi

Most acpi events still work but you will have to load the button and battery modules manually or add in /etc/modprobe.d/ if you want them.

[charon79m (charon79m)]

Well, I concur that the issue is in acpid. I've not had a lock-up since. The battery monitor no longer works and screen blanking when idle is gone.

I have verified this on both of my units.

[Igor V Grigorev (ivg313)]

I have 6710s and it crash immediately after pushing lid down. I think it's bug in module button.ko
If i do:

sudo rmmod button

- the problem disappears. Easy workaround creates something like /etc/modprobe.d/blacklist-button containing:

blacklist button

It's work for me.

[Joonas Koivunen (joonas-koivunen)]

Good news everyone! Indeed, it seems that the problem is kernel crashing!

If you start Kubuntu normally and log in, while starting KDE/whatever you switch to console (Alt+Ctrl+F1) and close the lid you'll see something like:

[<timestamp>] BUG: Could not handle a NULL pointer reference in kernel.

Ok, If someone knows how to trace this somehow, it'd be great! I wonder why wont the kernel panic in that event...

Your proposition of unloading button.ko might not be the problem -- I haven't seen the source but sounds like a pretty simple module. I guess the next step is to get someone interested in this problem .... Someone who knows how to debug or at least get a trace out of this.

[Joonas Koivunen (joonas-koivunen)]

Hate to spam you all again but I have got some new information and corrections to the previous post:

1. BUG: string I wrote isn't exactly the correct one, however, you can understand it is a result of BUG(...) macro in kernel
2. I haven't been able to reproduce the crash with BUG: output, at least with sync in my root filesystems options (/etc/fstab)
3. What I am able to reproduce everytime is:

a. Start Kubuntu
b. Log in to KDE
c. Connect to your local WLAN AP (I'm using WPA Enterprise connection at my school)
d. Open Konqueror and go to http://www.kernel.org
e. Start downloading the latest kernel (~40-60MB)
f1. Close the lid
    --> Total freeze
f2. Go to console before closing the lid
    --> Total freeze

In both cases, no any log messages. Sometimes the caps lock light is left burning.

Currently I'm building a new kernel with http://intellinuxwireless.org/ support...

This is damn irritating, I'll newer buy this shitty HP hardware again!

[Roger Irwin (rogirwin)]

In the past, the Linux/ACPI video driver invoked _DOS (Display Output Switch) with the parameter 1 to tell the BIOS to switch the video output display for us.

But this conflicts with Linux native graphics drivers, and can cause all sorts of issues, including hanging the system.

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

Here we change the Linux default to evaluate _DOS=0, which tells the BIOS to simply send us a hotkey event and not touch the graphics hardware.

The acpi video driver sends the display switch hotkey event up through the intput layer, and X can interpret that and use its native graphics driver to switch the display.

For the case where Linux has no native graphics driver running, or the graphics driver doesn't know how to switch video and the BIOS (safely) does, the previous behaviour can be restored with:

sudo echo 1 > /proc/acpi/video/*/DOS

I haven't had my computer crash since I did this..

[Joonas Koivunen (joonas-koivunen)]

I can confirm the advice from Roger, thanks a lot!

[Roger Irwin (rogirwin)]

I can't take the credit. It was copied from here: http://ubuntuforums.org/showthread.php?t=587390&page=3

[archdrone (archdrone)]

I confirm on HP 6510b, HH 8.04, 2.6.24-8-generic

[Hans Deragon (deragon)]

Nominated this bug for Hardy.

sudo echo 1 > /proc/acpi/video/*/DOS should be done automatically on machine that need this to be set.

[Gerhard Kremer (gerhardusm2002)]

I confirm the bug on HP 6120, Hardy beta, kernel 2.6.24-12-generic (but have this problem since Gutsy).

[Gerhard Kremer (gerhardusm2002)]

Roger's solution works for me too. Great!

[Matthew Garrett (mjg59)]

_DOS is set by the hotkey-setup init script. 7 is actually the correct value for us in this case.

[Launchpad Janitor (janitor)]

This bug was fixed in the package hotkey-setup - 0.1-17ubuntu21

---------------
hotkey-setup (0.1-17ubuntu21) hardy; urgency=low

  * Change the default _DOS value, preventing crashes on lid close.
    LP: #157691.

 -- Matthew Garrett <email address hidden> Thu, 10 Apr 2008 17:06:14 +0100

[Hans Deragon (deragon)]

hotkey-setup 0.1-17ubuntu21 does not fix this problem. My HP Compaq 6510b still freezes when lid is closed. And my interim workaround `echo 1 > /proc/acpi/video/*/DOS` continued to do the job.

I have put this bug's status back to "Confirmed".

[laga (laga)]

Hans,

the fix works on my 6510b. /proc/acpi/video/*/DOS is set to 7 and it doesn't crash when I close the lid.

[Hans Deragon (deragon)]

# sudo cat /proc/acpi/video/*/DOS # /proc/acpi/video/C098/DOS is the only file there.
DOS setting: <0>

Thus, in my case, the fix did not got installed properly on my HP Compaq 6510b. Probably an installation issue? Of course, I have the latest packages, including hotkey-setup 0.1-17ubuntu21. Cam someone instruct me how to debug this so we can fix the installation/upgrade issue?

[laga (laga)]

Hans Deragon schrieb:
> # sudo cat /proc/acpi/video/*/DOS # /proc/acpi/video/C098/DOS is the only file there.
> DOS setting: <0>
>
> Thus, in my case, the fix did not got installed properly on my HP Compaq
> 6510b. Probably an installation issue? Of course, I have the latest
> packages, including hotkey-setup 0.1-17ubuntu21. Cam someone instruct
> me how to debug this so we can fix the installation/upgrade issue?
>

Do you have /etc/init.d/hotkeys-setup?

If yes: what is your video driver in /etc/X11/xorg.conf? What does:

sed -n -e '/^[ \t]*section[ \\t]*"device"/I,/^[ \t]*endsection/I{/^[
\t]*driver[ \t]*/I{s/^[ \t]*driver[ \t]*"*//I;s/"*[ \t]*$//;p}}'
/etc/X11/xorg.conf

give you?

[Hans Deragon (deragon)]

#sudo ls -l /etc/init.d/hotkey-setup
-rwxr-xr-x 1 root root 3576 2008-04-10 12:49 /etc/init.d/hotkey-setup

Your sed command returns nothing. The graphic driver is not specified in the file.

/var/log/Xorg.0.log contains

(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
  i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
  E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ,
  965GM, 965GME/GLE, G33, Q35, Q33, Intel Integrated Graphics Device

Thanks.

[Alan Johnson (nilgiri)]

Hi, I also have a 6510b with a fresh install of Hardy. I used the work around to fix the problem on Gutsy, and it came back on with Hardy. The problem appears to be that the regex in that sed statement (which came from the hotkey-setup script) needs to be updated for the newer xorg.conf in the Hardy release (see attachment). The file now not only produces no matches for that regex, but it also contains no text matching the following case statement in the /etc/init.d/hotkey-setup. The Gutsy default xorg.conf (I'll have to post again to attach that example) produces the correct output when that sed regex is run on it.

Actually, it looks like the xorg.conf just does not contain the needed info any more, so something else is going to have to be searched.

Glad I backed up /etc before I did a clean upgrade Hardy. I learned from my Feisty-Gutsy upgrade experience. =)

[Alan Johnson (nilgiri)]

Here's the Gutsy fresh xorg.conf on this 6510b

[Ivan Noris (deja-vix)]

Hmm.

After a few days (actually, from the release date of Hardy) I've searched for this solution. I'm using Thinkpad R60e with Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03). Closing the laptop lid was a disaster for me until today.

According to the comments here I realized that /etc/init.d/hotkey-setup needs to be updated for me to use "i810" string rather than "intel". (One-line patch).

Attaching diff, if someone's interested. Strange that I have found nothing related to Thinkpads :(

[Kieran Fleming (kieran-fleming)]

What about matching hardware from lspci?
It is the best place to find this info IMO, and it means that the fix will only be applied on chips where we know it's needed on.

[Mathieu Leplatre (mathieu.leplatre)]

Here is mine !
Thanks & Good luck !

[Gerhard Kremer (gerhardusm2002)]

Can I suggest trying the new Intrepid PPA kernel? In my case, it solved the problem. See bug #206511 for details.

[Gabriele Vivinetto (gabriele.vivinetto)]

The bug is still present in Hardy on my HP6510b.
/etc/init.d/hotkey-setup does not work for me.

[Gabriele Vivinetto (gabriele.vivinetto)]

This is because there is no more a reference in /etc/X11/xorg.conf to the "intel" driver, that is loaded automatically.
So the function do_video() in /etc/init.d/hotkey-setup does not work.
The bug should be transferred to hotkey-setup ?

[Ivan Noris (deja-vix)]

Hmm.

Last time I rebooted, my own "patch" was not working.
I realized that I need to run /etc/init.d/hotkey-setup start AFTER I log into GNOME. So I added the script to my session.

I don't really understand this :-(

[petski (petski)]

I've used Launchpad's PPA to build a new version of the hotkey-setup package.

It covers these changes:

  * Merged with Debian unstable (version 0.1-21)
  * Allow more than one driver in xorg.conf
  * Added 'coreutils' to Depends (because we need '/usr/bin/uniq')
  * Added 'pciutils' to Depends (because we need '/usr/bin/lspci')
  * Changing DOS to 7 for HP's 8086:2a03 (LP: #157691)
  * Changed small typo in init script

Attached you'll find the diff between Debian's "hotkey-setup_0.1-21" and the version in my PPA.

To test the package, use:

$ sudo sh -c 'echo deb http://ppa.launchpad.net/petski/ubuntu hardy main > /etc/apt/sources.list.d/LP157691.list'
$ sudo sh -c 'echo deb-src http://ppa.launchpad.net/petski/ubuntu hardy main >> /etc/apt/sources.list.d/LP157691.list'
$ sudo apt-get update
$ sudo apt-get upgrade # Ignore warning about the unauthenticated hotkey-setup package.
$ sudo /etc/init.d/hotkey-setup restart

Close your lid to see what happens. If successful, please reboot and try to close the lid again.

To revert the changes you've made:

$ sudo rm -f /etc/apt/sources.list.d/LP157691.list
$ sudo apt-get update
$ sudo apt-get install 'hotkey-setup=0.1-17ubuntu21'

HTH

[Peter Veerman (pveerman)]

Petski Thanks for the patch, it does work for me.

[rebugger (rebugger)]

Thanks alot petski, it works great.

[maknu (mail-maknu)]

Petski, you're really great! This patch is working fine on my HP 2510p! Thanks!

[nostra (nostra)]

Works great for me. thanks petski.

[igor_mk (isaldev)]

Thanks petski, works for me, on HP Compaq 6720s. But since the beginning, the back-light does not turn off when I close the lid. And Power management is set to blank screen, on lid close. Thanks.

[Joonas Koivunen (joonas-koivunen)]

to igor_mk:
Have you tried disabling DPMS power management from the kde system settings? It seemed to do the job for me.

In 8.04 if I have DPMS (in kde sys settings) blanked out screen looks like theres one of the backlights is broken (which isn't the case), turning off the DPMS makes the screen turn off once in a while, haven't yet found a way to configure it though.

This could be a bug that kde system settings toggles the "xset dpms" somehow.. Too bad there doesn't seem to be an easy way to check this as "xset dpms" does not return anything.

[igor_mk (isaldev)]

I have gnome, not kde. Does this makes a difference?
xset dpms does not return anything

[Mathieu Leplatre (mathieu.leplatre)]

Thank you petski, the patch works for me on HP 6710b.

[Kieran Fleming (kieran-fleming)]

This bug seems to be fixed in intrepid alpha 5.

[Alan Johnson (nilgiri)]

Sorry folks, but this still does not work for me. I also now have Hardy running on a Dell Latitude D630 and it has the same problem. Both this and my HP 6510b I mentioned before have an Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller. I suspect this bug will apply to all machines running Hardy with this controller (maybe even any Intel). All of the hotkey-setup patches posted so far have the same broken sed statement failing to find anything useful in Hardy's default xorg.conf. Please see my previous post and the few preceding it for details.

I expect that

for x in /proc/acpi/video/*/DOS; do echo -n 7 >$x; done

described above, will fix the problem on this laptop as well. I'll repost here if not. I just put this in /etc/rc.local before the exit 0 command, so as to not interfere with any patches on hostkey-setup that might make it into the repos.

[Joonas Koivunen (joonas-koivunen)]

I too have noticed that neither using the PPA package provided above or the "echo -n 7 > .../DOS" line in rc.local does the trick. But when I do it manually (either restart hotkey-setup or just echo it) AFTER logging in (through the graphical login so that X is running) it works and even hibernating/suspending/recovering works most of the time.

[Davíð Jakobsson (rimmugygur)]

Confirming that petski's patch works on HP 6710b. Thanks man!

[Loïc Minier (lool)]

I'm reassigning from acpid to linux, matching the remote bug watch as there were reports of "[<timestamp>] BUG: Could not handle a NULL pointer reference in kernel."; if the machine freezes, this is not an userspace problem.

[Steve Langasek (vorlon)]

I'm told by Matthew Garrett that the problem causing kernel crashes when closing the lid on HPs is resolved in recent kernels; and in any case the latest hotkey-setup package does set the DOS value to 7 for all systems with Intel video chipsets. So I think this bug can be considered fixed.

[Steve Langasek (vorlon)]

For hardy, backporting the change to hotkey-setup to also change the DOS setting on i810 chipsets is also reasonable and appropriate; but I don't think we'll be changing the kernel side of this.

[Andrew Petelin (adrianopol)]

Item #33 solved problem. Thanks!

[Bjorn Helgaas (bjorn-helgaas)]

I think this is the same issue as http://bugzilla.kernel.org/show_bug.cgi?id=13751 . The root cause of 13751 seems to be a BIOS defect in SMI handling that corrupts registers or memory when the SMI handler runs somewhere other than CPU 0. One way to workaround it is to boot with "nosmp". Another is to do something like comment #33, which prevents the software-initiated SMI.

But I think the best way is to use the kernel patch I attached to 13751, which works around the BIOS defect directly by forcing the software SMI initiation to run on CPU 0. This should solve the problem without requiring any user-space workarounds.

[RayH (ray-hunter)]

I got hit by this bug too.....

Hardware HP6710B

root@X01:~# uname -a
Linux X01 2.6.24-24-generic #1 SMP Fri Jul 24 22:15:50 UTC 2009 x86_64 GNU/Linux

Symptom
=======

Closing the lid amost always caused a kernel panic. Everything on the machine freezes.
Only reason I know for sure it was a pnic was I switched to a text terminal before trying this and saw the panic text: there's nothing in the logs. You cannot change to other terminal or log in remotely.
Only way to reboot is to hold down the power key for 4 seconds for a hard reset.

workaround:
==========

change the power management option on the Gnome desktop to "do nothing" on lid closure (the backlight goes off anyway apparently in hardware)

check this is working

echo 1 > /proc/acpi/video/C098/DOS

and then close the lid and check if you can log in remotely, or work agian by re-opeing the lid.

if this works, permanently override the default by adding to rc.local

sudo vi /etc/rc.local and add the following lines

echo 1 > /proc/acpi/video/C098/DOS
exit 0

[Bjorn Helgaas (bjorn-helgaas)]

On Monday 10 August 2009 10:22:38 am RayH wrote:
> I got hit by this bug too.....

This patch should fix it:

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

If it doesn't, let me know.

Bjorn

> Hardware HP6710B
>
> root@X01:~# uname -a
> Linux X01 2.6.24-24-generic #1 SMP Fri Jul 24 22:15:50 UTC 2009 x86_64 GNU/Linux
>
> Symptom
> =======
>
> Closing the lid amost always caused a kernel panic. Everything on the machine freezes.
> Only reason I know for sure it was a pnic was I switched to a text terminal before trying this and saw the panic text: there's nothing in the logs. You cannot change to other terminal or log in remotely.
> Only way to reboot is to hold down the power key for 4 seconds for a hard reset.
>
> workaround:
> ==========
>
> change the power management option on the Gnome desktop to "do nothing"
> on lid closure (the backlight goes off anyway apparently in hardware)
>
> check this is working
>
> echo 1 > /proc/acpi/video/C098/DOS
>
> and then close the lid and check if you can log in remotely, or work
> agian by re-opeing the lid.
>
> if this works, permanently override the default by adding to rc.local
>
> sudo vi /etc/rc.local and add the following lines
>
> echo 1 > /proc/acpi/video/C098/DOS
> exit 0
>

[RayH (ray-hunter)]

The patch didn't apply properly automatically: it was rejected because the context was incorrect. I've tried adding it manually by using vi. We'll see what happens when I recompile the kernel but I'm not so hopeful.

Here's the diff I ended up with: osl.c is the linux kernel src for Ubuntu as of 2.6.24-24 osl.c.new is what I created manually after applying your proposed patch.

diff osl.c osl.c.new
183c183
< acpi_status acpi_os_initialize1(void)
---
> static void bind_to_cpu0(struct work_struct *work)
185,197c185,215
< /*
< * Initialize PCI configuration space access, as we'll need to access
< * it while walking the namespace (bus 0 and root bridges w/ _BBNs).
< */
< if (!raw_pci_ops) {
< printk(KERN_ERR PREFIX
< "Access to PCI configuration space unavailable\n");
< return AE_NULL_ENTRY;
< }
< kacpid_wq = create_singlethread_workqueue("kacpid");
< kacpi_notify_wq = create_singlethread_workqueue("kacpi_notify");
< BUG_ON(!kacpid_wq);
< BUG_ON(!kacpi_notify_wq);
---
> set_cpus_allowed(current, cpumask_of_cpu(0));
> kfree(work);
> }
>
> static void bind_workqueue(struct workqueue_struct *wq)
> {
> struct work_struct *work;
>
> work = kzalloc(sizeof(struct work_struct), GFP_KERNEL);
> INIT_WORK(work, bind_to_cpu0);
> queue_work(wq, work);
> }
>
> acpi_status acpi_os_initialize1(void)
> {
> /*
> * On some machines, a software-initiated SMI causes corruption unless
> * the SMI runs on CPU 0. An SMI can be initiated by any AML, but
> * typically it's done in GPE-related methods that are run via
> * workqueues, so we can avoid the known corruption cases by binding
> * the workqueues to CPU 0.
> */
> kacpid_wq = create_singlethread_workqueue("kacpid");
> bind_workqueue(kacpid_wq);
> kacpi_notify_wq = create_singlethread_workqueue("kacpi_notify");
> bind_workqueue(kacpi_notify_wq);
> kacpi_hotplug_wq = create_singlethread_workqueue("kacpi_hotplug");
> bind_workqueue(kacpi_hotplug_wq);
> BUG_ON(!kacpid_wq);
> BUG_ON(!kacpi_notify_wq);
> BUG_ON(!kacpi_hotplug_wq);

[RayH (ray-hunter)]

Yup Patch fails as I feared..... I admit to being really out of my depth here, but it looks very much like a lot has changed in this driver from when you generated your patch.... the hotplug section simply isn't declared any more (or else I've been dumb and missed some config item that has changed the source code).

drivers/acpi/osl.c: In function ‘acpi_os_initialize1’:
drivers/acpi/osl.c:211: error: ‘kacpi_hotplug_wq’ undeclared (first use in this function)
drivers/acpi/osl.c:211: error: (Each undeclared identifier is reported only once
drivers/acpi/osl.c:211: error: for each function it appears in.)
make[3]: *** [drivers/acpi/osl.o] Error 1
make[2]: *** [drivers/acpi] Error 2
make[1]: *** [drivers] Error 2
make[1]: Leaving directory `/usr/src/linux-source-2.6.24'
make: *** [debian/stamp-build-kernel] Error 2

[Bjorn Helgaas (bjorn-helgaas)]

On Monday 10 August 2009 11:52:32 am RayH wrote:
> The patch didn't apply properly automatically: it was rejected because
> the context was incorrect. I've tried adding it manually by using vi.
> We'll see what happens when I recompile the kernel but I'm not so
> hopeful.

Yep, that context changed a bit since 2.6.24. I can't really read
the old-style diffs (try "diff -u" for a newer, more readable
format), but I think you did it right. Let me know what happens.

> Here's the diff I ended up with: osl.c is the linux kernel src for
> Ubuntu as of 2.6.24-24 osl.c.new is what I created manually after
> applying your proposed patch.
>
> diff osl.c osl.c.new
> 183c183
> < acpi_status acpi_os_initialize1(void)
> ---
> > static void bind_to_cpu0(struct work_struct *work)
> 185,197c185,215
> < /*
> < * Initialize PCI configuration space access, as we'll need to access
> < * it while walking the namespace (bus 0 and root bridges w/ _BBNs).
> < */
> < if (!raw_pci_ops) {
> < printk(KERN_ERR PREFIX
> < "Access to PCI configuration space unavailable\n");
> < return AE_NULL_ENTRY;
> < }
> < kacpid_wq = create_singlethread_workqueue("kacpid");
> < kacpi_notify_wq = create_singlethread_workqueue("kacpi_notify");
> < BUG_ON(!kacpid_wq);
> < BUG_ON(!kacpi_notify_wq);
> ---
> > set_cpus_allowed(current, cpumask_of_cpu(0));
> > kfree(work);
> > }
> >
> > static void bind_workqueue(struct workqueue_struct *wq)
> > {
> > struct work_struct *work;
> >
> > work = kzalloc(sizeof(struct work_struct), GFP_KERNEL);
> > INIT_WORK(work, bind_to_cpu0);
> > queue_work(wq, work);
> > }
> >
> > acpi_status acpi_os_initialize1(void)
> > {
> > /*
> > * On some machines, a software-initiated SMI causes corruption unless
> > * the SMI runs on CPU 0. An SMI can be initiated by any AML, but
> > * typically it's done in GPE-related methods that are run via
> > * workqueues, so we can avoid the known corruption cases by binding
> > * the workqueues to CPU 0.
> > */
> > kacpid_wq = create_singlethread_workqueue("kacpid");
> > bind_workqueue(kacpid_wq);
> > kacpi_notify_wq = create_singlethread_workqueue("kacpi_notify");
> > bind_workqueue(kacpi_notify_wq);
> > kacpi_hotplug_wq = create_singlethread_workqueue("kacpi_hotplug");
> > bind_workqueue(kacpi_hotplug_wq);
> > BUG_ON(!kacpid_wq);
> > BUG_ON(!kacpi_notify_wq);
> > BUG_ON(!kacpi_hotplug_wq);
>

[Bjorn Helgaas (bjorn-helgaas)]

On Monday 10 August 2009 12:01:40 pm RayH wrote:
> Yup Patch fails as I feared..... I admit to being really out of my depth
> here, but it looks very much like a lot has changed in this driver from
> when you generated your patch.... the hotplug section simply isn't
> declared any more (or else I've been dumb and missed some config item
> that has changed the source code).
>
> drivers/acpi/osl.c: In function ‘acpi_os_initialize1’:
> drivers/acpi/osl.c:211: error: ‘kacpi_hotplug_wq’ undeclared (first use in this function)
> drivers/acpi/osl.c:211: error: (Each undeclared identifier is reported only once
> drivers/acpi/osl.c:211: error: for each function it appears in.)
> make[3]: *** [drivers/acpi/osl.o] Error 1
> make[2]: *** [drivers/acpi] Error 2
> make[1]: *** [drivers] Error 2
> make[1]: Leaving directory `/usr/src/linux-source-2.6.24'
> make: *** [debian/stamp-build-kernel] Error 2

Can you just send me a copy of the unmodified drivers/acpi/osl.c file
from Ubuntu? I'll send you back a patched version.

Bjorn

[RayH (ray-hunter)]

Here's the original distribution of osl.c for your inforation

[Bjorn Helgaas (bjorn-helgaas)]

OK, here's the patched osl.c for 2.6.24-24-generic. I see why the manually-applied upstream patch failed: upstream has three workqueues, but 2.6.24 has only two, so the kacpi_hotplug_wq bit doesn't work there.

[petski (petski)]

Hi all, please read up on LP #228399 , it might be related.

[RayH (ray-hunter)]

I can confirm that applying this patch to the standard 2.6.24-24-generic distribution and installing the resulting custom kernel seems to have solved the problem with the lid closing switch causing a kernel panic on the HP 6710B.

I'm not crazy about running a custom kernel, so bearing in mind that Gutsy is a long term support kernel, is it possible to make sure this patch makes its way into the general distribution?

Thanks for all of your help so far!