|Summary:||Intel DX58SO mainboard - powering off takes really long|
|Product:||ACPI||Reporter:||Tomasz Chmielewski (tch)|
|Severity:||normal||CC:||rjw, rui.zhang, yakui.zhao|
|Bug Depends on:|
2.6.31 .config used on Intel DX58SO mainboard
syslog from bootup till shutdown
write 0x3C01 to 0x404 and see whether the box is shutdown
lspci -vxxx output
Description Tomasz Chmielewski 2009-09-22 10:14:15 UTC
Comment 1 Zhang Rui 2009-09-23 03:29:08 UTC
please boot with boot option printk.time=1, poweroff and boot, then attach the /var/log/messages file.
Comment 2 Tomasz Chmielewski 2009-09-23 10:08:22 UTC
Created attachment 23147 [details] syslog from bootup till shutdown This is a full syslog output, fro system bootup to system shutdown. Obviously, it doesn't contain a long pause before which the system powers off, as then, syslog does not work anymore. Note that rebooting is very fast with this board (there is no delay after init.d shutdown sequence). Only powering down with 2.6.31 is very long and sometimes, the PC is not powered off (I tested it by waiting up to an hour, when the system was still not powered off - but was waiting: Halting system... [here, a long pause, and below sometimes never happens] Power down... Note that with this syslog, the system has 2 graphics card using proprietary fglrx driver. I tested shutting down without X enabled and without fglrx loaded and it is still long.
Comment 3 ykzhao 2009-09-24 07:23:27 UTC
Hi, Tomasz Which command is used to power off the box? poweroff or shutdown? Will you please use the following command and see whether it still take long time to shtudown the system? echo shutdown > /sys/power/disk echo disk > /sys/power/state Thanks.
Comment 4 ykzhao 2009-09-24 07:26:58 UTC
Created attachment 23166 [details] write 0x3C01 to 0x404 and see whether the box is shutdown will you please use the attached IO port tool to write 0x3C01 to 0x404 I/O port and see whether the box can be shutdown? ./iow --addr 0x404 --width 16 --value 0x3C01 Thanks.
Comment 5 ykzhao 2009-09-24 07:27:25 UTC
Will you please also attach the output of acpidump, lspci -vxxx? Thanks.
Comment 6 Tomasz Chmielewski 2009-09-24 08:48:59 UTC
Created attachment 23167 [details] acpidump output
Comment 7 Tomasz Chmielewski 2009-09-24 08:49:45 UTC
Created attachment 23168 [details] lspci -vxxx output
Comment 8 Tomasz Chmielewski 2009-09-24 08:52:18 UTC
I normally use "halt" to shutdown / poweroff this machine. I'll answer to your other questions in the evening; I only have remote access to this box right now.
Comment 9 Tomasz Chmielewski 2009-09-24 20:46:31 UTC
When I started: ./iow --addr 0x404 --width 16 --value 0x3C01 it immediately powered off the PC. Is this an expected result?
Comment 10 ykzhao 2009-09-25 00:56:35 UTC
Yes. This is the expected result. The last step in poweroff/shutdown is to write 0x3C01 to 0x404 I/O port. In such case the box can be poweroff/shutdown. Please use the poweroff to see whether it still takes long time. thanks.
Comment 11 Tomasz Chmielewski 2009-09-28 15:24:18 UTC
Whether I use shutdown, poweroff or halt, a /etc/init.d/halt script is executed. So I modified this script to see where it "hangs", by adding "-x" at the beginning of the script: #!/bin/bash -x The command which (sometimes) "hangs" with 2.6.31 is /sbin/halt: + exec /sbin/halt -i -d -p The meaning of these parameters is as follow: -d Don't write the wtmp record. The -n flag implies -d. -i Shut down all network interfaces just before halt or reboot. -p When halting the system, switch off the power. This is the default when halt is called as poweroff. Could it be that the network is blocking here? I don't use NFS nor iSCSI on this machine, so it shouldn't be the case. I'll remove the "-i" parameter to see if it changes anything though.
Comment 12 Tomasz Chmielewski 2009-09-29 09:07:27 UTC
Removing the "-i" parameter does not change anything, powering off can still take very long with 2.6.31.x kernels.
Comment 13 ykzhao 2009-09-29 09:33:31 UTC
How about the following command? >echo shutdown > /sys/power/disk >echo disk > /sys/power/state It can also be used to shutdown. Thanks.
Comment 14 Tomasz Chmielewski 2009-10-04 13:08:22 UTC
I was about to bisect it (issue does not happen with 2.6.30; does happen with 2.6.31-rc1). But I just booted and powered off 2.6.32-rc1 several times and I don't see this issue any more. So I think we can close this bug? If it reappears, I'll reopen.
Comment 15 Tomasz Chmielewski 2009-10-04 13:09:06 UTC