crazy clock skew after suspend

gcb · 2023-02-17 19:49:41

today i let my computer unplugged and it went into suspend mode. Suspend on this hardware (hp elitebook g9) have always been hit or miss. Either I let it overnight suspended and lose something like 2% of my battery, or it fully drains the battery. This time, I lost 2% but the clock went crazy.

I simply woke the computer up and all SSL certification validations were failing. I saw the clock a few hours off. So i just assume a bad ntp request and forced a reset from RTC... it fixed things, but i was not a few hours off, but a month!

Apr 05 00:56:31 elite doas[27958]: gcb ran command hwclock -us as root from /home/gcb
Apr 05 00:56:31 elite kernel: audit: type=1101 audit(3353298991.123:298): pid=27956 uid=1000 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acc>
Apr 05 00:56:31 elite kernel: audit: type=1110 audit(3353298991.123:299): pid=27956 uid=1000 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_fprintd acct="root" exe="/usr/b>
Apr 05 00:56:31 elite kernel: audit: type=1105 audit(3353298991.123:300): pid=27956 uid=1000 auid=1000 ses=2 msg='op=PAM:session_open grantors=pam_systemd_home,pam_limits,pa>
Feb 17 09:40:49 elite doas[27956]: pam_unix(doas:session): session closed for user root

for some reason computer was on Apr5... off to the logs to see when that happened.

Feb 16 18:00:15 elite systemd[1]: Starting System Suspend...
Feb 16 18:00:15 elite systemd-sleep[27189]: Entering sleep state 'suspend'...
Feb 16 18:00:15 elite kernel: PM: suspend entry (s2idle)
Feb 16 18:00:15 elite kernel: Filesystems sync: 0.017 seconds
Feb 16 18:00:15 elite wpa_supplicant[829]: wlp1s0: CTRL-EVENT-DSCP-POLICY clear_all
Feb 16 18:00:15 elite wpa_supplicant[829]: nl80211: deinit ifname=wlp1s0 disabled_11b_rates=0
Apr 05 00:10:55 elite kernel: Freezing user space processes ... (elapsed 0.001 seconds) done.
Apr 05 00:10:55 elite kernel: OOM killer disabled.
Apr 05 00:10:55 elite kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Apr 05 00:10:55 elite kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Apr 05 00:10:55 elite kernel: ACPI: EC: interrupt blocked
Apr 05 00:10:55 elite kernel: Unable to read current time from RTC
Apr 05 00:10:55 elite kernel: Unable to read current time from RTC
Apr 05 00:10:55 elite kernel: Unable to read current time from RTC
Apr 05 00:10:55 elite kernel: Unable to read current time from RTC
Apr 05 00:10:55 elite kernel: ACPI: EC: interrupt unblocked
Apr 05 00:10:55 elite kernel: [drm] PCIE GART of 1024M enabled (table at 0x000000F41FC00000).
Apr 05 00:10:55 elite kernel: amdgpu 0000:63:00.0: amdgpu: SMU is resuming...
Apr 05 00:10:55 elite kernel: nvme nvme0: Shutdown timeout set to 10 seconds
Apr 05 00:10:55 elite kernel: amdgpu 0000:63:00.0: amdgpu: SMU is resumed successfully!
Apr 05 00:10:55 elite kernel: [drm] Watermarks table not configured properly by SMU
Apr 05 00:10:55 elite kernel: nvme nvme0: 16/0/0 default/read/poll queues
Apr 05 00:10:55 elite kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: Firmware version: 3

So it went to suspend on Feb16, fine, but woke up on Apr05! and it was NOT a bad hardware glitch as it failed to read from RTC (no idea why that happened tho... and the date skew happen even before it tried and failed to read from hardware clock... so maybe not relevant here? I also did "fix" the issue by reading from hardware clock.)

anyone have any idea why that happened? what caused it?

seth · 2023-02-17 20:47:03

