Most recent kernel where this bug did not occur: n/a Distribution: Debian/sid Hardware Environment: Asus M6A notebook Software Environment: Problem Description: After S3 STR reboot does not work, I've tried reboot=w,h and reboot=c,b, no luck. System shows message about restarting system. Caps lock and num lock LEDs flash, but it does not reboot. Steps to reproduce: Do S3 susped, try to reboot.
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!