Latest working kernel version: < 2.6.18 Earliest failing kernel version: > 2.6.19 Distribution: any, I'm use Gentoo, openSuSE 10.3,11.0, ALT Linux 4.1 Hardware Environment: NoteBook ASuS X50N (F5N) Software Environment: Problem Description: Reboot does not work. System shows message about restarting system, but not restarting. Halt work properly. Changing versions BIOS - has not produced results
Created attachment 17724 [details] reboot via acpi Could you try the attached patch please? It changes the reboot default.
No, this patch is not work
Will you please attach the output of acpidump? Will you please try the latest kernel(2.6.28-rc2) and see whether the box can be rebooted? Maybe on your box the ACPI reset reg is defined in ACPI FADT table. But the RESET_REG_SUP flag bit indicates that ACPI reboot mechanism is not supported. So the reboot_type falls back to BOOT_KBD. After the following commit is shipped, RESET_REG_SUP flag is not checked any more. Instead the ACPI reset reg is checked to determine whether the ACPI reboot mechanism is supported. If supported, it will be used to reboot the system. Otherwise it means that ACPI reboot mechanism is not supported and it will fall back to BOOT_KBD. >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 thanks.
As there is no response for more than one month, the bug will be rejected. If the problem still exists on the latest kernel, please reopen it again and attach the output of acpidump, dmidecode. Thanks.
ACPIDUMP: http://paste.org/5124 DMIDECODE: http://paste.org/5125 2.6.28 ... 2.6.29_rc2-r3 - restart NOT work.
Debian Lenny - not work (with 2.6.19-2.6.29 kernels) Ubuntu can reboot with ALL_IDE_GENERIC option
Gentoo, ALT, openSuSE not work with 2.6.18-2.6.29 kernels Knoppix, ALT, Gentoo & maybe other whis kernel 2.6.16-2.6.17 - restart & halt work correctly.
Hi, Palach Will you please attach the output of acpidump? Not use the link.
I send it to your e-mail, it's very long
Created attachment 20207 [details] ACPIdump for Debian Lenny AMD64, Kernel 2.6.28
Created attachment 20213 [details] acpidump
Created attachment 20214 [details] dmidecode
Hi, Palach Thanks for the info of acpidump && dmidecode. From the acpidump it seems that there exists the definition of ACPI RESET_REG. > Reset REG: 0x64 I/O port > Reset Value: 0xFE But unfortunately the RESET_REG_SUP bit of FADT.flags is cleared, which means that the ACPI reset is not supported. So the acpi reset won't be used. How about adding the following boot option? a. reboot=t b. reboot=b Thanks.
Debian Lenny AMD64, Kernel 2.6.28 a. reboot=t b. reboot=b No, this magic didn't work :-(
Hi, Veresk thanks for the confirm. If the system works on the 64-bit mode, the boot option of "reboot=b" is redundant. It is only useful for 32-bit OS. And it is very strange that the reboot still can't work even after the INT3 is triggered. How about the boot option of "reboot=p"? When it is added, the 0xCF9 I/O port is used? Thanks.
Debian Lenny AMD64, Kernel 2.6.28.7 With "reboot=p" stop on "Restarting System" Without this stop on next step "Restart Machine"
Hi, Veresk thanks for the quick response. when the boot option of "reboot=p" is added, the 0xCF9 I/O port will be accessed. But it still has no effect. Now I have no idea how can we make the restart work well on this box. Maybe it is related with the BIOS/hardware issue. In comment #7 you mention : >Knoppix, ALT, Gentoo & maybe other whis kernel 2.6.16-2.6.17 - restart & halt work correctly. >Gentoo, ALT, openSuSE not work with 2.6.18-2.6.29 kernels Can you double check it? Thanks.
Debian Etch (AMD64,i386) can reboot (2.6.18 kernel) All kernels from 2.6.22 to 2.6.29-rc* can't reboot, but can halt and suspend. I don't think, then it is BIOS bug.
Hi, Veresk Can it be rebooted when using the vanilla 2.6.18 kernel from Linus? If it can't be rebooted, will you please get the difference between the Debian 2.6.18 kernel and vanilla 2.6.18 kernel? thanks.
I need in time for test it. I make 2.6.18 vanilla kernel in 12 hours.
> "reboot=p" Gentoo x86 kernel 2.6.28-3 has no effect.
2.6.18-8 vanilla kernel with Debian's Etch .config file can reboot system! I think, this says that it is kernel bug. How I can help fix this problem?
Created attachment 20602 [details] Config for 2.6.18-8 kernel With this config on 2.6.18 vanilla kernel system can reboot without problems.
Hi, Veresk Thanks for your test. From the test it seems that the box can be rebooted on the 2.6.18 vanilla kernel. But it can't be rebooted on 2.6.19 kernel. After checking the git log it seems that no commit is shipped about the file of reboot.c. Will you please use the git-bisect to identify the bad commit which causes that the box can't be rebooted. Thanks.
> > Will you please use the git-bisect to identify the bad commit which > causes > that the box can't be rebooted. Sorry, can you explain in detail (step by step instruction)? My English is very poor... I'm don't understand this phrase.
Hi, Palach According to your test the box can be rebooted on the 2.6.18 vanilla kernel. And it can't be rebooted on the 2.6.19 vanilla kernel. It seems that this is a regression. But it seems that there is no change about the file of reboot.c between 2.6.18 and 2.6.19 vanilla kernel. So the better way is to use the git-bisect to identify the bad commit which causes the regression. >git-bisect is one of the git tool set. Is the above clear? Thanks.
Since there is no response for more than two months, the bug will be rejected. If the problem still exists, please do the test as required in comment #26 and reopen it again. Thanks.
FYI: The problem still exists in kernel-2.6.30.xx (Archlinux) on an AsusF5N, _but_ cmdline parameter "reboot=p" helped here. Reboot seems to work fine, then. I'd like to bisect that problem, but that notebook isn't mine and i can only take my hands on it from time to time (twice a year :/).
Really, "reboot=p" work! (kernel >=2.6.30.xx)
Appendix: Since using parameter "reboot=p" on this laptop, _every_ 2nd(!!) reboot the synaptics touchpad doesn't work anymore. After removing the parameter everything is back to normal (well, rebooting doesn't work, but ahrrr). Does this make any sense to anyone? What is wrong with this crappy peace of hardware? "Francis: I hate Asus."
FYI: Appending "i8042.nopnp" to grub/lilo cmdline fixed that nasty touchpad-not-working-after-reboot-with-parameter-p problem. At least it works for this Asus F5N laptop.
Created attachment 67272 [details] test patch vs v3.0 to allow ACPI reset in face of BIOS tables that say it isn't supported Please try this patch, which enables ACPI reset. The patch applies to the 3.0 kernel. Depending on your kernel, you may need reboot=a to exercise this path. While the FADT says that ACPI reset is not supported: Reset Register Supported (V2) : 0 It does contain what appears to be a valid IO address: [074h 0116 12] Reset Register : <Generic Address Structure> [074h 0116 1] Space ID : 01 (SystemIO) [075h 0117 1] Bit Width : 08 [076h 0118 1] Bit Offset : 00 [077h 0119 1] Access Width : 00 [078h 0120 8] Address : 0000000000000064
does the patch work for you?
boris64 -- does this patch work for you?
boris64, please test.
I'm really sorry, but i can't test it anymore because the device is dead and gone :/
A patch referencing this bug report has been merged in Linux v3.4-rc1: commit cf450136bfde77c7f95065c91bffded4aa7fa731 Author: Len Brown <len.brown@intel.com> Date: Sun Jul 31 13:23:49 2011 -0400 ACPI: ignore FADT reset-reg-sup flag
the above patch has been reverted, and will be part of v3.4-rc4 commit 19244ad06b70ed84931df868583547ce1cd3a186 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Apr 20 11:19:35 2012 -0700 Revert "ACPI: ignore FADT reset-reg-sup flag"
Hi! :-) I'm also the owner of the Asus X50N me this bug too worried. During rebooting after term all process notebook freezes. Power off and Suspend work normal. I'm use openSUSE Tumbleweed version of kernel, at the moment, 4.7.2-default. If there are willing to understand this problem, I will be glad to help and reopen bug.