Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] hwclock wait for clock tick timed out (kernel 6.*)
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
sdauth
Guru
Guru


Joined: 19 Sep 2018
Posts: 569
Location: Ásgarðr

PostPosted: Wed Feb 07, 2024 10:19 pm    Post subject: [SOLVED] hwclock wait for clock tick timed out (kernel 6.*) Reply with quote

Hello,
I have upgraded my kernel from 6.1.74 to 6.6.13, all is good except I have this when system is booting (openrc)

Code:
* Setting system clock using the hardware clock [UTC] ...
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
 * Failed to set the system clock
 [ !! ]


hwclock service is set to boot runlevel as usual, no change.
The clock is correctly set nonetheless but I don't have this message with 6.1.74, any idea ?


Last edited by sdauth on Mon Feb 19, 2024 10:07 pm; edited 3 times in total
Back to top
View user's profile Send private message
sdauth
Guru
Guru


Joined: 19 Sep 2018
Posts: 569
Location: Ásgarðr

PostPosted: Wed Feb 07, 2024 10:28 pm    Post subject: Reply with quote

sudo hwclock -v

Code:
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


EDIT: For now, I'm masking 6.6 since it looks like a bug. 6.1.* series doesn't have this issue and hwclock works fine with it.
Back to top
View user's profile Send private message
sdauth
Guru
Guru


Joined: 19 Sep 2018
Posts: 569
Location: Ásgarðr

PostPosted: Wed Feb 14, 2024 7:57 pm    Post subject: Reply with quote

I just compiled 6.1.77 (keyword) and the same issue happens.
Current stable (6.1.74) is not affected.
Same config... So I don't know what is happening.
I'm using sys-devel/gcc-12.3.1_p20240112.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21635

PostPosted: Wed Feb 14, 2024 8:10 pm    Post subject: Reply with quote

Can you determine which commit in the range v6.1.74..v6.1.77 introduced this problem? If so, you could report it as a regression.
Back to top
View user's profile Send private message
sdauth
Guru
Guru


Joined: 19 Sep 2018
Posts: 569
Location: Ásgarðr

PostPosted: Wed Feb 14, 2024 8:20 pm    Post subject: Reply with quote

@Hu:
I don't know what to look for. I'm not a developer. :oops:
I noticed it only happens on two system. (They use the same motherboard & cpu (amd bdver2) )
My laptop (old core2duo) is not affected with 6.1.77 or 6.6.16. hwclock works fine with it.

edit : maybe this : https://github.com/torvalds/linux/commit/aca1ea92f518b38d0b7651a8f4823df6774e8c70 added in 6.1.76
It says :
Adjust the quirk to apply to AMD/Hygon systems from 2021 onwards.

dmi_get_bios_year() is used to query the value but my amd motherboard is 10 years old but with a very recent bios (coreboot) from this year.
I have no idea if that commit is the issue here but this is what I found related to rtc / cmos.
Any help welcome.
Meanwhile I'll try to compile 6.1.75 first then 6.1.76. I'll update this thread later.
Back to top
View user's profile Send private message
sublogic
Apprentice
Apprentice


Joined: 21 Mar 2022
Posts: 222
Location: Pennsylvania, USA

PostPosted: Wed Feb 14, 2024 11:58 pm    Post subject: Reply with quote

Hu wrote:
Can you determine which commit in the range v6.1.74..v6.1.77 introduced this problem? If so, you could report it as a regression.

sdauth wrote:
@Hu:
I don't know what to look for. I'm not a developer. :oops:

@sdauth: start here: https://wiki.gentoo.org/wiki/Kernel_git-bisect .
Be advised: it's a process. No, it's a learning experience. No, it's an adventure.

If you succeed with the bisection we can go on to reporting it upstream.
Back to top
View user's profile Send private message
sdauth
Guru
Guru


Joined: 19 Sep 2018
Posts: 569
Location: Ásgarðr

PostPosted: Thu Feb 15, 2024 12:24 am    Post subject: Reply with quote

Results with my amd system :
6.1.75 : no issue
6.1.76 : hwclock issue

with 6.1.75 :

