Speed up resume from S3 (deep) suspend?

Framework Laptop 13 Linux
1

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.

2 Likes
2

If I recall correctly from back when I was poking at it, on my system all ~12 seconds of the deep resume time are before Linux gets control. Once Linux starts measuring then it was only a few hundred milliseconds until it was “up”.

That was using pm-graph to measure the timings, IIRC.

1 Like
3

Thanks, that does seem consistent with what I found. So, the question is then whether some tricks in the BIOS or so can help speed up resume from deep suspend. A little beyond me, I fear, but perhaps others have ideas…

4

I’m using BIOS version 3.08 and compared to version 3.07 the resume time is way faster (more like 2 secs).

Maybe worth a try? The only “special” BIOS config I can think of is that I turned off VT-d (Intel’s IOMMU).

Regards,

Robert

5

Where did you get that version? As far as I can tell 3.07 is the latest?

6

Its not officially released, but you can download it from: https://downloads.frame.work/bios/Framework_Laptop_BIOS_EFI_3.08.zip

Regards,

Robert

8

Ah, good old “Insecure direct object reference.“ :grin:

9

I’ve been trying 3.08 out for a few days now, it’s the worst battery drain I’ve ever had with this laptop. 20% per night in deep sleep. 15 to 20 second wake up time from deep sleep.

Can I downgrade the firmware safely? is that allowed?

10

Sorry to hear that. I suspect you can downgrade, but I haven’t tried it myself.

11

So weird to hear about two very different experiences on the same laptop! Any differences in BIOS settings? Or, less likely, in OS/Distribution? Still holding off on trying the new BIOS myself, given this…

12

I’ve downgraded back to 3.07. Battery drain is normal again, wake time as well.

It’s weird indeed, I do hope this was a fluke and when the firmware officially lands, it will be better :wink: