Hi, on Debian-13 my systemd-logind is restarted after resuming from s2idle. It seems to be killed by the systemd watchdog, probably because the CLOCK_MONOTONIC timer in the kernel keeps running. Unfortunately it only happens in about 1 of 10 resumes from s2idle. So this might be a regression in the Linux kernel. I'm using Debian-13 with the standard Debian-13 kernel. I didn't observe this on Debian-12. But on Debian-12 I was building the kernel myself. So this might be a regression. But it could a Debian specific kernel issue as well. Additional effects: Unfortunately restarting systemd-logind will start an additional Xorg (didn't test Wayland). And this will overwrite /tmp/.X11-unix/X0 of the already running Xorg server, so no new graphical programs can be started in the running X11 session. That's the effect the user actually sees from all the underlying tech. Workaround (extensively not tested yet): systemctl edit systemd-logind.service [Service] WatchdogSec=0 Computer (dmesg): DMI: HP EliteBook 845 G8 Notebook PC/8895, BIOS T82 Ver. 01.18.00 08/27/2024 CPU + GPU: Ryzen 5 5650U Boot mode: EFI See also: systemd services are killed by watchdog when resuming from suspend/s2idle https://access.redhat.com/solutions/5118401 watchdog fires after s2idle - Lenovo X1 Yoga 3rd generation https://bugzilla.kernel.org/show_bug.cgi?id=200595 systemd watchdog will kill process after S1 https://github.com/systemd/systemd/issues/20284 Regards, kolAflash
P.S. /var/log/syslog lists lines these before I upgraded to Debian-13. So these lines where written when I was running Debian-12 with a 6.12.x kernel, which I compiled myself. systemd-timesyncd.service: Watchdog timeout (limit 3min)! systemd-udevd.service: Watchdog timeout (limit 3min)! systemd-journald.service: Watchdog timeout (limit 3min)! But systemd-logind startet appearing only after upgrading to Debian-13. So I guess the underlying issue existed for a longer time. At the moment I think, that it's probably a s2idle kernel issue that existed for a longer time. So let's see how the previously mentioned upstream kernel issue turns out. https://bugzilla.kernel.org/show_bug.cgi?id=200595 Regards, kolAflash
Hi all, There seems to be a longstanding issue with the combination of user- space watchdog timers (using CLOCK_MONOTONIC) and suspend-to-idle. This was reported at <https://bugzilla.kernel.org/show_bug.cgi?id=200595> and more recently at <https://bugs.debian.org/1107785>. During suspend-to-idle the system may be woken by interrupts and the CLOCK_MONOTONIC clock may tick while that happens, but no user-space tasks are allowed to run. So when the system finally exits suspend, a watchdog timer based on CLOCK_MONOTONIC may expire immediately without the task being supervised ever having an opportunity to pet the watchdog. This seems like a hard problem to solve! By definition we cannot allow CLOCK_MONOTONIC to run backward, and I assume we do not want it to stop while interrupts are being handled. But could CLOCK_MONOTONIC be split into a CLOCK_MONOTONIC_KERNEL (may tick during suspend-to-idle) and CLOCK_MONOTONIC_USER (only ticks while user tasks can run), with user-space CLOCK_MONOTONIC being the latter? (I'm aware that adding yet another clock type would be a rather large job even if this is possible.) Until and unless that happens, is it possible to detect that CLOCK_MONOTONIC advanced during suspend-to-idle by reading e.g. /proc/schedtat? If not, could the necessary information be exposed through one of the pseudo-filesystems? Ben.
So I don't know much about suspend-to-idle, but I'm surprised it's not suspending timekeeping! That definitely seems problematic. How much work do we expect to be done in irq context when we are in suspend-to-idle? Will any IRQ that fires (I assume many are masked in suspend-to-idle) resume the system? Or are there some irqs that fire and do work, but return without the system resuming? Yeah, I'm not eager for another functionally very similar clockid to be added, though something like this approach could be used. But I'd probably prefer to find a way to suspend/resume timekeeping instead (likely reading the clock, calculating the delta from suspend and calling timekeeping_inject_sleeptime64() from the irq handler). https://lore.kernel.org/lkml/20250603224304.3198729-3-ynaffit@google.com/ Where different tasks are frozen via the cgroup-v2 freezer, and we want to avoid watchdog timers from firing immediately when the task is pulled out of the freezer. In that case the proposal is to account for the per-task or per-cgroup freezer time, and export that so the watchdog logic understand if the application had a chance to run, or if a new watchdog timer should just be set instead. In that case there's a little more control over things, so adding the freezer time into the watchdog logic is doable, but I'm not sure if a similar approach would be viable for existing general linux applications around CLOCK_MONOTONIC. thanks -john
suspended in s2idle: https://docs.kernel.org/admin-guide/pm/sleep-states.html#suspend-to-idle Looking at enter_s2idle_proper(): https://elixir.bootlin.com/linux/v6.16-rc5/source/drivers/cpuidle/cpuidle.c#L154 We call tick_freeze(): https://elixir.bootlin.com/linux/v6.16-rc5/source/kernel/time/tick-common.c#L524 Which calls timekeeping_suspend() when the last cpu's tick has been frozen. So it seems like the problem might be somehow all the cpus maybe aren't entering s2idle, causing time to keep running? thanks -john
Well, there is a suspend-to-idle path in which timekeeping is not suspended. It is the one in which cpuidle_enter_s2idle() returns 0 (or less) causing cpuidle_idle_call() to fall back to call_cpuidle() after selecting the deepest available idle state. This happens when the cpuidle driver in use doesn't implement ->enter_s2idle() callbacks for any of its states and the most straightforward remedy is to implement those callbacks in the given cpuidle driver (they must guarantee that interrupts will not be enabled, however). There are also cases in which suspending timekeeping is delayed for various reasons. For instance, on some systems, if the temperature is too high, the platform will refuse to enter its deepest power state (ask platform designers which they thought that this would be a good idea), so the kernel waits for the temperature to drop before it attempts to go for proper suspend-to-idle. Moreover, if there are wakeup events while suspended that do not cause the system to resume (you may regard them as "spurious"), timekeeping is resumed and suspended again every time this happens. So in general time may keep running at least somewhat in the suspend-to-idle flow, but this also happens during any system suspend-resume flow (timekeeping is only suspended after all devices have been suspended and it takes time to suspend them all and analogously for resume).
It seems like in this case maybe would it be better to abort the suspend if the hardware doesn't really support it? Hrm. Practically how long would this thermal delay for s2idle be? Ok, I'd expect it to be resumed and suspended (though I'm wondering if that should be rethought) Yeah, for small amounts of time, I do expect that the suspend time will be slightly shorter than the time that applications are frozen - obviously to your point about the suprious irq case, that delta might grow with suspend time, but I'm hoping we're still dealing with relatively small amounts that won't confuse applications. But from the bug report it sounds like timekeeping is just never getting suspended at all, which is unexpected. thanks -john
Default seems to be WatchdogSec=180 So that's not a small amount of time. The problem only happens at about 1 in 10 times when resuming from s2idle. And s2idle is the only supported standby mode for this hardware. HP EliteBook 845 G8 Notebook PC/8895, BIOS T82 Ver. 01.18.00 08/27/2024 (no S3 support, https://bugzilla.kernel.org/show_bug.cgi?id=216516#c6 ) Thanks! kolAflash