Bug 6655

Did this work with a previous release, or is 2.6.17-rc5 the only tested?

After STR, does a regular "init 0" work properly?

> Did this work with a previous release, or is 2.6.17-rc5 the only tested?

I do not know any kernel that works. (beginning arount 2.6.13).

> After STR, does a regular "init 0" work properly?

I will try it and let you know. (What does exactly mean 'work properly' in this
case?)

> What does exactly mean 'work properly' in this case?

In ACPI mode, "# init 0" should do a "soft power-off",
ie a graceful shutdown and poweroff.  This path shares
a bunch of code with the reboot case.

init 0 works ok. It says: Will now halt. And then it halts after STR.

init 6 says:
Will now restart
Restarting system
.

and nothing more. Looks like it hangs in BIOS (LEDs flash like booting).

Does MS windows work? If this is BIOS problem, it would affect windows too.

> Does MS windows work? If this is BIOS problem, it would affect windows too.

In Windows, it is ok.

Moreover, in Windows, Fn+sleep button wakes up from STR. In Linux, it does not
(only the power button does resume).

Please check if RESET_REG_SUP is set in FADT.
If yes, it would be worthy to test ACPI FADT reset register works or NOT.

Created attachment 8288 [details]
debug patch

Use ACPI FADT reset register.
The original patch is at
http://oss.oracle.com/projects/rhel4kernels/src/mainline/current/SOURCES/linux-2.6.9-acpi-reset-mechanism.patch

*** Bug 5396 has been marked as a duplicate of this bug. ***

*** Bug 4020 has been marked as a duplicate of this bug. ***

> Please check if RESET_REG_SUP is set in FADT.
> If yes, it would be worthy to test ACPI FADT reset register works or NOT.

How do I do this?

Pleae try the attached patch, boot kernel, 
search "machine_reset = acpi_machine_reset" in dmesg 

Patch applied:
anubis:# dmesg | grep machine_reset
anubis:#

I have ASUS A6B, that patch fixed the problem.

Re: grep "macine_reset" get nothing:
Please get full dmesg, and post it here.

Anyway, please test the patch.

--Luming

Created attachment 8292 [details]
dmesg

I've tried to reboot with the patch - no luck, still not working.

Please post acpidump output too.

Created attachment 8293 [details]
acpidump

The FADT shows NO reset register support.

Then, could you verify you are using the latest BIOS.

I'm using the latest available BIOS. And in windows, it works.

Ok, could you remove unnecessary ACPI modules, and re-test.

I left only:
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y

which is mimimum acording to menuconfig. Without ACPI STR does not work.

Created attachment 8358 [details]
disable acpi before reboot

Please try the attached patch. I tested this on my asus A6BA, it fix the
S3 reboot hang issue. I guess it should fix your problem , even if your box
don't have FADT reset register.

Looks like it's OK. At least initial sequence S3, reboot. Thanks. Will you
commint this patch into mainline?

I guess it will.
Signed-off-by: Luming Yu <luming.yu@intel.com>
fot patch at comment# 23

patch at comment#23 needs go into -mm tree for wider testing.

Works for me, i've tested the patch in comment# 23 and it fixes the reboot
problem i reported in Bug 4020.

Thanks.

I can reproduce the problem on a Lenovo 945G platform.
Luming's patch in comment#23 fix the problem.
Len, will this hit the mainline?