[ 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, hpet irqs

with 6.1.76 :

[ 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

Notice hpet irqs is missing with 6.1.76, so I assume it uses (or try to) use acpi_alarm but it doesn't work on my system and so hwclock no longer works :

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

I will recompile 6.1.76 with :

use_acpi_alarm = false (at line 839 in drivers/rtc/rtc-cmos.c)
Back to top
View user's profile Send private message
sdauth
Guru
Guru


Joined: 19 Sep 2018
Posts: 569
Location: Ásgarðr

PostPosted: Thu Feb 15, 2024 1:18 am    Post subject: Reply with quote

With use_acpi_alarm = false (at line 839 in drivers/rtc/rtc-cmos.c), hwclock now works fine again. And hpet irqs shows up again.

[ 5.591615] rtc_cmos 00:01: RTC can wake from S4
[ 5.591881] rtc_cmos 00:01: registered as rtc0
[ 5.591907] rtc_cmos 00:01: setting system clock to 2024-02-15T01:04:07 UTC (1707959047)
[ 5.591949] rtc_cmos 00:01: alarms up to one day, 114 bytes nvram, hpet irqs

I have not tried with 6.6.x yet but I assume it should work too.
Anyway,
In : drivers/rtc/rtc-cmos.c
Code:
#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;
}


Because my bios year is recent :
Code:
[    0.000000] DMI: BIOS 4.18-f4c97ea131 01/04/2024


this part is ignored :

Code:
    if (dmi_get_bios_year() < 2021)
      return;
    break;


and acpi_alarm is enabled.
But only the bios is recent, as I said earlier, the system is quite old. (2012 motherboard)

edit:

I just noticed there is a parameter to enable/disable acpi_alarm with rtc_cmos, so maybe I could use that to disable it. (rtc_cmos.use_acpi_alarm=0 to cmdline) (edit : it doesn't work)
Code:
name:           rtc_cmos
filename:       (builtin)
license:        GPL
file:           drivers/rtc/rtc-cmos
description:    Driver for PC-style 'CMOS' RTCs
author:         David Brownell
alias:          platform:rtc_cmos
parm:           use_acpi_alarm:bool


Since this issue seems specific to my system, I'm not sure if this should be considered a kernel bug. I still opened a bug on gentoo nonetheless.
Back to top
View user's profile Send private message
sdauth
Guru
Guru


Joined: 19 Sep 2018
Posts: 569
Location: Ásgarðr

PostPosted: Mon Feb 19, 2024 10:07 pm    Post subject: Reply with quote

So to solve the issue with the dmi year I made this patch to prevent acpi_alarm activation :

Code:
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index e0a798923ce0..55798744bd0d 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -827,7 +827,7 @@ static void use_acpi_alarm_quirks(void)
       break;
    case X86_VENDOR_AMD:
    case X86_VENDOR_HYGON:
-      if (dmi_get_bios_year() < 2021)
+      if (dmi_get_bios_year() < 2041)
          return;
       break;
    default:


It worked but it sucked a little bit because I also use regular kernel with debian or whatever and don't want to patch each kernel.
So instead of that, I hardcoded a different year in my coreboot bios. (in coreboot src, it is in util/genbuild_h/genbuild_h.sh) and rebuild a new rom.

Now, my DMI reads :
Code:
[    0.000000] DMI: BIOS 4.18-f4c97ea131 12/31/2020


And hwclock works perfectly again! Tested with latest 6.1.78 & 6.6.17.

hwclock -v
Code:
hwclock from util-linux 2.38.1
System Time: 1708380159.776565
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2024/02/19 22:02:40
Hw clock time : 2024/02/19 22:02:40 = 1708380160 seconds since 1969
Time since last adjustment is 1708380160 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2024-02-19 23:02:39.686662+01:00


Code:
[    0.629620] rtc_cmos 00:01: RTC can wake from S4
[    0.629839] rtc_cmos 00:01: registered as rtc0
[    0.629897] rtc_cmos 00:01: setting system clock to 2024-02-19T21:51:07 UTC (1708379467)
[    0.629970] rtc_cmos 00:01: alarms up to one day, 114 bytes nvram, hpet irqs
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum