Most recent kernel where this bug did not occur: Distribution: Debian Etch Hardware Environment: Laptop Medion MD95500 Software Environment: Problem Description: power off doesn't work with ACPI. Reboot functions well. After running the halt script the System doesn't really goes down, only goes down until it says "acpi_power_off called" and then he do nothing. Steps to reproduce:
Created attachment 9041 [details] acpidump
Created attachment 9042 [details] dmesg
Created attachment 9043 [details] dmidecode
Created attachment 9044 [details] interrupts
Created attachment 9045 [details] lspci
Did this work with any kernels before 2.6.17? Does it work with 2.6.18?
In debian the newest linux-source is 2.6.17-9 but i will try it at weekend. I will report it. kernel-image-2.4.27 did work well, but i think this was compiled with apm. I am not sure. I didnt test apm. Another thing is that it only sometimes goes wrong. lg Markus
Ok I installed the 2.6.18 from www.kernel.org . The most time it worked for me, but sometimes it hangs up too. How can I get debug messages which i can post ?
I activated the debug in the Kernel/ACPI. How can I get more debug messages? Here comes the message on shutdown, ... Done unmounting localfilesystems. Mounting root filesystems read-only ... done. Will now halt. Synchronising SCSI cache for disk sda: Powerdown. acpi_power_off_called hwsleeg-0285[02] enter_sleep_state: Entering sleep state [S5] Why does my disk syncs after he gets read-only? Could it be that he get trouble with the syncing time?
Please re-open this bug when the failure reproduces w/o loading the binary nvidia module. > hwsleeg-0285[02] enter_sleep_state: Entering sleep state [S5] This means that Linux is getting to the right place to power-off. However something has confused the firmware such that the request fails. Try simplifying the system by removing as many device drivers as possible -- it may be possible to isolate the failure to a particular device driver. Re: older releases. 2.4 is too old to be interesting, but if you could try something from kernel.org older than 2.6.17, it would be helpful to know if this system never powered off with 2.6, or if this has recently broken. Re: dmesg, be sure to use dmesg -s64000 to capture the full buffer back to the beginning.