locked in suspend mode | keyboard not working in suspend mode #123

Activity

1. ghost changed the title [-]locked in suspend mode | keyboard not workng in suspend[/-] [+]locked in suspend mode | keyboard not working in suspend mode[/+] on Mar 14, 2020
2. qzed commented on Mar 15, 2020

   

   qzed

   on Mar 15, 2020

   Member

   More actions

   By default, Linux does not enable wake-up events from the keyboard or other input devices. See e.g. here on how you can change that. That being said, you will not be able to wake up the device via touchscreen, as that is disabled while the device is suspended.

   Does the device wake up via the lid or the power button?

   You may also want to look at journalctl -b -1 after you've tried to wake and then force-shut-down the system. This will give you the log from the last boot and may have some other information. I can also see some errors regarding nouveau in the dmesg log, which can also cause issues, e.g. system lock-ups. I recommend you try blacklisting nouveau completely (as described in jakeday/linux-surface#264 (comment)) and if needed rely on the nvidia proprietary driver.
5. qzed commented on Mar 15, 2020

   

   qzed

   on Mar 15, 2020

   Member

   More actions

   The journalctl log is a bit short, seems like it's only the top part of it. There should be a lot more stuff in there. Try journalctl -b -1 > out.log if you didn't do that already. Without more information (such as a log from trying to suspend/resume) I can't really help you. I suspect that something might be crashing during either suspend or resume, as there are no other errors apparent in the dmesg log. You did try again after blacklisting nouveau?
7. qzed commented on Mar 16, 2020

   

   qzed

   on Mar 16, 2020

   Member

   More actions

   Hmm, I can't see anything that would indicate why it's not working. You could try and see if unloading some modules before suspending (e.g ipts) fixes this. Just to make sure: The power button and lid are working when not suspended?
9. qzed commented on Mar 23, 2020

   

   qzed

   on Mar 23, 2020

   Member

   More actions

   Those messages are currently standard behavior when the IPTS module is unloaded. If it doesn't work depending on the way the suspend is initiated this could be a configuration problem. Can you check if this also happens when you run echo mem | sudo tee /sys/power/state?
11. qzed commented on Mar 23, 2020

    

    qzed

    on Mar 23, 2020

    Member

    More actions

    If that command works reliably, suspend works fine on the kernel side. That would point to a configuration issue, for example something like suspend on lid-close being set up through both Gnome (or your desktop environment) and systemd (in which case you should make sure that only one of those triggers it).
13. qzed commented on Mar 29, 2020

    

    qzed

    on Mar 29, 2020

    Member

    More actions

    Two things:

    • The GPU hangs might be caused by IPTS. Try running the following commands before suspending:

      modprobe -r ipts_surface
      modprobe -r intel_ipts
      modprobe -r mei_hdcp
      modprobe -r mei_me
      modprobe -r mei
      

    • Based on your logs it looks like you're actually suspending (and resuming) three times. Once directly after resuming:

      Mar 28 16:50:07 SB2-Mint kernel: PM: suspend exit
      Mar 28 16:50:07 SB2-Mint kernel: PM: suspend entry (s2idle)
      

      This can be caused by a configuration issue which I've mentioned before. In your log I see a couple of

      Mar 28 16:48:30 SB2-Mint systemd-logind[863]: Power key pressed.
      

      which indicates that sytemd-logind tries to handle the power button. I don't know how Cinnamon behaves, however it's based on Gnome and by default Gnome also tries to handle the power button event. Having both systemd and Cinnamon handle the power button will cause havoc, so maybe also try setting HandlePowerKey in /etc/systemd/logind.conf to ignore.
15. qzed commented on Apr 2, 2020

    

    qzed

    on Apr 2, 2020

    Member

    More actions

    Neat! You can ignore the mei_hdcp module if that doesn't exist, the key point is that you need to unload all mei_<...> modules that you have on your system.

    Is there any way to automate this process whenever I want to suspend the device?

    Yes, see https://github.com/linux-surface/linux-surface/wiki/Known-Issues#sleep-script. Just comment in the modprobe lines that you need (and comment out the bluetooth fix if you don't need that).

    Do I need to add the modules to the kernel after resuming from suspend?

    You should do so, yes. The sleep script should take care of that.
17. ghost closed this as completedon Apr 4, 2020