Troubleshooting failed suspend on Lenovo ThinkPad

I’m using the Lenovo ThinkPad X1 Carbon Gen 11. The BIOS doesn’t support s3 sleep so the only option is s2idle.

Out of the box, Qubes OS 4.2 RC3 works well but doesn’t suspend. I tried upgrading dom0 to kernel-latest but the problem persists. Screen turns off, fans stop spinning, then screen flashes on once or twice, fans start spinning again, and the lock screen appears.

Kernel logs show that the suspend was cancelled due to a hardware issue:

Sep 23 17:20:20 dom0 kernel: PM: suspend exit
Sep 23 17:20:20 dom0 kernel: PM: suspend entry (s2idle)
Sep 23 17:20:20 dom0 kernel: Filesystems sync: 0.007 seconds
Sep 23 17:20:21 dom0 kernel: Freezing user space processes
Sep 23 17:20:21 dom0 kernel: Freezing user space processes completed (elapsed 0.002 seconds)
Sep 23 17:20:21 dom0 kernel: OOM killer disabled.
Sep 23 17:20:21 dom0 kernel: Freezing remaining freezable tasks
Sep 23 17:20:21 dom0 kernel: Freezing remaining freezable tasks completed (elapsed 0.059 seconds)
Sep 23 17:20:21 dom0 kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Sep 23 17:20:21 dom0 kernel: proc_thermal_pci 0000:00:04.0: failed to save offset (-5)
Sep 23 17:20:21 dom0 kernel: iosm 0000:08:00.0: msg timeout
Sep 23 17:20:21 dom0 kernel: PM: suspend devices took 0.698 seconds
Sep 23 17:20:21 dom0 kernel: intel_pmc_core INT33A1:00: PM: dpm_run_callback(): acpi_subsys_suspend_late+0x0/0x50 returns -5
Sep 23 17:20:21 dom0 kernel: intel_pmc_core INT33A1:00: PM: failed to suspend late: error -5
Sep 23 17:20:21 dom0 kernel: PM: late suspend of devices failed
...
Sep 23 17:20:21 dom0 kernel: i915 0000:00:02.0: [drm] GT0: GuC firmware i915/adlp_guc_70.bin version 70.5.1
Sep 23 17:20:21 dom0 kernel: i915 0000:00:02.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3
Sep 23 17:20:21 dom0 kernel: nvme nvme0: Shutdown timeout set to 10 seconds
Sep 23 17:20:21 dom0 kernel: nvme nvme0: 10/0/0 default/read/poll queues
Sep 23 17:20:21 dom0 kernel: i915 0000:00:02.0: [drm] GT0: HuC: authenticated!
Sep 23 17:20:21 dom0 kernel: i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
Sep 23 17:20:21 dom0 kernel: i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
Sep 23 17:20:21 dom0 kernel: i915 0000:00:02.0: [drm] GT0: GUC: RC enabled
Sep 23 17:20:21 dom0 kernel: iosm 0000:08:00.0: msg timeout
Sep 23 17:20:21 dom0 kernel: PM: resume devices took 0.510 seconds
Sep 23 17:20:21 dom0 kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
Sep 23 17:20:21 dom0 kernel: OOM killer enabled.
Sep 23 17:20:21 dom0 kernel: Restarting tasks ... 
Sep 23 17:20:21 dom0 kernel: mei_pxp 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: bound 0000:00:02.0 (ops i915_pxp_tee_component_ops [i915])
Sep 23 17:20:21 dom0 kernel: done.
Sep 23 17:20:21 dom0 kernel: random: crng reseeded on system resumption
Sep 23 17:20:22 dom0 systemd-sleep[14852]: Failed to put system to sleep. System resumed again: Input/output error

The most interesting parts to me are:

  • acpi_subsys_suspend_late+0x0/0x50 returns -5
  • intel_pmc_core INT33A1:00: PM: failed to suspend late: error -5

But I don’t know what device this could be that’s failing to suspend. I tried disabling all optional devices in BIOS(webcam, fingerprint reader, WiFi, etc.) without success.

Does anyone have ideas on how I could troubleshoot this further?

Updated: sorry, I misunderstood your question, I though you were trying to make S0x suspend work which is still not supported.

Hmm, according to kernel docs s2idle maps to ACPI state S0. Does this mean your comment still applies and I should expect s2idle is fully unsupported for now?

Yes, it seems to be the same thing, just different names (Intel calls it S0ix).
Unfortunately it is unsupported in Qubes OS, nothing can be done at this point by usual user.

Follow the progress here:

1 Like

Thanks for the link, I will follow the progress.

Sad to hear this is not supported, because the newer ThinkPad machines like mine don’t have any option for S3 suspend so the only option we have on these devices is a full shutdown.

Actually they do have S3, e.g. Thinkpad T16 Gen1 and many others. The available BIOS/EFI settings (including S3 support) can be check on the Lenovo web site, they have BIOS/EFI emulator available in the browser.

The Lenovo BIOS simulator is new to me, thanks for sharing that!

Yes I see that the T16 Gen1 and Gen2 have the option Config > Power > Sleep State in the BIOS. Looks like this:

Even the X1 Carbon Gen 10 has this option, but unfortunately not the Gen 11.

Mark Pearson from the Lenovo team shared some background on why the S3 option was removed:

Most of our platforms (with the exception of a couple of workstations) are now S0ix only.
We did dual sleep support with both S3 and S0ix as an option in the BIOS (with S3 as ‘best effort’ for users who didn’t want to switch) on our Linux certified Intel platforms for a few years - and it was a nightmare.

We found many S3 issues would creep in with FW updates - devices would stop working on resume, system wouldn’t sleep properly and battery drain in a few cases were horrible. Getting fixes done took forever and we couldn’t delay FW updates for a sleep mode that was supposed to be ‘best effort’. Users were frustrated (understandably) and it was not a good experience for anybody. We were honestly trying to do the right thing - but it wasn’t working.
We made the decision to stop doing S3 support last year and to remove the option.

So it looks like issue #6411 that you shared will be increasingly important for Lenovo laptop users in future.

3 Likes

I think, it is already through the roof for laptop users.
As far as I know, Intel said something similar to “Intel CPUs of 11-12 Gen will not support S3”, but it was a lie, as we see S3 on some Thinkpads with Intel 12 Gen CPUs, including T16. But those Thinkpads are exceptions nowadays, most of laptop manufactures decided to drop S3 support as Intel advised.

Not obvious what/whom he blames, their own firmware developers of their own laptop’s hardware and devices they choose? I mean S3 existed for years, working perfectly well on many devices (but not all). Why would one blame S3 instead of firmware of devices they choose and use for being too unreliable and full of bugs within deep sleep? Looks a bit strange to me.

1 Like