What causes the long resume time: The fwts suspend/1_suspend-time-check failure (~6.9s resume, threshold 5.0s) is not caused by the kernel PM path itself. Kernel device resume completes in ~109ms: PM: resume of devices complete after 105.797 msecs PM: suspend exit
The 6-7 seconds are consumed after PM: suspend exit, by the /lib/systemd/system-sleep/hdparm post-resume hook (which calls /usr/lib/pm-utils/power.d/95hdparm-apm resume). That script runs hdparm -B 254 synchronously on each SATA disk. The hdparm ioctl blocks in the kernel because libata's Error Handler (EH) holds a SCSI queue freeze on the ata3 port while it spins the disk back up from STANDBY: PM: suspend exit ata3: link is slow to respond, please be patient (ready=0) ← +5.2s ata3: SATA link up 6.0 Gbps ata3.00: configured for UDMA/133 ← EH done, queue unfrozen systemd-suspend.service: Deactivated successfully. ← hook finally exits fwts: FWTS_RESUME ← 6.9s total fwts measures the resume time from when systemd-suspend.service deactivates. Because the backgrounded/blocked hdparm keeps that service's cgroup alive, fwts only records "resume complete" once the disk finishes spinning up. Booting with nohdparm on the kernel cmdline (which makes 95hdparm-apm exit immediately) drops the resume time to ~0.40s and the test PASSES on both 6.11 and 6.17. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2160187 Title: Suspend resume time is longer than the threshold on Dell Pro Tower QCT1255. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oem-6.17/+bug/2160187/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
