Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

mesaprotector · 2024-03-14 09:41:08

Just to add another data point, I also have a Lenovo laptop that crashes if I "suspend it twice" by using cli and then the lid afterwards. I tested Wild Weasel's thing of plugging/unplugging while suspended, and it didn't seem to cause issues. After disabling the lid-suspend function in /etc/systemd/logind.conf, the laptop still wakes if I cli-suspend, close the lid, and then open it, but it does so without issues. I use S3 sleep which might make a difference here.

I'm tempted to try out the "double suspend" in Windows - if that crashes too there's probably no way to fix it.

mesaprotector · 2024-03-15 03:13:42

You might want to try this solution I found on the Linux Mint forums, if the logs aren't showing any issue (i.e. it's just a display problem): https://forums.linuxmint.com/viewtopic.php?p=1838605

Wild Weasel · 2024-03-15 10:36:10

seth wrote:

I was only addressing Wild Weasel's situation, specifically
it crashes 100% of the time if you try to unplug the AC cable while suspended, if the suspend was preformed on AC-power. If you suspend it on battery power it works fine.
Any condition where closing the lid while the system is suspended wakes the system (and then it dies or not) is an issue w/ the firmware or hardware rather than the OS.
Did the AC condition have any impact on your situation?

Well, it seems that closing the lid while suspended causes a crash (after an a kernel update v. 6.5.0.25). If I understand your question correctly.
On the other hand if you first suspend it via the lid, any subsequent changes of the lid position (either open or closed) do not seem to cause a crash in most of the cases. It resumes and sleeps back.

Last edited by Wild Weasel (2024-03-15 14:43:08)

gpsolo · 2024-03-30 22:58:10

The AC did act 1:1 with Weasel's in my case, definitely seems like an issue with the computer specifically.

Recently I've been looking at coreboot and libreboot, do you think if I went through and internally flashed the bios with a coreboot/libreboot rom that it could fix the acpi errors I get at the start of my boot? I feel like those acpi errors may be the source of the problem. Including that the bios doesn't recognize linux or allow me to lie to it without something breaking.

Last edited by gpsolo (2024-03-31 01:59:59)

seth · 2024-03-31 09:39:54

ACPI error messages are common and most are harmless.
If we assume that this is NOT a hardware problem (closing the lid accidentally triggers the same mechanism as opening it, causing a spurious event) replacing the firmware *MIGHT* sidestep this bug but likely will kill warranty and always bears the potential to brick the device.

Wrt hardware beign the potential cause, windows doesn't exhibit this behavior?

gpsolo · 2024-04-04 17:37:38

if you mean putting the computer to sleep in windows acts as expected then yes, windows does not exhibit the behavior I see in any linux installation.

Also, what is wrt hardware exactly?

Last edited by gpsolo (2024-04-04 17:38:43)

seth · 2024-04-04 20:13:00

Wrt hardware beign

"With regards to [the] hardware being"

If there're no official firmware updates available you can try your luck w/ coreboot. Mind the part where this is gonna kill your warranty and bears the potential of turning your notebook into a very exclusive paperweight.
You probably want to research other peoples experiences around coreboot and the specific model.

seth · 2024-05-05 06:39:54

https://bbs.archlinux.org/viewtopic.php … 1#p2169281 might be worth a shot, but it's a different model.

gpsolo · 2024-05-10 09:35:03

might be worth a shot, but it's a different model.

I just went through with the steps mentioned in the link. Although unlocking my bios was a bit different with using the combination of the keys Fn+R and Fn+N, pretty much spamming them in the advanced bios information menu, saving the changes, and reentering the bios
which got me into the hidden settings. I had similar options with there being an option between "S3/Modern Standy" which was defaulted to "Modern Standby" and "Modern Standby Type | Modern Standy + Si03" there was an option with "Si02", "Si02 + Si03", or "Si03 with workaround"
1. Si03, the default didn't ever work.
2. Si02, kept the fans on when in sleep and also exhibited the same behavior.
3. Si02 + Si03, same as Si03.
4. Si03 with workaround, never managed to boot into linux at all, at least my installation.
However, although my issue isn't entirely fixed, the S3 option in the "S3/Modern Standy" seems to allow the lid to close and sleep, but a new problem has started with this that the display doesn't turn back on after trying to power the system up, I also noticed the fans come back on oddly slowly. But, even though it's not perfect, this is the closest and best we've gotten so far. I'm going to try some live boots and also continue looking around with what the guy in the linked thread mentioned about frequency scaling and maybe some other settings related to display. Anything I should try for troubleshooting now that the system can stay asleep, just not turn on the display? Also, thank you, this is a great find.

seth · 2024-05-10 15:00:21

Anything I should try for troubleshooting now that the system can stay asleep, just not turn on the display?

Is it jus the display? Can you ssh into the system resp. manually activate the display or get output when switching the VT?
Or does the journal continue after the resume?

Ie. what makes you think the system woke up at all?

this is a great find thing you stumbled over

ftfy

