Bug 14205 - Intel DX58SO mainboard - powering off takes really long
Summary: Intel DX58SO mainboard - powering off takes really long
Status: CLOSED DOCUMENTED
Alias: None
Product: ACPI
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: acpi_other
URL:
Keywords:
Depends on:
Blocks: 13615
  Show dependency tree
 
Reported: 2009-09-22 10:14 UTC by Tomasz Chmielewski
Modified: 2009-10-04 13:09 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.31
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
2.6.31 .config used on Intel DX58SO mainboard (98.56 KB, application/octet-stream)
2009-09-22 10:14 UTC, Tomasz Chmielewski
Details
syslog from bootup till shutdown (96.01 KB, application/octet-stream)
2009-09-23 10:08 UTC, Tomasz Chmielewski
Details
write 0x3C01 to 0x404 and see whether the box is shutdown (2.47 KB, patch)
2009-09-24 07:26 UTC, ykzhao
Details | Diff
acpidump output (220.74 KB, text/plain)
2009-09-24 08:48 UTC, Tomasz Chmielewski
Details
lspci -vxxx output (35.58 KB, text/plain)
2009-09-24 08:49 UTC, Tomasz Chmielewski
Details

Description Tomasz Chmielewski 2009-09-22 10:14:15 UTC
Created attachment 23138 [details]
2.6.31 .config used on Intel DX58SO mainboard

Not sure if it's ACPI related or not...

On Intel DX58SO mainboard with 2.6.31 kernel, powering off takes really long.

With 2.6.30 these last steps of shutting down the computer take at most 5 seconds:

Halting system...
[Here up to 5 seconds wait]
Power down...
[Here the PC is turned off, fan, disks etc. is off]



With 2.6.31 with the same .config, it usually takes something around 30-240 seconds, sometimes it takes ~5 minutes; very rarely, it never powers down:


Halting system...
[Here ~30-240 seconds wait, sometimes more]
Power down...
[Here the PC is turned off, fan, disks etc. is off]


I have the latest BIOS installed; this happened with previous BIOS releases as well.
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
Closing.

Note You need to log in before you can comment on or make changes to this bug.