Bug 7165
Summary: | acpi_power_off called doesn't work - Medion MD95500 | ||
---|---|---|---|
Product: | ACPI | Reporter: | Markus Feldmann (feldmann_markus) |
Component: | Power-Off | Assignee: | Alexey Starikovskiy (astarikovskiy) |
Status: | REJECTED INVALID | ||
Severity: | normal | CC: | acpi-bugzilla |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | Debian Kernel 2.6.17-7 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
acpidump
dmesg dmidecode interrupts lspci |
Description
Markus Feldmann
2006-09-18 05:21:47 UTC
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.
|