gpsolo · 2024-05-11 21:55:51

I don't see anything in the journal that would suggest the system is trying to wake up again. The only indication that my system "should" be turning back on is the led going back from flashing blue to solid white. As far as my OS goes I don't think it is turning back on at all.
These are the last things in my journal when I try to awaken the system again:

May 11 15:47:31 TuyaSmart dnsmasq[1589]: started, version 2.90 cachesize 150
May 11 15:47:31 TuyaSmart dnsmasq[1589]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
May 11 15:47:31 TuyaSmart dnsmasq[1589]: DBus support enabled: connected to system bus
...skipping...
May 11 15:48:17 TuyaSmart sudo[4165]:       gp : TTY=pts/0 ; PWD=/home/gp ; USER=root ; COMMAND=/usr/bin/systemctl suspend
May 11 15:48:17 TuyaSmart sudo[4165]: pam_unix(sudo:session): session opened for user root(uid=0) by gp(uid=1000)
May 11 15:48:17 TuyaSmart systemd-logind[1476]: The system will suspend now!
May 11 15:48:17 TuyaSmart NetworkManager[1482]: <info>  [1715464097.5930] manager: sleep: sleep requested (sleeping: no  enabled: yes)
May 11 15:48:17 TuyaSmart sudo[4165]: pam_unix(sudo:session): session closed for user root
May 11 15:48:17 TuyaSmart sudo[4095]: pam_unix(sudo:auth): conversation failed
May 11 15:48:17 TuyaSmart sudo[4095]: pam_unix(sudo:auth): auth could not identify password for [gp]
May 11 15:48:17 TuyaSmart NetworkManager[1482]: <info>  [1715464097.8140] device (enp2s0): state change: unavailable -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
May 11 15:48:17 TuyaSmart kernel: r8169 0000:02:00.0 enp2s0: Link is Down
May 11 15:48:17 TuyaSmart NetworkManager[1482]: <info>  [1715464097.8220] device (p2p-dev-wlo1): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
May 11 15:48:17 TuyaSmart NetworkManager[1482]: <info>  [1715464097.8224] manager: NetworkManager state is now ASLEEP
May 11 15:48:17 TuyaSmart NetworkManager[1482]: <info>  [1715464097.8225] device (wlo1): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed')
May 11 15:48:17 TuyaSmart systemd[1]: Starting Network Manager Script Dispatcher Service...
░░ Subject: A start job for unit NetworkManager-dispatcher.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit NetworkManager-dispatcher.service has begun execution.
░░ 
░░ The job identifier is 1973.
May 11 15:48:17 TuyaSmart systemd[1]: Started Network Manager Script Dispatcher Service.
░░ Subject: A start job for unit NetworkManager-dispatcher.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit NetworkManager-dispatcher.service has finished successfully.
░░ 
░░ The job identifier is 1973.
May 11 15:48:17 TuyaSmart kernel: wlo1: deauthenticating from 7a:98:b5:ef:0e:c7 by local choice (Reason: 3=DEAUTH_LEAVING)
May 11 15:48:18 TuyaSmart wpa_supplicant[1560]: wlo1: CTRL-EVENT-DISCONNECTED bssid=7a:98:b5:ef:0e:c7 reason=3 locally_generated=1
May 11 15:48:18 TuyaSmart wpa_supplicant[1560]: wlo1: CTRL-EVENT-DSCP-POLICY clear_all
May 11 15:48:18 TuyaSmart wpa_supplicant[1560]: wlo1: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
May 11 15:48:18 TuyaSmart NetworkManager[1482]: <info>  [1715464098.1853] device (wlo1): supplicant interface state: completed -> disconnected
May 11 15:48:18 TuyaSmart NetworkManager[1482]: <info>  [1715464098.1855] device (wlo1): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'managed')
May 11 15:48:18 TuyaSmart NetworkManager[1482]: <info>  [1715464098.1857] dhcp4 (wlo1): canceled DHCP transaction
May 11 15:48:18 TuyaSmart NetworkManager[1482]: <info>  [1715464098.1858] dhcp4 (wlo1): activation: beginning transaction (timeout in 45 seconds)
May 11 15:48:18 TuyaSmart NetworkManager[1482]: <info>  [1715464098.1858] dhcp4 (wlo1): state changed no lease
May 11 15:48:18 TuyaSmart NetworkManager[1482]: <info>  [1715464098.1859] dhcp6 (wlo1): canceled DHCP transaction
May 11 15:48:18 TuyaSmart NetworkManager[1482]: <info>  [1715464098.1859] dhcp6 (wlo1): state changed no lease
May 11 15:48:18 TuyaSmart NetworkManager[1482]: <info>  [1715464098.2288] device (wlo1): set-hw-addr: set MAC address to 1E:35:20:53:F5:76 (scanning)
May 11 15:48:18 TuyaSmart mullvad-daemon[1559]: [mullvad_api::availability][DEBUG] Pausing API requests due to being offline
May 11 15:48:18 TuyaSmart dnsmasq[1758]: no servers found in /etc/resolv.conf, will retry
May 11 15:48:18 TuyaSmart dnsmasq[1589]: no servers found in /etc/resolv.conf, will retry
May 11 15:48:18 TuyaSmart dnsmasq[1802]: no servers found in /etc/resolv.conf, will retry
May 11 15:48:18 TuyaSmart NetworkManager[1482]: <info>  [1715464098.4353] device (wlo1): supplicant interface state: disconnected -> interface_disabled
May 11 15:48:18 TuyaSmart NetworkManager[1482]: <info>  [1715464098.4353] device (wlo1): supplicant interface state: interface_disabled -> disconnected
May 11 15:48:18 TuyaSmart NetworkManager[1482]: <info>  [1715464098.4356] device (wlo1): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
May 11 15:48:18 TuyaSmart NetworkManager[1482]: <info>  [1715464098.6115] device (wlo1): set-hw-addr: reset MAC address to D0:39:57:A1:9D:89 (unmanage)
...skipping...
░░ Subject: A start job for unit systemd-suspend.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit systemd-suspend.service has begun execution.
░░ 
░░ The job identifier is 2085.
May 11 15:48:18 TuyaSmart wpa_supplicant[1560]: wlo1: CTRL-EVENT-DSCP-POLICY clear_all
May 11 15:48:18 TuyaSmart wpa_supplicant[1560]: nl80211: deinit ifname=wlo1 disabled_11b_rates=0
May 11 15:48:18 TuyaSmart systemd-sleep[4244]: Performing sleep operation 'suspend'...
░░ Subject: System sleep state suspend entered
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The system has now entered the suspend sleep state.
May 11 15:48:18 TuyaSmart kernel: PM: suspend entry (deep)

