On linux, there are two suspend modes:
# cat /sys/power/mem_sleep
s2idle [deep]
The one used by default, s2idle does not seem to save much power, and on resume idle power usage is much worse, since the processor no longer goes to states beyond C3 (bios 3.07, kernel 5.16.0; Issues with power usage - #5 by Brad_J EDIT: note that the excess idle power usage after resume from s2idle can be solved by passing nvme.noacpi=1; see Linux battery life tuning - #156 by technical27).
deep does not have these issues, but resume is very slow (~10 s). I think it would be good to try to track down what makes it so slow.
EDIT: My look at the kernel log initially suggested that there was a delay there, but that was a red herring; all delays I thought I saw happen after I can see the console again. So, at least according to the logs, the kernel is not the cause for the delay. So maybe this is a BIOS issue?
Anyway, mostly hoping for suggestions!!
Previous kernel log notes
Looking at the logs via journalctl, I see that once linux gets back control, it still takes about 4s (so there is 6s that probably needs work on the BIOS side…). Suspicious is:
Apr 17 17:51:40 raven mtp-probe[6390]: checking bus 3, device 8: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-9"
Apr 17 17:51:40 raven mtp-probe[6390]: bus: 3, device: 8 was not an MTP device
Apr 17 17:51:41 raven mtp-probe[6413]: checking bus 3, device 8: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-9"
Apr 17 17:51:41 raven mtp-probe[6413]: bus: 3, device: 8 was not an MTP device
Apr 17 17:51:42 raven ModemManager[530]: <info> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1d.0/0000:aa:0>
It is not clear to me why “Media Transfer Protocols” need to be probed on resume and perhaps one can disable this to improve resume time.~
p.s. On my X1 Yoga, the same linux part is about 1s, and there is no mtp-probe.
