Distribution: Gentoo Linux 2004.2
Hardware Environment: HP nx7000
Problem Description: When I compile a 2.6.9-rc1 or -rc2 kernel with
CONFIG_ACPI_BUTTON=y, 'shutdown -h now' does a reboot instead of a shutdown.
With all previous 2.6.x kernel versions I have tried, there has been no problem
with this ACPI option and shutdown.
Steps to reproduce:
1. Compile and install a 2.6.9-rc1 or -rc2 kernel with CONFIG_ACPI_BUTTON=y
2. Execute: shutdown -h now
Could you please attach a dmesg and /proc/acpi/dsdt ?
Created attachment 3683 [details]
Here is my dmesg
Created attachment 3684 [details]
Here is my /proc/acpi/dsdt
I have the same problem with zt3000 (the sister model of nx7000).
It first started happening somewhere between 2.6.7-mm1 and 220.127.116.11-mm2.
On an interesting note, the problem only occurs when connected to AC - when
running on battery power shutdown works fine.
I can comfirm that the same thing happen with 2.6.9-rc2:
- On AC => reboot
- On battery => shutdown
Created attachment 3692 [details]
Patch to DSDT
There is an error in your DSDT.
I doubt that this is the cause of the problem, but anyway, here is the patch to
get rid of that error.
This kind of patch was totally new for me, but I followed the instructions from:
Booted my static DSDT override patched kernel, but 'shutdown -h now' still reboots.
I too am pretty sure it's not the DSDT. I remember fixing mine a while back, but
it made no difference that I could notice, so I reverted it. Plus the problem is
quite clearly associated with specific kernel versions, so....
Another (very annoying) thing I noticed is that sometimes (1 in 3-4 maybe?) when
it does actually shutdown, it goes into a "bad" state, where it will no longer
turn on just by pressing the power button. I have to unplug it, remove the
battery, let it sit for while, and only then will it power on again.
Not sure if it might be caused by deffective hardware... Peter does that ever
happen to you?
No, everything has been rock solid. Until 2.6.9-rc1.
Same Problem here with an NX7000 and the 2.6.9-rc3 kernel. No shutdown only a
With the Kernel 18.104.22.168 it works fine.
Updatet yesterday to 2.6.9-rc3.
I have the same problem with 2.6.9-rc4 on an nx7010. Otherwise the same as the
rest of the reports: only happens when on AC, problem exists since rc1.
I'm having the same problem with my laptop shutting down and immediately
switching back on. The (only) change to drivers/acpi/button.c in 2.6.9 (BK 1.25)
looks a wee bit suspicious as it dealing with wakeups.
I'd suggest commenting out the "if (device->wakeup.flags.valid)" statement and
see if it fixes the problem. I'll try later today when I finish work.
Nope, still switches back on. Problem is elsewhere.
I'm having same troubles on nx7010 on 2.6.9-stable. As above stated, it only
occurs when running on AC, no matter whether the battery is inserted or not. I
switched a few days ago directly from 2.6.7 where the problem does not exist. I
will check for diffs in acpi code and hopefully me or someone else will find the
source of the problem as it is rather annoying not to be able to shut your
laptop properly down.
same problem on Acer TM 630
It does not shut down w/ oder w/o AC - it reboots in either case.
It only shuts down with lid closed.
Tested again with Kernel 2.6.10-rc1 but problem still exists... No change for me :-(
Hope the problem will be fixed, because it's really annoying...
see if is not a duplicated bug of bug2109
please try the patch in bug 3669
I took the patch in bug 3669, and applied it to kernel 2.6.9. I cannot build the
kernel, unleass I also modify the Makefile in the drivers/acpi/sleep directory
so it also compiled wakeup.c (I don't know if this is due to that the patch i
tailored for another kernel version, or due to my kernel config or to some
errors in the patch). But when this kernel is installed, a 'shutdown -h now' now
works as before, i.e. my laptop i powered off properly.
Confirm that with this patch my HP nx7010 now powers off correctly when running
on AC power (and checked that battery power continued to shutdown as normal).
*** This bug has been marked as a duplicate of 3669 ***