|Summary:||S3 resume breaks reboot - Asus M6A notebook|
|Product:||Power Management||Reporter:||Lukas Hejtmanek (xhejtman)|
|Component:||Hibernation/Suspend||Assignee:||Rafael J. Wysocki (rjwysocki)|
|Severity:||normal||CC:||acpi-bugzilla, akpm, dottedmag, jan, opensource, pedro, rjwysocki, stefan.seyfried, stephent98|
|Bug Depends on:|
disable acpi before reboot
Output of lspci -v from affected Intel-based desktop
patch to force the triple fault reset on i386
Description Lukas Hejtmanek 2006-06-06 02:10:59 UTC
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.
Comment 1 Len Brown 2006-06-06 14:59:35 UTC
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?
Comment 2 Lukas Hejtmanek 2006-06-06 15:05:44 UTC
> 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?)
Comment 3 Len Brown 2006-06-06 15:36:58 UTC
> 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.
Comment 4 Lukas Hejtmanek 2006-06-07 02:16:32 UTC
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).
Comment 5 Luming Yu 2006-06-07 07:29:50 UTC
Does MS windows work? If this is BIOS problem, it would affect windows too.
Comment 6 Lukas Hejtmanek 2006-06-07 12:38:12 UTC
> 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).
Comment 7 Luming Yu 2006-06-11 21:40:06 UTC
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.
Comment 8 Luming Yu 2006-06-12 00:01:00 UTC
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
Comment 9 Luming Yu 2006-06-12 00:04:17 UTC
*** Bug 5396 has been marked as a duplicate of this bug. ***
Comment 10 Luming Yu 2006-06-12 00:10:35 UTC
*** Bug 4020 has been marked as a duplicate of this bug. ***
Comment 11 Lukas Hejtmanek 2006-06-12 05:01:20 UTC
> 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?
Comment 12 Luming Yu 2006-06-12 05:53:02 UTC
Pleae try the attached patch, boot kernel, search "machine_reset = acpi_machine_reset" in dmesg
Comment 13 Lukas Hejtmanek 2006-06-12 08:55:00 UTC
Patch applied: anubis:# dmesg | grep machine_reset anubis:#
Comment 14 Luming Yu 2006-06-12 18:01:48 UTC
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
Comment 16 Lukas Hejtmanek 2006-06-13 00:31:49 UTC
I've tried to reboot with the patch - no luck, still not working.
Comment 17 Luming Yu 2006-06-13 00:39:33 UTC
Please post acpidump output too.
Comment 19 Luming Yu 2006-06-13 01:23:28 UTC
The FADT shows NO reset register support. Then, could you verify you are using the latest BIOS.
Comment 20 Lukas Hejtmanek 2006-06-13 01:44:44 UTC
I'm using the latest available BIOS. And in windows, it works.
Comment 21 Luming Yu 2006-06-13 02:15:27 UTC
Ok, could you remove unnecessary ACPI modules, and re-test.
Comment 22 Lukas Hejtmanek 2006-06-13 02:37:44 UTC
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.
Comment 23 Luming Yu 2006-06-20 23:07:06 UTC
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.
Comment 24 Lukas Hejtmanek 2006-06-21 11:22:28 UTC
Looks like it's OK. At least initial sequence S3, reboot. Thanks. Will you commint this patch into mainline?
Comment 25 Luming Yu 2006-06-22 09:24:41 UTC
I guess it will. Signed-off-by: Luming Yu <firstname.lastname@example.org> fot patch at comment# 23 patch at comment#23 needs go into -mm tree for wider testing.
Comment 26 Andrea Vettorello 2006-07-15 04:22:28 UTC
Works for me, i've tested the patch in comment# 23 and it fixes the reboot problem i reported in Bug 4020. Thanks.
Comment 27 Zhang Rui 2007-01-17 23:40:33 UTC
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?
Comment 28 Nicolo' Chieffo 2007-01-19 07:00:38 UTC
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
Comment 29 Nicolo' Chieffo 2007-01-19 07:13:13 UTC
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
Comment 30 Nicolo' Chieffo 2007-01-19 14:18:42 UTC
for linux-2.6.20 I needed to change the patch from FADT_DESCRIPTOR *f = &acpi_fadt; to struct fadt_descriptor *f = &acpi_fadt;
Comment 31 Nicolo' Chieffo 2007-01-19 15:39:29 UTC
The first patch did not help at all.
Comment 32 Len Brown 2007-03-08 23:15:12 UTC
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.
Comment 33 Rafael J. Wysocki 2007-05-20 15:15:49 UTC
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.
Comment 34 Rafael J. Wysocki 2007-05-31 10:04:09 UTC
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.
Comment 35 Rafael J. Wysocki 2007-06-01 10:38:48 UTC
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).
Comment 36 Rafael J. Wysocki 2007-06-02 05:45:54 UTC
On the machine from Comment #35, the triple-fault reset doesn't work after a resume from RAM.
Comment 37 Mikhail Gusarov 2007-06-02 06:03:06 UTC
>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.
Comment 38 Rafael J. Wysocki 2007-06-02 07:45:12 UTC
Created attachment 11640 [details] patch to force the triple fault reset on i386
Comment 39 Rafael J. Wysocki 2007-06-02 09:08:48 UTC
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.
Comment 40 Mikhail Gusarov 2007-06-02 11:05:42 UTC
Patches from #38 or #39 do not change anything on m6b00n :(
Comment 41 Rafael J. Wysocki 2007-06-02 16:04:00 UTC
As expected, the x86_64 version of the patch from Comment #39 doesn't work on Asus L5D.
Comment 42 Stefan Seyfried 2007-06-05 10:16:10 UTC
JFTR: my Toughbook CF-51, which had problems in the past rebooting after S3 now reboots fine with 2.6.22-rc3-git2
Comment 43 Mikhail Gusarov 2007-06-05 20:21:17 UTC
Due to Comment #42 tried 2.6.22-rc4 on M6B00N: still does not reboot after S3 suspend.
Comment 44 Fabien Wernli 2007-06-17 05:35:04 UTC
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!
Comment 45 Rafael J. Wysocki 2007-06-17 14:15:31 UTC
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).
Comment 46 Rafael J. Wysocki 2007-10-02 04:38:57 UTC
*** Bug 8951 has been marked as a duplicate of this bug. ***
Comment 47 Steve Tyler 2008-03-09 14:07:14 UTC
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-126.96.36.199-137.fc8.src.rpm. The system does not restart when using these stock Fedora kernels: kernel-188.8.131.52-12.fc8 kernel-184.108.40.206-137.fc8
Comment 48 ykzhao 2008-09-23 01:55:13 UTC
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?
Comment 49 ykzhao 2008-11-16 22:58:17 UTC
Hi, Steve Will you please try the latest kernel and see whether the problem still exists? Thanks.
Comment 50 Steve Tyler 2008-12-03 14:50:57 UTC
(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 220.127.116.11-41.fc9.i686 dated Thu Nov 13 20:52:14 EST 2008. Thanks!