Subject : AMD64 reboot regression Submitter : "Michael B. Trausch" <mike@trausch.us> Date : 2008-11-02 20:30 References : http://marc.info/?l=linux-kernel&m=122565790519736&w=4 This entry is being used for tracking a regression from 2.6.27. Please don't close it until the problem is fixed in the mainline.
Caused by: commit 8fd145917fb62368a9b80db59562c20576238f5a Author: Zhao Yakui <yakui.zhao@intel.com> Date: Fri Oct 17 14:22:27 2008 -0400 ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
Will you please attach the output of acpidump? Before the patch in comment #1 is merged, the RESET_REG_SUP bit will be checked to indicate whether the ACPI reboot mechanism. Unfortunately on some laptops there exists the definition of RESET_REG but the RESET_REG_SUP bit is zero, which indicates that ACPI reboot mechanism is unsupported. And on these laptops the system only can be rebooted by ACPI reboot mechansim after resuming from S3(by writing RESET_VALUE to RESET_REG port). So I change the check method about ACPI reboot mechanism in the patch of comment #1. Thanks.
Created attachment 18605 [details] Output of 'acpidump' This is the output from acpidump. When I did it, I also received a warning on stderr: $ sudo acpidump > acpidump.out.txt Wrong checksum for OEMB! Not sure if this is relevant or not. All I _do_ know is that something between what was there originally and is there now, there is a problem. Maybe some check can be done that switches the code based on the system? I don't know anything about the problem on other people's systems that caused the change from 17-Oct to become necessary, so I don't know if that's even possible.
Hi, Michael From the acpidump in comment #3 it seems that the RESET_REG_SUP flag bit is zero but there exists the definition of RESET_REG & RESET_VALUE. RESET_REG: Access_width : 8 Address: 0xCF9 I/O Port. RESET_VALUE: 0x06 It seems that this box can't be rebooted by writing RESET_VALUE to RESET_REG port. But if the system can't be rebooted by ACPI reboot, it will fall back to BOOT_KBD reboot type.
Created attachment 18606 [details] use the attached tool to write some I/O ports Will you please use the attached tool to write the 0x06 to 0xCF9 I/O port and see whether the system can be rebooted? ./iow --addr 0xCF9 --width 8 --value 0x06 After writing the 0x06 to 0xCF9 I/O port, please attach the screenshot. Thanks.
Will you please confirm whether the windows can work well on this box? Thanks.
On Sun, 2 Nov 2008 21:19:59 -0800 (PST) yakui.zhao@intel.com wrote: > Hi, Michael > From the acpidump in comment #3 it seems that the RESET_REG_SUP > flag bit is zero but there exists the definition of RESET_REG & > RESET_VALUE. RESET_REG: Access_width : 8 > Address: 0xCF9 I/O Port. > RESET_VALUE: 0x06 > > It seems that this box can't be rebooted by writing RESET_VALUE to > RESET_REG port. But if the system can't be rebooted by ACPI reboot, > it will fall back to BOOT_KBD reboot type. Hello! I am not exactly sure what all that means. Are you able to determine why the code that was in the kernel prior to 17-Oct-2008 works, but the current code does not? Using the old code, my system will reboot successfully; using the new code, it hangs right after the kernel prints "[xxxxxx.xxxxxx] Restarting system" to the screen---hard lock up, not even the SysRq keys will get the kernel to do anything, and I am then forced to press the reset button or power cycle the machine to reboot. Would operating in Long Mode have any effect on this? I do run my system with a 64-bit kernel. --- Mike
(In reply to comment #6) > Will you please confirm whether the windows can work well on this box? If you mean does Microsoft Windows reboot successfully, I don't know. I do not have a 64-bit version of Windows to be able to determine whether it works or not; 32-bit versions work just fine, but rebooting on x86 in protected mode is (I thought) pretty standard since you can always drop back to real mode. I will have a response to comment #5 shortly.
(In reply to comment #5) > Created an attachment (id=18606) [details] > use the attached tool to write some I/O ports > > Will you please use the attached tool to write the 0x06 to 0xCF9 I/O port and > see whether the system can be rebooted? > ./iow --addr 0xCF9 --width 8 --value 0x06 > > After writing the 0x06 to 0xCF9 I/O port, please attach the screenshot. > Thanks. > Replying to comment #5: I took a video of this process as well (4:00, ~49 MiB). I will upload it somewhere on request if it would help to actually see the process I went through here. The first time I booted an unpatched git kernel from 2.6.28-rc2 (2.6.28-rc2-00185-ge946217). This kernel locks up immediately upon printing the "Restarting system" message to the console. The second boot was a kernel from git, with commit 8fd14591 reverted, based on 2.6.28-rc2 with some of the git updates. This kernel reboots successfully. The third boot was done using the same kernel as the second boot. The "iow" command that was supplied in comment #5 was executed, and then a reboot was attempted. The result was that the kernel locked up the same as the first, unpatched 2.6.28-rc2 kernel from git did. When the iow command was run, the display read: # ./iow --addr 0xCF9 --width 8 --value 0x06 the value written into IO port 0xcf9 is 6 I then attempted the reboot, wherein it locked up after printing "Restarting system." Please let me know if any more information is needed.
Thanks for the test. It is inappropriate to ignore the flag of RESET_REG_SUP when acpi reboot mechanism is used although it can solve the issue on some laptops that the system can be rebooted after resuming from S3. Please revert the commit in comment #1. thanks.
reverted 8fd145917fb62368a9b80db59562c20576238f5a in acpi tree.
Handled-By : Len Brown <lenb@kernel.org> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=11942#c11
*** Bug 11910 has been marked as a duplicate of this bug. ***
shipped in 2.6.28-rc4-git3 not needed in .stable, since this regression was post 2.6.27. closed. commit d17cb18a07c587b8f9ff174a1bf6d03413eabe64 Author: Len Brown <len.brown@intel.com> Date: Thu Nov 6 20:51:59 2008 -0500 Revert "ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism" This reverts commit 8fd145917fb62368a9b80db59562c20576238f5a.