Suspend issues on ThinkPad E495

User Support Hardware Issues
#1

I am running Qubes on my ThinkPad E495 and most things work pretty well now, after some initial startup problems. I upgraded to kernel-latest and this removed some graphics issues (e.g., not being able to adjust screen brightness). Overall, the system also feels more responsive.

However, I cannot get my laptop to wake up from suspend. I tried different stuff:

  • Made sure the UEFI is up to date
  • Tried suspending when ALL domUs were stopped
  • Disabled the redshift-gtk service that I had installed because I thought it might potentially interfere with something
  • I also successfully suspended the laptop using a live USB installation of Kali Linux which I had lying around. This works perfectly and the kernel is way older than kernel-latest on Qubes.

When going into suspend from Qubes, everything looks good (device LED is blinking as it should). When I try to wake the device up, the LED starts to shine permanently, indicating some reaction. After a few seconds, the fans spin up but that’s it. The screen remains pitch black.
journalctl indicates that Qubes never really comes back from sleep. The last message before suspend is “kernel: PM: suspend entry (deep)” and then the log continues after the reboot.

I am not really experienced with troubleshooting such issues. It would be great if anyone could provide help

1 Like
Diagnosing stalled black screen at resume
#2

Hey phl,

sounds like a similiar problem, that i had with my hp laptop.

Maybe you could check with

uname -r

if the latest stable kernel is still used. After upgrading dom0 the 5.6… kernel was still installed but it reverted back to the standard kernel. there was no message so i also ended up with a black screen after suspend.

maybe its that simple :slight_smile:

good luck

#3

I know exactly what you mean.
I had this issue a while ago and realized it because I could no longer adapt my screen brightness (which only works with kernel-latest).

I deinstalled the regular kernel a while ago due to this issue so unfortunately that’s not the solution.

#4

Just a quick update: In the meantime I migrated to the current-testing repository to try out an even more up-to-date kernel (5.8.16-1 at the time of writing). This didn’t help either.

I suppose finding the right driver to blacklist or tweaking some kernel parameters could be the key to success.

Unfortunately, I don’t know which configurations might be promising.

#5

Try disabling ASPM (PCIe power saving), maybe it helps.

#6

Thank you for your idea @Ni4.
I went through the following steps;

  • Searched ASPM in BIOS/UEFI, nothing to be found
  • Deactivated ASPM by setting the parameter pcie_aspm=off to the kernel command line in den.cfg
    Rebooted the system and tried to suspend.

Unfortunately it didn’t work.
While grepping for ASPM in dmesg output to confirm that it had indeed been disabled I found the line

ACPI FADT declares the system doesn't support PCIe ASPM, so disable it

This line is still there after removing the kernel option. So apparently the E495 does not even support ASPM, making it impossible to disable it.

I am afraid that rules out your idea :/.

#7

Any other updates on this problem (or potential solutions?).

1 Like
#8

Did you try ?

[user@sys-net config]$ cat /rw/config/suspend-module-blacklist
# You can list here modules you want to be unloaded before going to sleep. This
# file is used only if the VM has any PCI device assigned. Modules will be
# automatically loaded after resume.
iwlmvm
iwlwifi
1 Like
#9

Yes. I did. I have both drivers blacklisted. My issue is not a lack of network access upon resume (I can’t even get that far), it is the same as the OP.

I have a Thinkpad X1 Extreme Gen 3.

When I hit suspend, the laptop appears to go to sleep, however will not wake up from suspend.

I have tried the following:

I have upgraded to kernel-latest and updated the bios to the latest from lenovo (as of 15 June 2021)

Tried suspending when ALL domUs were stopped

As with OP, I also successfully suspended the laptop using a live USB installation of Ubuntu 20.04, which works.

When going into suspend, everything turns off and the power LED is a slow blinking (as it should). When I try to wake the device up, the LED starts to shine permanently, indicating some reaction. After a few seconds, the fans spin up but that’s it. The screen remains pitch black.

As with OP,

Blockquote

journalctl indicates that Qubes never really comes back from sleep. The last message before suspend is “kernel: PM: suspend entry (deep)” and then the log continues after the reboot.

Blockquote

1 Like
#10

Sorry I have been on vacation and just now found your messages. So far I have not made any progress regarding the suspend issues. A while ago I tried some driver blacklisting but nothing helped.

I always wanted to test an installation of Qubes 4.1 but I don’t have much spare time to experiment with these things lately.

#11

Since some update of dom0, without doing anything special, suspend mode now works perfectly well

#12

That’s interesting. For me it didn’t work until recently, when I decided to finally try out Qubes 4.1. The availability of the in-place updater certainly influenced my decision to try it out…

What should I say: now the system doesn’t boot at all :sweat_smile:.

I’ll see if I can get it back in a working state and if Qubes 4.1 fixes my suspend issue. From what I read so far, that is not necessarily the case. Especially with AMD systems, strange behaviour seems to be possible :/.

#13

Hi,

I’m experiencing the same problem. The system tries to go into sleep mode but wakes up again with bios error code 30. The fan just keeps running but no display.

Any idea where should i look for?
Thank you.

EDIT: I’m using AMD processor, I tried after shutdown of all vm’s still same sleeps and then wakes up.

#14

Small update (although, unfortunately, it doesn’t help):

I tested Qubes 4.1 compatibility a few weeks before it became stable (see https://github.com/QubesOS/qubes-issues/issues/7096).

This didn’t help either. For a while it made problems even worse and I found several related issues, pointing to UEFI bugs.
Ultimately, I could get R4.1 working, but suspend behaved exactly the same as before.

As a result I stopped using Qubes on my private Laptop for now :cry:. After a few weeks of using plain Fedora I have to say that my productivity has drastically increased due to working suspend (I most often use the device for just a few minutes each day), although I already hate to not have different dispVMs for browsing.

I still love Qubes on my work device though and hope that the more recent AMD devices will receive a mor stable support in the future (this seems to be mostly caused by Xen, not by something the Qubes team can influence directly).