Bug 68331

Summary:	[Regression] [bisected] RTC wakeup not working when HPET enabled in BIOS on Gigabyte motherboard
Product:	Timers	Reporter:	Diego Rodriguez (gran.diego)
Component:	Realtime Clock	Assignee:	timers_realtime-clock
Status:	NEEDINFO ---
Severity:	normal	CC:	alexandre.belloni, bp, chemobejk, gran.diego, pastas4, pmlists
Priority:	P1
Hardware:	x86-64
OS:	Linux
Kernel Version:	>= 3.8.13	Subsystem:
Regression:	Yes	Bisected commit-id:

Description Diego Rodriguez 2014-01-09 11:18:06 UTC

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?

Comment 1 Dainius Masiliūnas 2014-04-06 07:17:11 UTC

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.

Comment 2 Peter 2014-07-03 08:46:02 UTC

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

Comment 3 Stefan Becker 2016-02-07 10:27:58 UTC

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

Comment 4 Alexandre Belloni 2016-02-17 12:48:36 UTC

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.

Comment 5 Stefan Becker 2016-02-25 19:26:01 UTC

(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".

Comment 6 Borislav Petkov 2016-04-24 16:24:28 UTC

Sounds to me like we want to disable CONFIG_HPET_EMULATE_RTC on Gigabyte boards... pending a better fix, that is. Alexandre?

Comment 7 Alexandre Belloni 2016-05-03 07:35:15 UTC

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.

Comment 8 Dainius Masiliūnas 2016-08-07 23:07:03 UTC

Bug #15289 might be related and requires a similar fix.