[SOLVED] suspend, resume: system remains un-interactive

martin.s.weber · 2024-11-05 13:00:00

suspend with systemctl suspend -i
resume by hitting the power button
watch the lights go on (including screen and contents), but the system remains un-interactive.

I get exactly the other treatment from some recent 6.11 upgrade than https://bbs.archlinux.org/viewtopic.php?id=300008 -- while I see that my screens become visible again, displaying the contents of pre-suspend, the rest of the system is in a weird state.
sway does not process inputs - neither keyboard nor mouse events seem to reach it.
I can ping the box, but it won't react on a ssh login attempt.
The system journal contains the system going to sleep, but not it waking up again.
I have to to a hard reset (i.e., cut power, as it won't react on a normal power button push).
I don't have a nvidia card.
I didn't change hardware between 'it works' and 'it stopped working'. I noticed a few weeks back but was too busy to enter the conversation with my issues.

uname -a:

Linux atlas 6.11.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 01 Nov 2024 03:30:41 +0000 x86_64 GNU/Linux

Here's the tail of my journal from when it went to sleep:

Nov 04 22:47:28 atlas systemd-logind[658]: The system will suspend now!
Nov 04 22:47:28 atlas systemd[1]: Reached target Sleep.
Nov 04 22:47:28 atlas systemd[1]: Starting System Suspend...
Nov 04 22:47:28 atlas systemd-sleep[1074316]: Successfully froze unit 'user.slice'.
Nov 04 22:47:28 atlas systemd-sleep[1074316]: Performing sleep operation 'suspend'...
Nov 04 22:47:28 atlas kernel: PM: suspend entry (deep)
Nov 04 22:47:28 atlas kernel: Filesystems sync: 0.009 seconds
(end of file)

What would helpful debugging steps be? One I ought to be taking is using the LTS kernel for sure. I hope I have time tinkering about after my workday. Anything else I can try? TIA!

Last edited by martin.s.weber (2024-11-06 08:40:14)

seth · 2024-11-05 13:51:27

https://bbs.archlinux.org/viewtopic.php?id=300008

Do you also match that hardware (nvidia)?
Can you reboot the system w/ the https://wiki.archlinux.org/title/Keyboa … el_(SysRq) or just frenetically pressing ctrl+alt+del (the latter requires somewhat responsive userspace, in case this is just a visual problem, the sysrq needs to be explicitly enabled before sleeping the system)

Please post your complete system journal for an affected boot, eg.

sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st

for the previous ("-1") one.

Also please use [code][/code] tags. Edit your post in this regard.

martin.s.weber · 2024-11-05 14:19:49

seth wrote:

https://bbs.archlinux.org/viewtopic.php?id=300008
Do you also match that hardware (nvidia)?

Nope, I have a (bios-disabled) builtin AMD soft-gpu and an amd radeon rx 7700 xt.

I'll be doing some experiments this evening (CET) and come back with results / data.

martin.s.weber · 2024-11-05 21:31:19

- with my current (up-to-date) linux package (i.e., linux 6.11.6.arch1-1), I could reproduce this without even using wayland / X, just from the console, by suspending with systemctl suspend, and resuming by tapping my box's power button.
- I could reboot the system by using Alt + SysRq + b.
- The journal of the affected uptime is at http://0x0.st/XD-m.txt .

seth · 2024-11-05 21:37:47

- I could reboot the system by using Alt + SysRq + b.

You want the entire REISUB dance - notably the "S" syncs the filesystems - the wakeup isn't logged in the posted journal (which is expectable since the journal wasn't written to disc)

martin.s.weber · 2024-11-05 21:47:37

oh, right. I forgot the syncing indeed. Guess it's been too long since I've debugged embedded devices, where I'm much more used to sysrq usage!

While looking around, I saw https://bbs.archlinux.org/viewtopic.php?id=299993 which is .. kinda similar to what I'm seeing (except I actually get the pre-suspend screen contents back). That lead me down the bluetooth-disabling rabbit hole (i.e., https://bugzilla.kernel.org/show_bug.cgi?id=219290 ) which fixes the problem for me.

Given the remedy/workaround for the bugzilla entry remediates/works around my issue, I claim myself a dupe of that and will just wait for upstream to fix this. Realistically though, I suppose the file I added to my system will just live there forever

I'll disable the script for one more forced reboot including the sync of the journal and see if that turns up something new to the story; if not, I'll 'solve' this thread.

martin.s.weber · 2024-11-05 22:06:43

Hmm. Great. Before I tried (and then, chmod 0'd) the script to disable bluetooth, my "reproduction rate" was at 100%. resume from suspend would not work, period. Now it does, even after removing the script. The system ought to be the same, except if systemd somehow cached the shell script by turning it into a service or something? I am perplexed, but, at the same time, equipped with a strong conviction that this is being tracked and worked on already, and me having a workaround for the time being.
(I will wait for the next occurrence of the issue and then reinstall the workaround. Until then, consider this solved.)

martin.s.weber · 2024-11-06 08:05:48

So, it happened again, but I don't have new information to add.

I did manage to do the 'REISUB' dance with SysRq, but there's no additional information in the system journal.

journal available at http://0x0.st/XD8X.txt

Nov 06 00:19:19 atlas systemd-logind[645]: The system will suspend now!
Nov 06 00:19:19 atlas systemd[1]: Reached target Sleep.
Nov 06 00:19:19 atlas systemd[1]: Starting System Suspend...
Nov 06 00:19:19 atlas systemd-sleep[77840]: Successfully froze unit 'user.slice'.
Nov 06 00:19:19 atlas systemd-sleep[77840]: Performing sleep operation 'suspend'...
Nov 06 00:19:19 atlas kernel: PM: suspend entry (deep)
Nov 06 00:19:19 atlas kernel: Filesystems sync: 0.007 seconds

So even with killing the daemon (E / I) and syncing the discs, there's nothing new flushed there.

Anyways, I'll reinstate the bluetooth script and forget about this.

Last edited by martin.s.weber (2024-11-06 08:06:21)

Arch Linux

#1 2024-11-05 13:00:00

[SOLVED] suspend, resume: system remains un-interactive

#2 2024-11-05 13:51:27

Re: [SOLVED] suspend, resume: system remains un-interactive

#3 2024-11-05 14:19:49

Re: [SOLVED] suspend, resume: system remains un-interactive

#4 2024-11-05 21:31:19

Re: [SOLVED] suspend, resume: system remains un-interactive

#5 2024-11-05 21:37:47

Re: [SOLVED] suspend, resume: system remains un-interactive

#6 2024-11-05 21:47:37

Re: [SOLVED] suspend, resume: system remains un-interactive

#7 2024-11-05 22:06:43

Re: [SOLVED] suspend, resume: system remains un-interactive

#8 2024-11-06 08:05:48

Re: [SOLVED] suspend, resume: system remains un-interactive

Board footer