If I enable HPET in BIOS on Gigabyte GA-MA78GPM-DS2H (AMD processor, AMD 780G chipset) or Gigabyte GA-G31MF-S2 (Intel Core2 Duo processor, Intel G31 chipset) and I try to set up RTC wakeup using (as root): echo `date '+%s' -d '+ 5 minutes'` > /sys/class/rtc/rtc0/wakealarm or: rtcwake -d rtc0 -u -m no -t `date '+%s' -d '+ 5 minutes'` and then poweroff the computer, it does not wake up. Bug still present in current kernel. Not sure if any other gigabyte motherboards are affected. I tested two Gigabyte boards I own, and also an ASUS board (not affected). I ran git bisect on 3.8.11 to 3.8.13 and found the offending commit: 6d22382d7148a132fb7b4c461cb2940df4f0c77e Author: Derek Basehore <dbasehore@chromium.org> Date: Mon Apr 29 16:20:23 2013 -0700 drivers/rtc/rtc-cmos.c: don't disable hpet emulation on suspend BugLink: http://bugs.launchpad.net/bugs/1178361 <http://bugs.launchpad.net/bugs/1178361> commit e005715efaf674660ae59af83b13822567e3a758 upstream. There's a bug where rtc alarms are ignored after the rtc cmos suspends but before the system finishes suspend. Since hpet emulation is disabled and it still handles the interrupts, a wake event is never registered which is done from the rtc layer. This patch reverts commit d1b2efa83fbf ("rtc: disable hpet emulation on suspend") which disabled hpet emulation. To fix the problem mentioned in that commit, hpet_rtc_timer_init() is called directly on resume. Signed-off-by: Derek Basehore <dbasehore@chromium.org> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Steve Conklin <sconklin@canonical.com> :040000 040000 3e84b9874d08e64109a8e7155b0b0734fbf250e3 08ae4a77586575391919e292a9730d649d5251ac M drivers More details at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1197871 Please ask for any other info or tests you may need. Could this commit be reverted?
I can confirm this on a Gigabyte GA-MA770-UD3. Reverting the commit will probably not solve the real issue (as the commit itself reverts another commit). Also, the reason why AMD 700 chipsets are affected is probably due to these hardware deficiencies: https://en.wikipedia.org/wiki/AMD_700_chipset_series#Southbridge_issues_.28SB7x0.29 It could be that the check that should turn off HPET doesn't actually work as reliably as it should (it doesn't seem to turn it off in my case, I have to manually do that through hpet=disabled). So the *real* fix could in fact be to disable HPET in BIOS since it doesn't work reliably in the first case? Though not sure if the same applies to the Intel system you mentioned.
Same problem with this hardware: http://bugzillafiles.novell.org/attachment.cgi?id=582083 There is no HPET setting in the BIOS, but "hpet=disable" helps. Peter
Thanks for pointing out the buggy HPET in that chipset. With "hpet=disable" the RTC alarm now seems to wakeup my Gigabyte GA-MA78GM-S2H board reliably from ACPI S5. FYI: Kernel 4.3 introduced a new regression on my board related to RTC alarm: after poweroff the RTC alarm, even if it is not set, immediately wakes up the board again. See bug #112091
Could you try a kernel with CONFIG_HPET_EMULATE_RTC unset and leaving hpet enabled? I'm trying to understand whether this is the HPET that prevents the wakeup or if this is caused by the RTC emulation.
(In reply to Alexandre Belloni from comment #4) > Could you try a kernel with CONFIG_HPET_EMULATE_RTC unset and leaving hpet > enabled? I had to make the following change on 4.3.0 vanilla to get kernel to accept unsetting CONFIG_HPET_EMULATE_RTC. Otherwise it was always set to "yes" after running "make": --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -754,7 +754,7 @@ config HPET_TIMER Choose N to continue using the legacy 8254 timer. config HPET_EMULATE_RTC - def_bool y + def_bool n depends on HPET_TIMER && (RTC=y || RTC=m || RTC_DRV_CMOS=m || RTC_DRV_CMOS=y) config APB_TIMER -------------- After this change the system wakes up correctly from RTC alarm *with* HPET enabled: # uname -a Linux mediabox 4.3.0+ #5 SMP Thu Feb 25 20:34:45 EET 2016 i686 i686 i386 GNU/Linux # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.3.0+ root=UUID=XXX ro rd.md=0 rd.dm=0 KEYTABLE=us SYSFONT=True rd.lvm.lv=XXX rd.lvm.lv=XXX rd.luks=0 LANG=en_US.UTF-8 console=ttyS0,115200 # dmesg | fgrep -i hpet [ 0.000000] ACPI: HPET 0x000000007FDE9E40 000038 (v01 GBT GBTUACPI 42302E31 GBTU 00000098) [ 0.000000] ACPI: HPET id: 0x10b9a201 base: 0xfed00000 [ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484873504 ns [ 0.000000] hpet clockevent registered [ 0.389120] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0 [ 0.392002] hpet0: 4 comparators, 32-bit 14.318180 MHz counter [ 0.395039] clocksource: Switched to clocksource hpet [ 3.581339] misc hpet: hash matches # extract-ikconfig /lib/modules/4.3.0+/kernel/kernel/configs.ko | fgrep HPET_ CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set # CONFIG_HPET_MMAP is not set This is with the latest BIOS version F11 flashed on my Gigabyte GA-MA78GM-S2H board. Without the above change RTC alarm only works with "hpet=disable".
Sounds to me like we want to disable CONFIG_HPET_EMULATE_RTC on Gigabyte boards... pending a better fix, that is. Alexandre?
I'd say so. I will have a look at it a bit more in depth, hopefully soon. This is still on my TODO list.
Bug #15289 might be related and requires a similar fix.