I have a lenovo x201 thinkpad laptop. After a reboot or halt, the computer does not power off. All other commands seem to be executed correctly, and partitions are unmounted. The only way to power down is to hold in the on/off switch. This problem is non existent in kernel version kernel26-2.6.37-5-x86_6. I'm running Arch Linux
what is printed on the screen after you execute the poweroff command? What, exactly happens when you use the "reboot" command? Please attach the complete dmesg
Created attachment 61912 [details] dmesg.log dmesg.log as requested. This was generated using kernel kernel26-2.6.39.1-1-x86_64 which also exhibits this bug
the last line printed to the screen is REBOOTING or POWERING DOWN as normal. There is also a flashing underscore "_" below this. I can hear the hard drive spin down, but the laptop will not power down or reboot.
I'm seeing the same problem. It started appearing at kernel version 2.6.38, I believe. The weird thing is that it only occurs if the Ethernet cable is *not* plugged into the laptop. In particular, after the laptop hangs during reboot/shutdown, plugging in the Ethernet cable correctly shuts the laptop down within a second or two. Also, it seems that the problem only occurs if interface eth0 is up. For some reason, starting with 2.6.38, eth0 *has* to be up for me for Wake On LAN to work (that was not the case with 2.6.37). And that's *not* a e1000e driver regression in 2.6.38, because I copied over the whole drivers/net/e1000e tree from 2.6.37 to 2.6.38 and it did *not* help. For reference, here's my related e1000e bug report: https://sourceforge.net/tracker/?func=detail&atid=447449&aid=3300273&group_id=42302
Problem persists in version kernel version 3
Created attachment 70702 [details] image of error after poweroff command fails As of Kernel version 3 I now receive some text output after the powerdown command. Perhaps it can shed some light on the problem. It appears to me that the hard drive spins down, then spins up again after a few seconds. It takes probably 20 seconds for all the text in this image to be displayed.
Created attachment 70712 [details] Updated dmesg.log for kernel 3 Updated dmesg.log for kernel version 3
Now on Kernel Version 3.1.7-1-ARCH . Managed to find a work around. I added the following to my rc.local.shutdown file, and now it powers off after a halt or reboot. /etc/rc.d/wicd stop ifconfig eth0 down It seems the problem is with the ethernet driver. The computer also behaves properly when connected to an lan without the above workaround as mentioned above by Kamil Iskara. #Hardware Info $> lspci | grep net 00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection (rev 06)
Mike, there is a better workaround. I found that for me, the problem was actually triggered by running powertop. When you start powertop, at least the old <1.99 version, it offers to enable "Runtime Power Management". What this actually does is, essentially: for dpcontrol in /sys/bus/{pci,spi,i2c}/devices/*/power/control; do echo auto > "$dpcontrol" done I found that if various /sys/bus/pci/devices/*/power/control values are set to "auto" rather than the default "on", weird things happen at shutdown. So I modified my shutdown sequence to set them back to "on", and that fixed several weird problems I've been experiencing at shutdown. You can check how the values are set for you by doing: cat /sys/bus/pci/devices/*/power/control I wonder if there is a connection between this problem and pcie_aspm problems documented by Phoronix and recently fixed by Matthew Garrett? Both started occurring in the 2.6.38 kernel. Matt's fixes are supposed to be in 3.3, if I remember correctly. Would be nice if they fixed this issue too...
It's great that the kernel bugzilla is back. Can you please verify if the problem still exists in the latest upstream kernel?
I can verify that the problem is still present with 3.2.1. In order to trigger it, I need to shut down with eth0 (e1000e) up, no network cable plugged in, and /sys/bus/pci/devices/*/power/control set to "auto" (as powertop does). Setting the /sys values back to the default "on" on shutdown fixes it. See my comment #9 for more information.
*** Bug 33872 has been marked as a duplicate of this bug. ***
I can confirm this bug. I have Thinkpad T520 and kernel 3.2.5. If interface is up, no link is detected and /sys/class/net/eth0/device/power/control is set to auto, then poweroff and reboot hang at the very end + ethtool reports errors like that: darkhorse ~ # ethtool eth0 Settings for eth0: Cannot get device settings: No such device Cannot get wake-on-lan settings: No such device Cannot get message level: No such device Cannot get link status: No such device No data available
I have been trying to reproduce this issue on a T510 with a stock Arch Linux kernel (Linux 3.3.1). And so far so good, I can't reproduce it anymore. I tried to reproduce it by adding "auto" to /sys/bus/pci/devices/*/power/control and by installing laptop-mode-tools (which triggered this issue as well). See: https://bugzilla.kernel.org/show_bug.cgi?id=33872 But it's not hanging in shutdown anymore. Can anyone else try please?
It seems to be solved for me with Linux 3.3.1. At least it didn't hang on shutdown for me yet. BTW (Just FYI), laptop-mode-tools also automatically sets "auto" to all /sys/bus/pci/devices/*/power/control.
Yes, I can confirm that on Linux 3.3.1 shutdown and reboot work fine. ethtool though still behaves the way I described previously, which interferes with laptop-mode-tools trying to disable wake-on-LAN and is strange anyway.
I've just did a small test and reinstalled Linux 3.2.14, echoed "auto" to /sys/bus/pci/devices/*/power/control and shutdown, and it hanged as usual with "Disabling IRQ #16" plus other messages. So what changed between Linux 3.2.14 and 3.3.1 to resolve the shutdown hang/problem?
Tested 3.3.2 and it's fine there as well. I mean I can't reproduce the hang in 3.3.1 or 3.3.2 anymore. :D This makes me really happy.
bug closed.
@Zhang Rui: Thanks so much for getting this issue fixed. Can you guys at Intel comment what was the problem behind this issue and what you guys did to fix it? Just for curiosity. Thanks.
I experiencing this issue now with 3.8.1 on HP Compaq 8200 Elite SFF PC.