Last edited by gpsolo (2024-05-11 21:56:22)

mesaprotector · 2024-05-11 23:31:03

It certainly doesn't look like your laptop woke up. S3 is frequently buggy on newer laptops. When your PC attempts to wake up, have you tried shutting it down using the REISUB sequence with the "SysRq" (should be Alt+PrtSc) key? You have to enable SysRq for the current session first, by

echo "1" > /proc/sys/kernel/sysrq

If it doesn't respond to this, the kernel has likely panicked on attempting to wake up.

trivia21 · 2024-08-28 10:06:35

I solved this by blacklisting the ideapad-laptop kernel module. (Create a file /etc/modprobe.d/blacklist-ideapad-laptop.conf with contents "blacklist ideapad-laptop", reboot.)
Someone here complains about loosing some functionality using this workaround. I'm not sure what he is talking about, I have no problems any more.
Maybe the ideapad-laptop module is not supposed to be loaded, or it needs a fix for LOQ laptops?

mesaprotector · 2024-08-28 16:53:22

trivia21 wrote:

I solved this by blacklisting the ideapad-laptop kernel module. (Create a file /etc/modprobe.d/blacklist-ideapad-laptop.conf with contents "blacklist ideapad-laptop", reboot.)
Someone here complains about loosing some functionality using this workaround. I'm not sure what he is talking about, I have no problems any more.
Maybe the ideapad-laptop module is not supposed to be loaded, or it needs a fix for LOQ laptops?

For my LOQ, the ideapad_laptop module is needed for the Airplane Mode keyboard shortcut to work (Fn + F8). I don't believe it's necessary for brightness controls.

Based on my previous experimentation I'm guessing it also is necessary for muting the mic with Fn + F4 and disabling the touchpad with Fn + F10. Anything power or battery related I instead use LenovoLegionLinux.

trivia21 · 2024-08-28 19:10:07

mesaprotector wrote:

For my LOQ, the ideapad_laptop module is needed for the Airplane Mode keyboard shortcut to work (Fn + F8). I don't believe it's necessary for brightness controls.
Based on my previous experimentation I'm guessing it also is necessary for muting the mic with Fn + F4 and disabling the touchpad with Fn + F10. Anything power or battery related I instead use LenovoLegionLinux.

I confirm that the airplane mode and mute mic shortcuts don't work. Disabling the touchpad (Fn + F10) works fine.

Last edited by trivia21 (2024-08-28 19:15:33)

Arch Linux

#26 2024-03-14 09:41:08

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#27 2024-03-15 03:13:42

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#28 2024-03-15 10:36:10

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#29 2024-03-30 22:58:10

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#30 2024-03-31 09:39:54

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#31 2024-04-04 17:37:38

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#32 2024-04-04 20:13:00

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#33 2024-05-05 06:39:54

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#34 2024-05-10 09:35:03

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#35 2024-05-10 15:00:21

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#36 2024-05-11 21:55:51

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#37 2024-05-11 23:31:03

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#38 2024-08-28 10:06:35

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#39 2024-08-28 16:53:22

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

#40 2024-08-28 19:10:07

Re: Odd Behavior Of Systemctl Suspend With Laptop Lid (Lenovo LOQ 16aph8)

Board footer