Bug 11533

Summary: Restart not work - Notebook ASuS X50N
Product: ACPI Reporter: Palach (palachmb)
Component: Power-OffAssignee: Len Brown (lenb)
Status: CLOSED UNREPRODUCIBLE    
Severity: normal CC: acpi-bugzilla, bugzilla.kernel.org, evgeny_veresk, florian, ilya, lenb, palachmb, shawnlandden
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.25-r8 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: reboot via acpi
ACPIdump for Debian Lenny AMD64, Kernel 2.6.28
acpidump
dmidecode
Config for 2.6.18-8 kernel
test patch vs v3.0 to allow ACPI reset in face of BIOS tables that say it isn't supported

Description Palach 2008-09-10 17:32:40 UTC
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
Comment 1 Ingo Molnar 2008-09-11 00:53:22 UTC
Created attachment 17724 [details]
reboot via acpi

Could you try the attached patch please? It changes the reboot default.
Comment 2 Palach 2008-09-11 04:28:10 UTC
No, this patch is not work
Comment 3 ykzhao 2008-10-27 02:20:16 UTC
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.
Comment 4 ykzhao 2008-12-04 01:27:09 UTC
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.
Comment 5 Palach 2009-01-29 22:37:07 UTC
ACPIDUMP:

http://paste.org/5124

DMIDECODE:

http://paste.org/5125

2.6.28 ... 2.6.29_rc2-r3 - restart NOT work.
Comment 6 Veresk 2009-01-29 23:03:56 UTC
Debian Lenny - not work (with 2.6.19-2.6.29 kernels) 
Ubuntu can reboot with ALL_IDE_GENERIC option
Comment 7 Palach 2009-01-29 23:44:28 UTC
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.
Comment 8 ykzhao 2009-02-12 01:28:22 UTC
Hi, Palach
    Will you please attach the output of acpidump? Not use the link.
    
Comment 9 Veresk 2009-02-12 02:09:21 UTC
I send it to your e-mail, it's very long
Comment 10 Veresk 2009-02-12 02:11:07 UTC
Created attachment 20207 [details]
ACPIdump for Debian Lenny AMD64, Kernel 2.6.28
Comment 11 Palach 2009-02-12 04:12:09 UTC
Created attachment 20213 [details]
acpidump
Comment 12 Palach 2009-02-12 04:12:51 UTC
Created attachment 20214 [details]
dmidecode
Comment 13 ykzhao 2009-02-12 17:06:14 UTC
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.
Comment 14 Veresk 2009-02-12 23:36:46 UTC
Debian Lenny AMD64, Kernel 2.6.28

a. reboot=t
b. reboot=b

No, this magic didn't work :-(
Comment 15 ykzhao 2009-03-18 20:35:54 UTC
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.
Comment 16 Veresk 2009-03-18 22:49:44 UTC
Debian Lenny AMD64, Kernel 2.6.28.7

With  "reboot=p" stop on "Restarting System"
Without this stop on next step "Restart Machine"
Comment 17 ykzhao 2009-03-18 23:46:51 UTC
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.
Comment 18 Veresk 2009-03-19 00:04:20 UTC
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.
Comment 19 ykzhao 2009-03-19 00:50:11 UTC
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.
Comment 20 Veresk 2009-03-19 01:23:05 UTC
I need in time for test it. I make 2.6.18 vanilla kernel in 12 hours.
Comment 21 Palach 2009-03-19 06:47:46 UTC
> "reboot=p"
Gentoo x86 kernel 2.6.28-3 has no effect.
Comment 22 Veresk 2009-03-19 14:53:21 UTC
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?
Comment 23 Veresk 2009-03-19 14:58:27 UTC
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.
Comment 24 ykzhao 2009-03-19 18:01:15 UTC
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.
Comment 25 Palach 2009-03-20 01:52:55 UTC
> 
>     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.
Comment 26 ykzhao 2009-03-22 20:00:45 UTC
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.
Comment 27 ykzhao 2009-06-09 02:23:57 UTC
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.
Comment 28 boris64 2009-07-30 19:53:36 UTC
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 :/).
Comment 29 Palach 2009-08-04 05:40:20 UTC
Really, "reboot=p" work! (kernel >=2.6.30.xx)
Comment 30 boris64 2009-08-04 10:45:17 UTC
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."
Comment 31 boris64 2009-08-14 12:58:38 UTC
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.
Comment 32 Len Brown 2011-07-31 17:30:31 UTC
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
Comment 33 Len Brown 2011-08-11 19:38:31 UTC
does the patch work for you?
Comment 34 Len Brown 2011-08-30 01:19:10 UTC
boris64 -- does this patch work for you?
Comment 35 Len Brown 2012-01-17 11:18:03 UTC
boris64, please test.
Comment 36 boris64 2012-01-17 12:43:26 UTC
I'm really sorry, but i can't test it anymore 
because the device is dead and gone :/
Comment 37 Florian Mickler 2012-04-04 15:03:21 UTC
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
Comment 38 Shawn Landden 2012-04-20 21:03:54 UTC
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"
Comment 39 Илья Индиго 2016-09-09 16:16:02 UTC
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.