Bug 924614 – >=sys-kernel/gentoo-sources-6.1.76: rtc-cmos clock issue (acpi_alarm wrongly enabled on unsupported system)

• Product: Gentoo Linux
• Status: RESOLVED CANTFIX

[Description David Duchesne 2024-02-15 02:03:47 UTC]

Hello,
Starting with 6.1.76 and this commit :
https://github.com/torvalds/linux/commit/aca1ea92f518b38d0b7651a8f4823df6774e8c70

acpi alarm is used instead of hpet
----
Adjust the quirk to apply to AMD/Hygon systems from 2021 onwards.
This matches what has been tested and is specifically to avoid potential
risk to older systems.
----

The issue is that the AMD motherboard I own use a custom bios that reports this value in DMI table :

[    0.000000] DMI: BIOS 4.18-f4c97ea131 01/04/2024

but the motherboard is old (2012), only the bios version is recent.

so (With 6.1.76) in drivers/rtc/rtc-cmos.c
----
#ifdef CONFIG_X86
static void use_acpi_alarm_quirks(void)
{
  switch (boot_cpu_data.x86_vendor) {
  case X86_VENDOR_INTEL:
    if (dmi_get_bios_year() < 2015)
      return;
    break;
  case X86_VENDOR_AMD:
  case X86_VENDOR_HYGON:
    if (dmi_get_bios_year() < 2021)
      return;
    break;
  default:
    return;
  }
  if (!is_hpet_enabled())
    return;

  use_acpi_alarm = true;
}
----

this part is ignored as expected:
----
    if (dmi_get_bios_year() < 2021)
      return;
    break;
----

and acpi_alarm is enabled but my old system doesn't support that. And it causes hwclock to stop working :

hwclock -v -r
hwclock from util-linux 2.38.1
System Time: 1707344831.153512
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1703758889 seconds after 1969
Last calibration done at 1703758889 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
...synchronization failed

If I set :
use_acpi_alarm = false (at line 839 in drivers/rtc/rtc-cmos.c)

then hwclock works fine again.

Reproducible: Always

[Comment 1 David Duchesne 2024-02-15 18:47:48 UTC]

(In reply to David Duchesne from comment #0)
> If I set :
> use_acpi_alarm = false (at line 839 in drivers/rtc/rtc-cmos.c)
> 
> then hwclock works fine again.

Also, if I change the year here :

----
    if (dmi_get_bios_year() < 2021)
      return;
    break;
----

from 2021 to 2025 for example it works fine as well. (since the year reported by my bios is 2024 so acpi_alarm is not enabled)

----

with 6.1.76 without modification :

[ 5.628018] rtc_cmos 00:01: RTC can wake from S4
[ 5.628339] rtc_cmos 00:01: registered as rtc0
[ 5.628367] rtc_cmos 00:01: setting system clock to 2024-02-14T23:35:38 UTC (1707953738)
[ 5.628411] rtc_cmos 00:01: alarms up to one day, 114 bytes nvram

with 6.1.76 with either year changed or acpi_alarm set to false :

[ 5.635879] rtc_cmos 00:01: RTC can wake from S4
[ 5.636201] rtc_cmos 00:01: registered as rtc0
[ 5.636229] rtc_cmos 00:01: setting system clock to 2024-02-15T00:11:45 UTC (1707955905)
[ 5.636271] rtc_cmos 00:01: alarms up to one day, 114 bytes nvram, hpet irqs

Notice hpet irqs is missing without modification (and hwclock error is triggred)

[Comment 2 Mike Pagano 2024-02-16 16:19:33 UTC]

So the manufacturer is reporting the incorrect date and therefore the code fails.  This feels like an upstream issue and not something we can fix.