Latest working kernel version: probably 2.6.25 (see below) Earliest failing kernel version: 2.6.26 Distribution: Debian Unstable Hardware Environment: MSI M673 laptop. 32 bit mode Software Environment: Problem Description: Sometimes my laptop does not poweroff automatically just after shutdown or hibernation. I've asked about this at linux-pm (https://lists.linux-foundation.org/pipermail/linux-pm/2008-December/019172.html) but it was about nvidia-tainted kernel. Now I'm able to reproduce this often enough without any binary modules. I'm currently using "nv" driver with X.org 1.5. This happens not every boot. And I don't know exactly how to reproduce it. It happens sometimes after playing movies with -vo xv. The most successfull way to reproduce is to try hibernation while KDE4 starts. I've verified this with both TuxOnIce as well as with in-kernel swsusp. It also happens with just shutdown (/sbin/halt). And I should press power button for 4-5 seconds to turn laptop off. I'm unsure about previous working kernel version. 2.6.25 was working IIRC, but I've flashed updated BIOS after this. Currently 2.6.25.20 fails too. I can't revert it, since old one is not available for download. I've asked MSI support for older BIOS version. Maybe some userspace update was cause of this. I'm unsure. Hang is happens at drivers/acpi/hardware/hwsleep.c do { status = acpi_get_register(ACPI_BITREG_WAKE_STATUS, &in_value); if (ACPI_FAILURE(status)) { return_ACPI_STATUS(status); } } while (!in_value); I've verified it by adding printk() to this loop. It just prints such printk message as fast as possible. I'm attaching dmesg of 2.6.28 boot. Please let me know if I can provide anything else.
Created attachment 19622 [details] 2.6.28 dmesg
Hi, Dmitry Will you please double check whether the issue happens on the kernel of 2.6.25? Will you please attach the output of acpidump, lspci -vxxx? Thanks.
Created attachment 19629 [details] acpidump output
Created attachment 19630 [details] lspci output
Outputs attached. I'll double check 2.6.25 kernel in 24 hours. Also currently there are two BIOS versions available for download: http://global.msi.com.tw/index.php?func=downloaddetail&type=bios&maincat_no=135&prod_no=1089 One is "for Windows XP" another is for Vista. I've tried both. Same behaviour Thanks
Currently 2.6.25.20 fails too at same hwsleep.c. Also this may be useful. I've reported another issues in times of 2.6.26 release. And it contains acpidump output from this laptop too. I'm sure that old one is made from "old" BIOS before upgrade. And they are different. Here is link: http://bugzilla.kernel.org/show_bug.cgi?id=11101#c7 Can we use it to try something?
Hi, Dmitry Will you please try the boot option of "nolapic_timer" on the latest kernel and see whether the box can be shutdown correctly? Thanks.
Created attachment 20436 [details] use the ioport tool to access the I/O port directly Will you please write the 0x3C01 to 0x4004 I/O port directly and see whether the box can be shutdown? How to use the attached tool is described in the readme. thanks.
I'll test it this weekend. Thanks
Ping Dmitry? How about the test result? Thanks.
Hi. Sorry for delay. Just installed 2.6.29 right now and successfully hibernate/resumed ~5 times. Since issue wasn't reproduceable every time, I'll back in 1-2 days. Thanks
Hi, Bug was reproduced with 2.6.29. Also I've tried attached tool. % sudo ./ior --addr 0x4004 --width 16 the value of IO port 0x4004 is 1 % sudo ./iow --addr 0x4004 --width 16 --value 0x3C01 the value written into IO port 0x4004 is 3c01 Then i decide to verify result: % sudo ./ior --addr 0x4004 --width 16 the value of IO port 0x4004 is 1c01 It was unable to poweroff laptop after hibernate. After resume value became 1 again. Thanks
Created attachment 20676 [details] 2.6.29 dmesg just after resume
PS. Kernel was untained and with "nv" X11 driver
Hi, Dmitry Thanks for the confirm. It seems that the box still can't be powered off even when the SLP_TYP is written to PM1A control register. How about the boot option of "nolapic_timer"? Thanks.
Hi. It _looks_ like nolapic_timer helps. However laptop works smaller amount of time from battery. Any other better fix?
Hi, Dmitry Do you mean that the box can be shutdown if the boot option of "nolapic_timer" is added? Will you please double check it? Thanks.
Hi, Yes. I'm still not sure, there were no "failed" hibernate attempts after adding nolapic_timer to kernel parameters. So I've done ~10 attempts and all of them were with correct shutdown
Hi. I just got failed shutdown even with nolapic_timer option. % cat /proc/cmdline root=/dev/mapper/laptop-deb_root resume=/dev/mapper/laptop-swap no_console_suspend r<o nolapic_timer
oops. cmdline was root=/dev/mapper/laptop-deb_root resume=/dev/mapper/laptop-swap no_console_suspend ro nolapic_timer. Just incorrectly pasted
Hi, Hapens a few times this week with nolapic_timer option. So I'm sure that this parameters do NOT solve issue for me
Created attachment 20924 [details] try the custom DSDT Will you please try the custom DSDT and see whether the box can be shutdown? How to use the custom DSDT can be found in : http://www.lesswatts.org/projects/acpi/faq.php As the DSDT.hex is attached, the first four steps can be skipped and you can start if from the fifth step. Thanks.
Hi, I'm in some travel now. Will back on wednesday and test it. Thanks
Finally tried custom DSDT. Machine still fails to shutdown. dmesg| grep DSDT shows that DSDT was really replaced: [ 0.020737] ACPI: Override [DSDT-1635X ], this is unsafe: tainting kernel [ 0.020803] ACPI: Table DSDT replaced by host OS [ 0.020948] ACPI: DSDT 00000000, 4A5E (r1 M S I 1635X 4162004 INTL 20081031) [ 0.021108] ACPI: DSDT override uses original SSDTs unless "acpi_no_auto_ssdt" [ 0.161507] ACPI: EC: Look up EC in DSDT
Hi, Dmitry Sorry for the late response. From the test the box still can't be shutdown even when writting the S5 SLP_TYP to PM1A control register. Maybe this is related with the BIOS. In fact we have another bug, in which the box can't shutdown. Even when the S5 SLP_TYP is writtne to the PM1A control register, the box can't be shutdown either. So I mark this as the duplicated bug of bug8549. Thanks. *** This bug has been marked as a duplicate of bug 8549 ***