| View previous topic :: View next topic |
| Author |
Message |
sdauth
l33t
Joined: 19 Sep 2018
Posts: 644
Location: Ásgarðr
|
 Posted: Wed Feb 07, 2024 10:19 pm Post subject: [SOLVED] hwclock wait for clock tick timed out (kernel 6.*) |
 |
|
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 |
|
 |
sdauth
l33t
Joined: 19 Sep 2018
Posts: 644
Location: Ásgarðr
|
| Posted: Wed Feb 07, 2024 10:28 pm Post subject: |
|
|
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 |
|
|
sdauth
l33t
Joined: 19 Sep 2018
Posts: 644
Location: Ásgarðr
|
| Posted: Wed Feb 14, 2024 7:57 pm Post subject: |
|
|
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 |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22612
|
| Posted: Wed Feb 14, 2024 8:10 pm Post subject: |
|
|
| 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 |
|
|
sdauth
l33t
Joined: 19 Sep 2018
Posts: 644
Location: Ásgarðr
|
| Posted: Wed Feb 14, 2024 8:20 pm Post subject: |
|
|
@Hu:
I don't know what to look for. I'm not a developer. 
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 |
|
|
sublogic
Apprentice
Joined: 21 Mar 2022
Posts: 269
Location: Pennsylvania, USA
|
| Posted: Wed Feb 14, 2024 11:58 pm Post subject: |
|
|
| 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. |
@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 |
|
|
sdauth
l33t
Joined: 19 Sep 2018
Posts: 644
Location: Ásgarðr
|
| Posted: Thu Feb 15, 2024 12:24 am Post subject: |
|
|
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 |
|
|
sdauth
l33t
Joined: 19 Sep 2018
Posts: 644
Location: Ásgarðr
|
| Posted: Thu Feb 15, 2024 1:18 am Post subject: |
|
|
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 |
|
|
sdauth
l33t
Joined: 19 Sep 2018
Posts: 644
Location: Ásgarðr
|
| Posted: Mon Feb 19, 2024 10:07 pm Post subject: |
|
|
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 |
|
|
figofuture
n00b
Joined: 10 Apr 2011
Posts: 4
Location: china
|
| Posted: Mon Aug 26, 2024 7:59 am Post subject: |
|
|
there is another way can avoid/resolve this problem,
pls edit file /etc/conf.d/hwclock add --directisa to clock_args
| Code: |
#vi /etc/conf.d/hwclock
|
| Code: |
# Set CLOCK to "UTC" if your Hardware Clock is set to UTC (also known as
# Greenwich Mean Time). If that clock is set to the local time, then
# set CLOCK to "local". Note that if you dual boot with Windows, then
# you should set it to "local".
clock="UTC"
# If you want the hwclock script to set the system time (software clock)
# to match the current hardware clock during bootup, leave this
# commented out.
# However, you can set this to "NO" if you are running a modern kernel
# and using NTP to synchronize your system clock.
#clock_hctosys="YES"
# If you do not want to set the hardware clock to the current system
# time (software clock) during shutdown, set this to no.
#clock_systohc="YES"
# If you wish to pass any other arguments to hwclock during bootup,
# you may do so here. Alpha users may wish to use --arc or --srm here.
clock_args="--directisa"
|
_________________
When in doubt, use brute force! |
|
| Back to top |
|
|
|
Kernel & Hardware
