Wake from Suspend?

Got it. I wonder if you can run a stress test with a lot more cycles and see if you catch an error at all?

Those logs you shared look clean.

I just ran a few more cycles of 30 minutes and got this issue (I am having it for the first time) : [WORKAROUND] xHCI host controller not responding at resume after suspend

See the log of the first cycle : Linux s2idle Power Report

relevant logs
xhci_hcd 0000:c2:00.4: xHCI host not responding to stop endpoint command
xhci_hcd 0000:c2:00.4: xHCI host controller not responding, assume dead
xhci_hcd 0000:c2:00.4: HC died; cleaning up
usb 2-1: PM: dpm_run_callback(): usb_dev_resume [usbcore] returns -22
usb 1-1: PM: dpm_run_callback(): usb_dev_resume [usbcore] returns -22
usb 1-1: PM: failed to resume async: error -22
usb 2-1: PM: failed to resume async: error -22

I am using a KVM (Aten CS84U), only for the keyboard and mouse (with keyboard and mouse emulation kept turned ON) so this might also be related, but from the kernel point of view it should simply look like a USB hub with class compliant mouse and keyboard connected.

lsusb --tree -v
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/2p, 480M

[...]

        |__ Port 002: Dev 004, If 0, Class=Hub, Driver=hub/4p, 12M
            ID 0557:8021 ATEN International Co., Ltd Hub
            |__ Port 001: Dev 005, If 0, Class=Human Interface Device, Driver=usbhid, 12M
                ID 0557:2213 ATEN International Co., Ltd CS682 2-Port USB 2.0 DVI KVM Switch
            |__ Port 001: Dev 005, If 1, Class=Human Interface Device, Driver=usbhid, 12M
                ID 0557:2213 ATEN International Co., Ltd CS682 2-Port USB 2.0 DVI KVM Switch

[...]

I will try to run even longer cycles to see if I can reproduce the non-waking up issue.
Also one thing I am thinking about, is that this script uses the ACPI SCI Wake Interrupt. I wonder if pressing the power button or waking up from USB devices produces a different one, and if maybe this could be the reason why I cannot reproduce the issue using this script ?

Who’da thunk! I had disabled this on a whim because the BIOS mentioned something about it being a Microsoft-related feature, but looks like Pluton is indeed essential to resume from suspend on Linux. Thanks so much for this pointer.

For the record: I was also seeing weird dmesg logs about “Low-power S0 idle used by default for system suspend” and “nvme platform quirk: setting simple suspend”. These messages are still there, even though suspend now works again, so maybe they were a red herring.

Those messages are normal. And yes on this system you won’t be able to suspend if you disable pluton but leave the IOMMU enabled.