Quite the glitch… I have my AMD FW13 (Ryzen 5 7640U, 32GB RAM, Kernel 6.5.6-300) plugged in to an HP TB dock, and have not run in to issues with it yet.
Not sure if my response onto this post is of any help, but here it is:
Thanks! I do have auto date/time enabled in settings.
I haven’t explicitly (command line systemctl) changed anything from defaults for systemd-timedated.service. It’s currently showing as running but only started very recently?
$ systemctl status systemd-timedated.service
â—Ź systemd-timedated.service - Time & Date Service
Loaded: loaded (/usr/lib/systemd/system/systemd-timedated.service; static)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Wed 2023-11-15 11:25:30 PST; 46s ago
Docs: man:systemd-timedated.service(8)
man:localtime(5)
man:org.freedesktop.timedate1(5)
Main PID: 12372 (systemd-timedat)
Tasks: 1 (limit: 71856)
Memory: 1.2M
CPU: 29ms
CGroup: /system.slice/systemd-timedated.service
└─12372 /usr/lib/systemd/systemd-timedated
Nov 15 11:25:30 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:25:30 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
ok, looks like it starts/stop periodically:
$ journalctl --output=short-full --unit systemd-timedated.service --boot
Wed 2023-11-15 10:45:40 PST angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Wed 2023-11-15 10:45:40 PST angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Wed 2023-11-15 10:46:32 PST angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Wed 2023-11-15 10:55:19 PST angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Wed 2023-11-15 10:55:19 PST angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Wed 2023-11-15 10:56:52 PST angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Wed 2023-11-15 11:19:23 PST angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Wed 2023-11-15 11:19:23 PST angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Wed 2023-11-15 11:19:53 PST angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Wed 2023-11-15 11:19:53 PST angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Wed 2023-11-15 11:19:53 PST angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Wed 2023-11-15 11:20:30 PST angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Wed 2023-11-15 11:20:30 PST angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Wed 2023-11-15 11:20:30 PST angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Wed 2023-11-15 11:21:30 PST angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Wed 2023-11-15 11:21:30 PST angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Wed 2023-11-15 11:21:30 PST angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Wed 2023-11-15 11:22:30 PST angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Wed 2023-11-15 11:22:30 PST angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Wed 2023-11-15 11:22:30 PST angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Wed 2023-11-15 11:23:30 PST angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Wed 2023-11-15 11:23:30 PST angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Wed 2023-11-15 11:23:30 PST angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Wed 2023-11-15 11:24:30 PST angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Wed 2023-11-15 11:24:30 PST angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Wed 2023-11-15 11:24:30 PST angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Wed 2023-11-15 11:25:30 PST angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Wed 2023-11-15 11:25:30 PST angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Wed 2023-11-15 11:25:30 PST angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Wed 2023-11-15 11:26:30 PST angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Wed 2023-11-15 11:26:30 PST angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Wed 2023-11-15 11:26:30 PST angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
However it has run every minute until earlier this boot:
$ journalctl --unit systemd-timedated.service --boot
Nov 15 10:45:40 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 10:45:40 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 10:46:32 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 10:55:19 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 10:55:19 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 10:56:52 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:19:23 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:19:23 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:19:53 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:19:53 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:19:53 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:20:30 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:20:30 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:20:30 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:21:30 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:21:30 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:21:30 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:22:30 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:22:30 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:22:30 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:23:30 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:23:30 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:23:30 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:24:30 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:24:30 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:24:30 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:25:30 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:25:30 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:25:30 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:26:30 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:26:30 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:26:30 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:27:30 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:27:30 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:27:30 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:28:30 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:28:30 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:28:30 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:29:30 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:29:30 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:29:30 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:30:30 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 15 11:30:30 angua systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 11:30:30 angua systemd[1]: Started systemd-timedated.service - Time & Date Service.
Nov 15 11:31:30 angua systemd[1]: systemd-timedated.service: Deactivated successfully.
Somewhat wild thought: When I first powered the machine on (before installing Fedora), I immediately went into the BIOS to make sure settings (AMDGPU memory window, charge threshold) were as I wanted them to be.
I did not set the RTC at that time. It might have been set at some default that’s far into the future.
I assume that when the OS eventually completed its NTP time sync during/after installation, it would have actually caused the RTC clock to also sync up. Could that not be the case on this board?
By the way, a little background on why I noticed and how this could bite users if it wasn’t a random fluke: NetworkManager is configured to automatically connect/require a VPN when connecting to my usual WLAN. So when I resumed the machine this morning, the VPN certificates had “expired”.
If it hadn’t been for that, it’s quite possible that chrony and/or systemd-timesyncd would have rather quickly fixed the clock before I would notice anything.
Even if so, if that’s not a one-off and the RTC can accelerate at relativistic speeds while suspended it could be an issue worth fixing. Similar certificate “expiration” can cause problems e.g. with enterprise login/screen unlock when resuming (Linux and/or Windows).
There is a very similar kernel report for this issue on some other products. AFAIK AMD has never reproduced it, and only seen by the two reports there previously.
There is a debugging patch specifically attached to that bug report. Any of you guys that can reproduce this issue, would you mind rebuilding your kernel with that patch? If you can reproduce the issue it will add a lot more context about the situation that lead to it which could be helpful at finding what is actually wrong in the kernel when this happens.
@Thomas_Weissschuh I also had a bunch of unable to read current time from RTC:
Tue 2023-11-14 23:46:33 PST angua kernel: PM: suspend entry (s2idle)
Tue 2023-11-14 23:46:34 PST angua rtkit-daemon[1675]: Successfully made thread 8887 of process 8852 (/usr/bin/gnome-shell) owned by '1000' high priority at nice level 0.
Tue 2023-11-14 23:46:34 PST angua kernel: Filesystems sync: 0.021 seconds
Tue 2023-11-14 23:46:34 PST angua rtkit-daemon[1675]: Successfully made thread 8887 of process 8852 (/usr/bin/gnome-shell) owned by '1000' RT at priority 20.
Tue 2077-09-28 18:41:15 PDT angua kernel: Freezing user space processes
Tue 2077-09-28 18:41:16 PDT angua kernel: Freezing user space processes completed (elapsed 0.001 seconds)
Tue 2077-09-28 18:41:16 PDT angua kernel: OOM killer disabled.
Tue 2077-09-28 18:41:16 PDT angua kernel: Freezing remaining freezable tasks
Tue 2077-09-28 18:41:16 PDT angua kernel: Freezing remaining freezable tasks completed (elapsed 0.058 seconds)
Tue 2077-09-28 18:41:16 PDT angua kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Tue 2077-09-28 18:41:16 PDT angua kernel: queueing ieee80211 work while going to suspend
Tue 2077-09-28 18:41:16 PDT angua kernel: PM: suspend devices took 0.179 seconds
Tue 2077-09-28 18:41:16 PDT angua kernel: ACPI: EC: interrupt blocked
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
Tue 2077-09-28 18:41:16 PDT angua kernel: Unable to read current time from RTC
but no mach_set_cmos_time in the journal at all.
@Mario_Limonciello I can’t promise I’ll succeed in building a patched kernel, haven’t done this since literally the last millennium. I think I’ll follow the Fedora guide.
@Loell_Framework something to run by you and/or Kieran (trying to limit tagging to people already in the thread): The kernel bug entry that Mario mentioned indicates that the EC can, in general, have an indirect effect on RTC behavior/use during s2idle. I have a couple of spare rechargeable cells available on a just-in-case basis for the two 11 gen machines in the household. Would it hurt/be worth a try to install one in this AMD machine’s empty holder to see if it has any effect? Also any EC thoughts about this clock issue in general?
that the EC can, in general, have an indirect effect on RTC behavior/use during s2idle .
IIRC the Framework EC is connected over eSPI, which it’s possible to read RTC time values through. Given all these failures are happening around the s2idle sequence is it plausible that it’s requesting RTC time values at the same time as Linux is?