Feb 16 18:00:15 elite wpa_supplicant[829]: nl80211: deinit ifname=wlp1s0 disabled_11b_rates=0
Apr 05 00:10:55 elite kernel: Freezing user space processes ... (elapsed 0.001 seconds) done.

Even from the excerpt the skew seems to happen before the S3, but directly after the wifi signs out.
Can you trigger this by disconnecting the wifi of rfkill'ing it?

Sidebar:

overnight suspended and lose something like 2% of my battery, or it fully drains the battery … clock went crazy

How many parallel windows installations do you have?

TheMinefighter · 2023-11-17 09:59:58

I have the exact same problem, clock being skewed by multiple decades with the same log. Running a R7 7840HS (Lenovo 83AM0007GE). I haven't found a fix yet

seth · 2023-11-17 13:59:06

For the OP it wasn't "multiple decades".
Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

and comment on the questions in #2
"#metoo" won't help you here.

milouse · 2023-12-05 20:05:59

Hi,

I have the same problem here: very big time skew after suspend (not necessarily a night long, 10 minutes was sufficient). It is not the first time it occurs, but never found the solution. As it happen again today, I did some research again, but without more success

Here are my own logs:

déc. 05 17:32:55 computer systemd-logind[738]: The system will suspend now!
déc. 05 17:32:55 computer NetworkManager[740]: <info>  [1701793975.8694] manager: sleep: sleep requested (sleeping: no  enabled: yes)
déc. 05 17:32:55 computer NetworkManager[740]: <info>  [1701793975.8695] manager: NetworkManager state is now ASLEEP
déc. 05 17:32:55 computer NetworkManager[740]: <info>  [1701793975.8696] device ([…]): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed')
déc. 05 17:32:55 computer NetworkManager[740]: <info>  [1701793975.8703] device (wlo1): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed')
déc. 05 17:32:55 computer dbus-daemon[737]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by>
déc. 05 17:32:55 computer systemd[1]: Starting Network Manager Script Dispatcher Service...
déc. 05 17:32:55 computer systemd[1]: Started Network Manager Script Dispatcher Service.
déc. 05 17:32:55 computer dbus-daemon[737]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
déc. 05 17:32:55 computer NetworkManager[740]: <info>  [1701793975.9347] device ([…]): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'manag>
déc. 05 17:32:55 computer NetworkManager[740]: <info>  [1701793975.9358] dhcp4 ([…]): canceled DHCP transaction
déc. 05 17:32:55 computer NetworkManager[740]: <info>  [1701793975.9358] dhcp4 ([…]): activation: beginning transaction (timeout in 45 seconds)
déc. 05 17:32:55 computer NetworkManager[740]: <info>  [1701793975.9358] dhcp4 ([…]): state changed no lease
déc. 05 17:32:55 computer NetworkManager[740]: <info>  [1701793975.9359] dhcp6 ([…]): canceled DHCP transaction
déc. 05 17:32:55 computer NetworkManager[740]: <info>  [1701793975.9359] dhcp6 ([…]): activation: beginning transaction (timeout in 45 seconds)
déc. 05 17:32:55 computer NetworkManager[740]: <info>  [1701793975.9359] dhcp6 ([…]): state changed no lease
déc. 05 17:32:55 computer kernel: wlo1: deauthenticating from […] by local choice (Reason: 3=DEAUTH_LEAVING)
déc. 05 17:32:55 computer NetworkManager[740]: <info>  [1701793975.9918] device ([…]): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
déc. 05 17:32:56 computer wpa_supplicant[781]: wlo1: CTRL-EVENT-DISCONNECTED bssid=[…] reason=3 locally_generated=1
déc. 05 17:32:56 computer wpa_supplicant[781]: wlo1: CTRL-EVENT-DSCP-POLICY clear_all
déc. 05 17:32:56 computer wpa_supplicant[781]: wlo1: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
déc. 05 17:32:56 computer NetworkManager[740]: <info>  [1701793976.0547] device (wlo1): supplicant interface state: completed -> disconnected
déc. 05 17:32:56 computer NetworkManager[740]: <info>  [1701793976.0548] device (wlo1): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'managed')
déc. 05 17:32:56 computer NetworkManager[740]: <info>  [1701793976.0557] dhcp4 (wlo1): canceled DHCP transaction
déc. 05 17:32:56 computer NetworkManager[740]: <info>  [1701793976.0557] dhcp4 (wlo1): activation: beginning transaction (timeout in 45 seconds)
déc. 05 17:32:56 computer NetworkManager[740]: <info>  [1701793976.0557] dhcp4 (wlo1): state changed no lease
déc. 05 17:32:56 computer NetworkManager[740]: <info>  [1701793976.0558] dhcp6 (wlo1): canceled DHCP transaction
déc. 05 17:32:56 computer NetworkManager[740]: <info>  [1701793976.0558] dhcp6 (wlo1): activation: beginning transaction (timeout in 45 seconds)
déc. 05 17:32:56 computer NetworkManager[740]: <info>  [1701793976.0558] dhcp6 (wlo1): state changed no lease
déc. 05 17:32:56 computer NetworkManager[740]: <info>  [1701793976.0713] device (wlo1): set-hw-addr: set MAC address to […] (scanning)
déc. 05 17:32:56 computer NetworkManager[740]: <info>  [1701793976.6078] device (wlo1): supplicant interface state: disconnected -> interface_disabled
déc. 05 17:32:56 computer NetworkManager[740]: <info>  [1701793976.6079] device (wlo1): supplicant interface state: interface_disabled -> disconnected
déc. 05 17:32:56 computer NetworkManager[740]: <info>  [1701793976.6082] device (wlo1): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
déc. 05 17:32:57 computer NetworkManager[740]: <info>  [1701793977.1248] device (wlo1): set-hw-addr: reset MAC address to […] (unmanage)
déc. 05 17:32:57 computer systemd[1]: Reached target Sleep.
déc. 05 17:32:57 computer systemd[1]: Starting System Suspend...
déc. 05 17:32:57 computer wpa_supplicant[781]: wlo1: CTRL-EVENT-DSCP-POLICY clear_all
déc. 05 17:32:57 computer systemd-sleep[94424]: Entering sleep state 'suspend'...
déc. 05 17:32:57 computer kernel: PM: suspend entry (s2idle)
déc. 05 17:32:57 computer kernel: Filesystems sync: 0.006 seconds
déc. 05 17:32:57 computer wpa_supplicant[781]: wlo1: CTRL-EVENT-DSCP-POLICY clear_all
déc. 05 17:32:57 computer wpa_supplicant[781]: nl80211: deinit ifname=wlo1 disabled_11b_rates=0
nov. 08 10:38:44 computer kernel: Freezing user space processes
nov. 08 10:38:44 computer kernel: Freezing user space processes completed (elapsed 0.002 seconds)
nov. 08 10:38:44 computer kernel: OOM killer disabled.
nov. 08 10:38:44 computer kernel: Freezing remaining freezable tasks
nov. 08 10:38:44 computer kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
nov. 08 10:38:44 computer kernel: printk: Suspending console(s) (use no_console_suspend to debug)
nov. 08 10:38:44 computer kernel: ACPI: EC: interrupt blocked
nov. 08 10:38:44 computer kernel: Unable to read current time from RTC
nov. 08 10:38:44 computer kernel: Unable to read current time from RTC
nov. 08 10:38:44 computer kernel: Unable to read current time from RTC
nov. 08 10:38:44 computer kernel: Unable to read current time from RTC
nov. 08 10:38:44 computer kernel: Unable to read current time from RTC
nov. 08 10:38:44 computer kernel: Unable to read current time from RTC
nov. 08 10:38:44 computer kernel: Unable to read current time from RTC
nov. 08 10:38:44 computer kernel: Unable to read current time from RTC
nov. 08 10:38:44 computer kernel: ACPI: EC: interrupt unblocked
nov. 08 10:38:44 computer kernel: pci 0000:00:00.2: can't derive routing for PCI INT A
nov. 08 10:38:44 computer kernel: pci 0000:00:00.2: PCI INT A: no GSI
nov. 08 10:38:44 computer kernel: [drm] PCIE GART of 1024M enabled.
nov. 08 10:38:44 computer kernel: [drm] PTB located at 0x000000F41FC00000
nov. 08 10:38:44 computer kernel: amdgpu 0000:03:00.0: amdgpu: SMU is resuming...
nov. 08 10:38:44 computer kernel: amdgpu 0000:03:00.0: amdgpu: dpm has been disabled
nov. 08 10:38:44 computer kernel: amdgpu 0000:03:00.0: amdgpu: SMU is resumed successfully!
nov. 08 10:38:44 computer kernel: nvme nvme0: 16/0/0 default/read/poll queues
nov. 08 10:38:44 computer kernel: usb 1-4: reset full-speed USB device number 4 using xhci_hcd
nov. 08 10:38:44 computer kernel: [drm] VCN decode and encode initialized successfully(under DPG Mode).
nov. 08 10:38:44 computer kernel: [drm] JPEG decode initialized successfully.
nov. 08 10:38:44 computer kernel: amdgpu 0000:03:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0
nov. 08 10:38:44 computer kernel: amdgpu 0000:03:00.0: amdgpu: ring gfx_low uses VM inv eng 1 on hub 0
nov. 08 10:38:44 computer kernel: amdgpu 0000:03:00.0: amdgpu: ring gfx_high uses VM inv eng 4 on hub 0
nov. 08 10:38:44 computer kernel: OOM killer enabled.
nov. 08 10:38:44 computer kernel: Restarting tasks ... done.
nov. 08 10:38:44 computer kernel: random: crng reseeded on system resumption
nov. 08 10:38:44 computer kernel: Bluetooth: hci0: RTL: examining hci_ver=08 hci_rev=000c lmp_ver=08 lmp_subver=8821
nov. 08 10:38:44 computer kernel: Bluetooth: hci0: RTL: rom_version status=0 version=1
nov. 08 10:38:44 computer kernel: Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_fw.bin
nov. 08 10:38:44 computer kernel: Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_config.bin
nov. 08 10:38:44 computer kernel: Bluetooth: hci0: RTL: cfg_sz 10, total sz 34926
nov. 08 10:38:44 computer kernel: PM: suspend exit
[…] bluetooth related stuff, no errors
[…] pipewire related stuff, no errors
nov. 08 10:38:44 computer systemd[1]: systemd-suspend.service: Deactivated successfully.
nov. 08 10:38:44 computer systemd[1]: Finished System Suspend.
nov. 08 10:38:44 computer systemd[1]: Stopped target Sleep.
nov. 08 10:38:44 computer systemd[1]: Reached target Suspend.
nov. 08 10:38:44 computer systemd[1]: Stopped target Suspend.
nov. 08 10:38:44 computer systemd-logind[738]: Operation 'sleep' finished.

