I'm hitting the same s2idle hang, and I have some evidence that might narrow this down — it looks like it could be a chain of AMD/s2idle + external-drive-power-management + filesystem-sync interaction, not purely a firmware issue on its own.
Same hang on the previous firmware version too — this isn't new with the latest linux-firmware-amd-graphics update, I was seeing it before as well, just less frequently. Symptom: the machine doesn't actually go to sleep — the power LED never starts slow-flashing, it just stays stuck as if still awake. Only a hard power-off recovers it. What the kernel log shows: journalctl -b -1 -k for the failed boot ends cleanly at: PM: suspend entry (s2idle) with nothing after — no further kernel messages at all, even with verbose PM debug logging (dyndbg="file drivers/base/power/main.c +p") enabled for a later attempt. Comparing against two successful long sleeps earlier in the same boot uptime, both log a Filesystems sync: N seconds line within single-digit milliseconds of PM: suspend entry: PM: suspend entry (s2idle) Filesystems sync: 0.003 seconds The failed attempt never produces that line. That points at the kernel's suspend-time sys_sync() (flushing all mounted filesystems, the very first step of the suspend path) hanging before it ever gets to suspending individual devices — consistent with it blocking on I/O to some filesystem that can't complete a flush, rather than a driver/device-suspend-callback problem. External drive angle: I have an 8TB HDD in a USB-to-SATA enclosure, which — like most such enclosures — has its own autonomous power-saving timer independent of anything the OS does. Two things line up: 1. Throughout this whole boot (40+ hours), udisksd's routine SMART housekeeping poll to that drive fails every ~10 minutes with a malformed response to the CHECK POWER MODE ATA command, each one triggering a full USB device reset to recover — evidence the USB-SATA bridge's handling of power-state queries is flaky. (This pattern alone isn't sufficient to cause a hang — it coexisted with two successful multi-hour sleeps in the same boot — but it does show the bridge is unreliable specifically around power-state communication.) 2. I have a VeraCrypt volume (official 1.26.29 .deb) mounted on that drive. It was actively mounted and running at the exact moment of the failed suspend. By contrast, after one of the successful long sleeps, that same drive came back as a fresh USB enumeration on resume (re-attached as a new SCSI device) rather than through the normal device-resume path — i.e. it was physically absent/fully power-cycled during that successful sleep, not present-but-asleep. I checked the VeraCrypt binary directly (strings) — this version has no built-in suspend-triggered unmount/PrepareForSleep handling, so it isn't VeraCrypt itself doing anything at suspend time; the theory is simpler than that: the drive spins itself down on its own schedule, the kernel doesn't know, and when suspend's filesystem sync tries to flush the mounted volume it has to wait for the drive to wake back up through a bridge that's already demonstrably unreliable at exactly that kind of power-state handshake — and sometimes that wait never resolves. So my working hypothesis is a three-way interaction: s2idle's suspend- entry sync path + an external drive that free-runs its own power management + a USB-SATA bridge that doesn't handle power-state queries/transitions cleanly. None of the three alone reproduces it reliably (I've had plenty of successful sleeps with the same drive attached), which may be why this has been hard to pin down from firmware/kernel logs alone. Next test on my end: unmounting the VeraCrypt volume (and ideally the whole drive) before letting the machine sleep, to see whether suspend stops hanging when that drive isn't mounted at all. Will report back with results. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2162104 Title: linux-firmware-amd-graphics 0ubuntu3.1 DMCUB fix causes suspend hang on Krackan APU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware-amd-graphics/+bug/2162104/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