Hello! I have an asus M6Ne laptop and I'm affected by the exactly same bug. I
did apply the last patch (comment #23) but the problem remains. Only one thing
is better: now to switch down the machine I don't have to keep the power button
for 5 seconds, but just one hit is enough! What should I try?

I have this line about FADT in my normal ubuntu kernel

ACPI: FADT (v001 A M I  OEMFACP  0x03000528 MSFT 0x00000097) @ 0x1ff40200

I will try the first patch now

The patch caused a compile error: I'm using 2.6.20.
In fact there is no "type" caled FADT_DESCRIPTOR in that file...

drivers/acpi/bus.c: In function 

for linux-2.6.20 I needed to change the patch from

FADT_DESCRIPTOR *f = &acpi_fadt;

to

struct fadt_descriptor *f = &acpi_fadt;

The first patch did not help at all.

re: the patch in comment #8 adding acpi_machine_reset()
it is missing credit to the original author, and has removed
the x86_64 support, so it can not be applied.

re: the patch in comment #23 exiting acpi mode on reset
it is also i386 specific, will not build for CONFIG_ACPI=n
and I don't understand why it works.

I'm able to reproduce the problem on Asus L5D with 2.6.22-rc2/x86-64, 100% of 
the time (it only suspends in the init=/bin/bash "mode", but that's 
sufficient).

I have debugged it a little and found that the box hangs hard after the first 
outb(0xfe,0x64), arch/x86_64/kernel/reboot.c:129 .  It sometimes reaches the 
second read (ie. kb_wait(), arch/x86_64/kernel/reboot.c:127), but not always.

Tomorrow I'll try the patch from Comment #8.

The approach from Comment #8 is not practical, because the machine's FADT
revision is 1.  Moreover, none of the machines I have checked (some of them
pretty modern) support the Reset Register.

The hack from Comment #23 apparently doesn't work on this box.

I'm going to check if the triple fault reset works (I suspect it will).

It seems to me that on the affected machines the keyboard is handled by the
embedded controller using the "traditional" keyboard ports, so the write in
arch/x86_64/kernel/reboot.c:129 actually goes to the EC which mishandles it.

Created attachment 11638 [details]
Output of lspci -v from affected Intel-based desktop

I can reproduce this problem (100% of the time) on yet another machine, which
is a Celeron-based desktop with an Intel chipset and GeForce MX 400 (the output
of 'lspci -v' from this box is attached).

Apart from this, 's2ram --force --vbe_post --vbe_mode' works just fine on this
box  (except for a glitch cuased by ehci_hcd that makes it resume right after
the suspend, but this is a different issue).

On the machine from Comment #35, the triple-fault reset doesn't work after a
resume from RAM.

>the triple-fault reset doesn't work after a resume from RAM.

Could you post a patch? I'd like to see whether it works for M6N.

Created attachment 11640 [details]
patch to force the triple fault reset on i386

Created attachment 11642 [details]
Working patch

The attached patch, based on the patch from Comment #23, helps the machine from
Comment #35 reboot after a resume from RAM.

Of course, _why_ it works is a different issue. ;-)

To double check, I'll see if the x86_64 version will help on Asus L5D.

Patches from #38 or #39 do not change anything on m6b00n :(

As expected, the x86_64 version of the patch from Comment #39 doesn't work on
Asus L5D.

JFTR: my Toughbook CF-51, which had problems in the past rebooting after S3 
now reboots fine with 2.6.22-rc3-git2

Due to Comment #42 tried 2.6.22-rc4 on M6B00N: still does not reboot after S3 
suspend.

Same here using 2.6.21 on the box identified by:

    sys_vendor   = "MSI."
    sys_product  = "MS-7207PV"
    sys_version  = "100"
    bios_version = "080012 "

however acpi off only stops working after suspend if I use vga=792 or other. If I use vga=normal on the kernel cmdline, it works!

I guess you mean restart?  ACPI off works on all of my test boxes after the resume, but the restart doesn't work on some of them (booting with vga=normal doesn't change anything).

*** Bug 8951 has been marked as a duplicate of this bug. ***

The "disable acpi before reboot" patch (#23 From Luming Yu) works on an ASUS Z91E notebook (also called the A3E) with BIOS version 204. The system restarts as expected after a suspend/resume.

The patch was applied to a custom configuration built from Fedora 8 
kernel-2.6.23.15-137.fc8.src.rpm.

The system does not restart when using these stock Fedora kernels:
kernel-2.6.24.3-12.fc8
kernel-2.6.23.15-137.fc8

    From the acpidump it seems that there exists the definition of RESET_REG although the RESET_REG is not supported.(The RESET_REG bit of FADT is zero).
    > RESET_REG 0xCF9
    > RESET_VALUE : 0x06
     
    Will you please attach the output of dmidecode?

Hi, Steve
    Will you please try the latest kernel and see whether the problem still exists?
    Thanks.

(In reply to comment #49)
> Hi, Steve
>     Will you please try the latest kernel and see whether the problem still
> exists?
>     Thanks.

Suspending, resuming, and restarting on my ASUS Z91E works with
Fedora 9 kernel 2.6.27.5-41.fc9.i686 dated Thu Nov 13 20:52:14 EST 2008.
Thanks!