After forcing the timesync, timedatectl still show the problem:

$ timedatectl status
               Local time: mar. 2023-12-05 21:03:19 CET
           Universal time: mar. 2023-12-05 20:03:19 UTC
                 RTC time: lun. 2077-11-08 12:43:14
                Time zone: Europe/Paris (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

From my research, I felt on those topics:

- https://bbs.archlinux.org/viewtopic.php?id=173487
- https://www.reddit.com/r/debian/comment … endresume/
- https://unix.stackexchange.com/question … op-suspend
- https://unix.stackexchange.com/question … from-sleep
- https://discussion.fedoraproject.org/t/ … g/81056/10

So we are clearly not alone… but does not look like a common thing either. And I’m not very happy with the solution to install a quickier time sync daemon (it fails sometime too, and does not fix the problem, just work around).

I did not check my RTCclock in the bios yet. Will come back if I see something strange there.

Also looks like lot of people in the previous threads are using HP laptop. That’s also my case. Could it be related?

Last edited by milouse (2023-12-05 20:09:13)

seth · 2023-12-05 20:12:30

seth wrote:

How many parallel windows installations do you have?

Also, does the complete journal suggest more RTC or general clock issues (notably during the boot, but generally)?

milouse · 2023-12-05 22:05:03

For information, I did go to my bios… and everything looks fine. The clock ticks and displays the right date and time.

seth wrote:

Also, does the complete journal suggest more RTC or general clock issues (notably during the boot, but generally)?

On my side no, apart when it fails just after suspend.

For information, here is what a previous resume sooner today looks like

déc. 05 14:51:15 computer systemd[1]: Starting System Suspend...
déc. 05 14:51:15 computer systemd-sleep[73168]: Entering sleep state 'suspend'...
déc. 05 14:51:15 computer kernel: PM: suspend entry (s2idle)
déc. 05 14:51:15 computer wpa_supplicant[781]: wlo1: CTRL-EVENT-DSCP-POLICY clear_all
déc. 05 14:51:15 computer wpa_supplicant[781]: nl80211: deinit ifname=wlo1 disabled_11b_rates=0
déc. 05 14:51:15 computer kernel: Filesystems sync: 0.005 seconds
déc. 05 15:11:34 computer kernel: Freezing user space processes
déc. 05 15:11:34 computer kernel: Freezing user space processes completed (elapsed 0.002 seconds)
déc. 05 15:11:34 computer kernel: OOM killer disabled.
déc. 05 15:11:34 computer kernel: Freezing remaining freezable tasks
déc. 05 15:11:34 computer kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
déc. 05 15:11:34 computer kernel: printk: Suspending console(s) (use no_console_suspend to debug)
déc. 05 15:11:34 computer kernel: ACPI: EC: interrupt blocked
déc. 05 15:11:34 computer kernel: ACPI: EC: interrupt unblocked
déc. 05 15:11:34 computer kernel: pci 0000:00:00.2: can't derive routing for PCI INT A
déc. 05 15:11:34 computer kernel: pci 0000:00:00.2: PCI INT A: no GSI
déc. 05 15:11:34 computer kernel: [drm] PCIE GART of 1024M enabled.
déc. 05 15:11:34 computer kernel: [drm] PTB located at 0x000000F41FC00000
déc. 05 15:11:34 computer kernel: amdgpu 0000:03:00.0: amdgpu: SMU is resuming...
déc. 05 15:11:34 computer kernel: amdgpu 0000:03:00.0: amdgpu: dpm has been disabled
déc. 05 15:11:34 computer kernel: amdgpu 0000:03:00.0: amdgpu: SMU is resumed successfully!
[…]

In between nothing interesting to report (no upgrade, no reboot…). And last time it occurs for me was long before the current archive state of my logs

seth · 2023-12-06 07:25:47

seth wrote:

seth wrote:
How many parallel windows installations do you have?

And also please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

milouse · 2023-12-06 10:16:36

What do you mean by "How many parallel windows installations do you have?". You mean Microsoft Windows? If yes, I don’t have windows installed on this machine. Only Archlinux, with systemd-boot.

I’m not very confident with the fact to share a full log, as I’m not sure whether it will contain sensible information. What data specifically might be of interest?

V1del · 2023-12-06 11:17:25

We don't know exactly, which is why we need the full log. Generally speaking the journal should not contain anything sensitive maybe filter out IP addresses or so but clearly mark them as redacted.

ColourfulPro · 2024-02-29 21:40:28

I have the same error with Lenovo Yoga 7 Pro (14APH8, 82Y8), Ryzen 7 7840HS.
Sometimes it returns from suspend state normally, but sometimes it changes date to the random day in the future (mostly to 2078 year).

feb 28 18:17:06.188397 notebook kernel: PM: suspend entry (s2idle)
feb 28 18:17:06.192207 notebook kernel: Filesystems sync: 0.001 seconds
apr 27 16:07:22.315611 notebook kernel: Freezing user space processes
apr 27 16:07:22.353149 notebook kernel: Freezing user space processes completed (elapsed 0.002 seconds)
apr 27 16:07:22.353176 notebook kernel: OOM killer disabled.
apr 27 16:07:22.353190 notebook kernel: Freezing remaining freezable tasks
apr 27 16:07:22.353205 notebook kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
apr 27 16:07:22.353217 notebook kernel: printk: Suspending console(s) (use no_console_suspend to debug)
apr 27 16:07:22.353227 notebook kernel: ACPI: EC: interrupt blocked
apr 27 16:07:22.353241 notebook kernel: Unable to read current time from RTC
apr 27 16:07:22.353251 notebook kernel: Unable to read current time from RTC
apr 27 16:07:22.353261 notebook kernel: Unable to read current time from RTC
apr 27 16:07:22.353269 notebook kernel: Unable to read current time from RTC
apr 27 16:07:22.353284 notebook kernel: ACPI: EC: interrupt unblocked
apr 27 16:07:22.353294 notebook kernel: [drm] PCIE GART of 512M enabled (table at 0x00000080FFD00000).
apr 27 16:07:22.353303 notebook kernel: amdgpu 0000:63:00.0: amdgpu: SMU is resuming...
apr 27 16:07:22.353478 notebook kernel: amdgpu 0000:63:00.0: amdgpu: SMU is resumed successfully!
apr 27 16:07:22.353623 notebook kernel: nvme nvme0: 16/0/0 default/read/poll queues

I have no Windows installations, just Linux as main OS.

Looks like this is an error with last Lenovo series with Ryzen 7840, because TheMinefighter from #3 has similar laptop.

I though that it may be a problem with RTC (or CMOS battery), but the laptop is new (3 months) and when time is changed i see the next info:

$ timedatectl status
Local time: Su 2186-08-20 03:41:07 EEST
Universal time: Su 2186-08-20 00:41:07 UTC
RTC time: We 2024-02-28 10:03:41
Time zone: Europe/Kyiv (EEST, +0300)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

So it looks like RTC is ok, but local time is changed and kernel "Unable to read current time from RTC".

seth · 2024-02-29 22:03:19

There's also https://bbs.archlinux.org/viewtopic.php … 7#p2149257

sudo journactl -b | grep -i rtc
lsmod | grep rtc

But what might simply happen is that the RTC isn't ready to reply when the waking system tries to sync the time.
After the wakeup, try

sudo hwclock -r

and if that looks like the clock on your wall

sudo hwclock -s

Then check "date"

You might be able to leverate a https://wiki.archlinux.org/title/Power_ … stem-sleep to automatize this.

ColourfulPro · 2024-03-01 10:07:48

Yes, i can return my date-time to normal value via NTP too. Usually i disable and reenable date synchronization in Settings app manually, but i understand that i can make automation for this process. But anyway it looks like a bug in the kernel or some error with the hardware.

You say it may be because of "RTC isn't ready to reply when the waking system tries to sync the time" - is this normal behavior? Or some kernel fix needed to make it work normally?

This is the output for commands you asked:

feb 28 17:59:22 notebook kernel: PM: RTC time: 15:59:06, date: 2024-02-28
feb 28 17:59:22 notebook kernel: rtc_cmos 00:01: RTC can wake from S4
feb 28 17:59:22 notebook kernel: rtc_cmos 00:01: registered as rtc0
feb 28 17:59:22 notebook kernel: rtc_cmos 00:01: setting system clock to 2024-02-28T15:59:07 UTC (1709135947)
feb 28 17:59:22 notebook kernel: rtc_cmos 00:01: alarms up to one month, 114 bytes nvram, hpet irqs
apr 27 16:07:22 notebook kernel: Unable to read current time from RTC
apr 27 16:07:22 notebook kernel: Unable to read current time from RTC
apr 27 16:07:22 notebook kernel: Unable to read current time from RTC
apr 27 16:07:22 notebook kernel: Unable to read current time from RTC
apr 27 16:07:23 notebook kernel: mach_set_cmos_time: RTC write failed with error -22
apr 27 16:07:24 notebook kernel: mach_set_cmos_time: RTC write failed with error -22
apr 27 16:07:25 notebook kernel: mach_set_cmos_time: RTC write failed with error -22
apr 27 16:07:26 notebook kernel: mach_set_cmos_time: RTC write failed with error -22
apr 27 16:07:27 notebook kernel: mach_set_cmos_time: RTC write failed with error -22
apr 27 16:07:28 notebook kernel: mach_set_cmos_time: RTC write failed with error -22
apr 27 16:07:29 notebook kernel: mach_set_cmos_time: RTC write failed with error -22
apr 27 16:07:30 notebook kernel: mach_set_cmos_time: RTC write failed with error -22
apr 27 16:07:31 notebook kernel: mach_set_cmos_time: RTC write failed with error -22
apr 27 16:07:32 notebook kernel: mach_set_cmos_time: RTC write failed with error -22
apr 27 16:07:33 notebook kernel: mach_set_cmos_time: RTC write failed with error -22
apr 27 16:07:34 notebook kernel: mach_set_cmos_time: RTC write failed with error -22

... 20+ same rows with -22 error each second

"lsmod | grep rtc" - return nothing

I don't have this error today, so i can't try "hwclock" manipulations you asked for, but last time when error present i had next result:

sudo hwclock --systohc
hwclock: ioctl(RTC_SET_TIME) to /dev/rtc0 to set the time failed: Invalid argument

seth · 2024-03-01 10:29:39

We don't care about NTP with this, w/ your journal, the rtc doesn't respond at least 12s after the resume - it'll probably not revive.
(error -22 is "invalid argument", so these are likely from failed attempts to write the system time back to the RTC, possibly after an NTP update)

Does adding "rtc_cmos.use_acpi_alarm=1" to the https://wiki.archlinux.org/title/Kernel_parameters change anything about the behavior?

ColourfulPro · 2024-03-04 09:16:14

I tested whole weekend with and without "rtc_cmos.use_acpi_alarm=1", but the bug didn't appear in both cases. So potentially bug depends on some other things (day of month, external conditions like charging status, running services etc). Or enabling this kernel option fixed the bug somehow. I will continue monitoring and get back to you if this bug reappears.

Arch Linux

#1 2023-02-17 19:49:41

crazy clock skew after suspend

#2 2023-02-17 20:47:03

Re: crazy clock skew after suspend

#3 2023-11-17 09:59:58

Re: crazy clock skew after suspend

#4 2023-11-17 13:59:06

Re: crazy clock skew after suspend

#5 2023-12-05 20:05:59

Re: crazy clock skew after suspend

#6 2023-12-05 20:12:30

Re: crazy clock skew after suspend

#7 2023-12-05 22:05:03

Re: crazy clock skew after suspend

#8 2023-12-06 07:25:47

Re: crazy clock skew after suspend

#9 2023-12-06 10:16:36

Re: crazy clock skew after suspend

#10 2023-12-06 11:17:25

Re: crazy clock skew after suspend

#11 2024-02-29 21:40:28

Re: crazy clock skew after suspend

#12 2024-02-29 22:03:19

Re: crazy clock skew after suspend

#13 2024-03-01 10:07:48

Re: crazy clock skew after suspend

#14 2024-03-01 10:29:39

Re: crazy clock skew after suspend

#15 2024-03-04 09:16:14

Re: crazy clock skew after suspend

Board footer