Display doesn't power on after sleep/suspend (lid close or menu)

silverfos_ · 2026-01-30 16:27:58

seth wrote:

Did the ACPI errors only appear after switching to the 580xx drivers (and are you currently still using those)?

no, it's always been there ever since I first installed. Just that since you mentions ACPI i payed attention to it.

Also, you're stubbornly ignoring the comments about
seth wrote:
don't ignore the windows fast start condition (this isn't optional)

Oh my bad i forgot to specify. It's been off since the first day I got this pc. I haven't turned it on since.
Here's the cat:
https://paste.c-net.org/IglooHodges

Last edited by silverfos_ (2026-01-30 16:30:08)

seth · 2026-01-30 20:01:02

It's been off since the first day I got this pc. I haven't turned it on since.

But maybe Microsoft did (this frequently happens w/ updates) - please have a look and ensure that fast-start is still disabled.

silverfos_ · 2026-01-31 03:30:32

Ran the powercfg command again for safe measure. It is disabled (I haven't updated since the first use day, since I switched to win10 ltsc immediately). No change in suspend

seth · 2026-01-31 14:45:32

So the kernel resumes, but you're losing the nvme and it's not (likely) APST.
Ahead of the nvme is an mt7921e - can you disable the wifi chip in the UEFI?
Does the system resume from suspend when using nouveau instead of nvidia?

silverfos_ · 2026-02-01 13:20:22

seth wrote:

So the kernel resumes, but you're losing the nvme and it's not (likely) APST.
Ahead of the nvme is an mt7921e - can you disable the wifi chip in the UEFI?

disabled. here's the journalctl:
https://paste.c-net.org/SilentFrankie
as for nouveau, i will update in the future.
Additionally, is there any specific reason why the "root directory is getting lost"? It doesn't happen on the windows so it shouldn't be cause of the specific SSD, should it?

Last edited by silverfos_ (2026-02-01 14:12:38)

seth · 2026-02-01 15:11:35

This is conjecture, based off the fact that despite rebooting w/ sysrq+REISUB the wakeup isn't logged.
Why that is, if that is, is what we're trying to figure - but the HW most likely will no longer respond.
The usual suspects would be aspm, apst and of course a hibernating windows - but apparently that's not the cause.

You could try to lie to the BIOS,

acpi_osi=! acpi_osi="Windows 2015"

https://learn.microsoft.com/en-us/windo … inacpi-osi

Can you btw. reboot by frenetically pressing ctrl+alt+del?

silverfos_ · 2026-02-02 02:59:43

set osi parameters:
https://paste.c-net.org/CheersBoiled

here's the journal after ctrl+alt+del restart:
https://paste.c-net.org/FlippedFiercely

no changes in sleep states. When going to sleep, screen blinks once after it turns black. idk if it is changing display modes or something in that moment.
Oh and I used osi as windows 2021. Since my windows 10 ltsc is of version 21H2.

And a dire issue. Mouse is not responding after restart:
https://paste.c-net.org/GrumpyMirrors
I fixed it by removing the acpi_osi=! Line.

Last edited by silverfos_ (2026-02-02 03:23:55)

seth · 2026-02-02 16:16:55

"Mouse" is

Feb 02 08:23:02 snowfall kernel: input: ELAN06FA:00 04F3:327E Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-ELAN06FA:00/0018:04F3:327E.0002/input/input8
Feb 02 08:23:02 snowfall kernel: hid-generic 0018:04F3:327E.0002: input,hidraw1: I2C HID v1.00 Mouse [ELAN06FA:00 04F3:327E] on i2c-ELAN06FA:00
Feb 02 08:23:02 snowfall kernel: input: ELAN06FA:00 04F3:327E Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-ELAN06FA:00/0018:04F3:327E.0002/input/input16
Feb 02 08:23:02 snowfall kernel: hid-multitouch 0018:04F3:327E.0002: input,hidraw1: I2C HID v1.00 Mouse [ELAN06FA:00 04F3:327E] on i2c-ELAN06FA:00
Feb 02 08:23:02 snowfall kernel: mousedev: PS/2 mouse device common for all mice

The journal shows you rebooting, but no attempt to sleep - the plan is to *somehow* get a journal covering the botched wakeup OR (by lying to the ACPI) find a way to avoid that.
Other dysfunctions are immediately irrelevant (ie. if you can reboot and get a journal or properly wake up it's for the moment not important whether the mouse works or not)

silverfos_ · 2026-02-04 17:01:50

hey, sorry for 2 day delay. little college work. here's journal after a failed sleep
https://paste.c-net.org/OccupiedSolomon
Further, I won't be responding till 12th of Feb. Sorry, exams. Hope anyone reading this understand

Last edited by silverfos_ (2026-02-08 11:48:12)

seth · 2026-02-04 20:43:04

Ends in

Feb 04 22:29:32 snowfall systemd-sleep[1787]: Performing sleep operation 'suspend'...
Feb 04 22:29:32 snowfall kernel: PM: suspend entry (s2idle)
Feb 04 22:29:32 snowfall kernel: Filesystems sync: 0.327 seconds

You did reboot from there by spamming ctrl+alt+del?

I think you've not picked up on that and I'm not expecting all that much but can you ssh into the system after it wakes up?
Do you experience similar behavior when suspending from a live system (install iso or grml etc)?
Even if not it might be worth a shot to boot such, mount the root partition of the installed system (just so the nvme is in use for sure), suspend and wakeup and hope and see whether there're maybe nvme errors logged in the journal or dmesg or you get some when now trying to access the nvme.

silverfos_ · 2026-02-12 13:55:53

Hey, sorry for the delay in response.
No I did not restart by ctrl+alt+delete. It simply refused to function. I tried setting ctrlaltdel to hard and even tried other debug steps across internet. None helped.
As for SSH, I'll try it in a day. I will procure the bootable usb from a friend and try to mount and suspend. Please wait one more day. Once again, apologies for the delay.

seth · 2026-02-12 15:09:11

Ok, but the point remains to somethow trigger a controlled reboot, https://bbs.archlinux.org/viewtopic.php … 9#p2285669 made it seem like you were actually able to reboot out of this situation w/ ctrl+alt+del

For clarification: when failing to resume after the suspend you *can* reboot w/ sysrq+REISUB and have done so in the past and that has lead to still incomplete journals?
And to stress that: whenever you reboot by holding the power button, you'll not get any meaningful journal for the previous boot.
Once you hold the power button until the system reboots all data is lost no matter what - looking at such journals would be misleading waste of time.

silverfos_ · 2026-02-13 06:34:40

My fault. That was an error on my end. I merely restarted by clicking restart on the menu that appears after pressing it, without trying to sleep.
As for incomplete journals, it is not incomplete (or at least I think it's not) ever since I added the acpi_osi line.
I do not reboot with power button. And even if I do, i make sure to do the process again and restart using sysrq each time

Last edited by silverfos_ (2026-02-13 06:36:46)

seth · 2026-02-13 14:50:52

As for incomplete journals, it is not incomplete (or at least I think it's not) ever since I added the acpi_osi line.

The latest journals all end abruptly, so if
a) you cannot reboot by spamming ctrl+alt+del the userspace (systemd) doesn't properly work
b) you reboot w/ sysrq+REISUB but nothing gets permanently logged you're looking at an nvme-related issue or the userspace (systemd) fails for completely unrelated reasons

Therefore see whether

seth wrote:

Do you experience similar behavior when suspending from a live system (install iso or grml etc)?

because that doesn't depend on the nvme and will hopefully expose any problems you might have with that.

silverfos_ · 2026-02-14 16:25:05

Sorry for the delay. I had a new annoying problem. So I went into windows since I dual boot, to read a file. When I rebooted, linux and systemd was gone. I rebooted again thinking I just missed it. Nope. Again windows. I went into disk partitioning of windows and checked. Everything is right there. It just doesn't register. So I booted into iso. Mounted root to /mnt and efi to /mnt/boot. THEN I realised I'm supposed to mount efi to /boot and not /mnt/boot. Took a while but I fixed it. Anyways, coming back to our topic
I tried to reboot with REISUB once more. This was the result this time.
https://paste.c-net.org/RemovingMedina
Which... As usual looks like broken.
For the iso test, i assume I just need to mount the root and suspend, wake up and save journal in someplace.
But... After suspending in iso, it did not turn on. And I assume if I restart, journal is lost anyways.
Does that bring this to any answer?

seth · 2026-02-14 19:53:05

Mounted root to /mnt and efi to /mnt/boot. THEN I realised I'm supposed to mount efi to /boot and not /mnt/boot

Not before the chroot, no. Afterwards yes.
Sounds suspicious, though…

After suspending in iso, it did not turn on. And I assume if I restart, journal is lost anyways.

Can you reboot w/ sysrq+REISUB from here? (Won't preserve any journal but it might be relevant whether you get the same nature of wakeup failure from the iso)
Suspending w/o touching the nvme also failed?

silverfos_ · 2026-02-15 06:47:40

Suspending w/o touching the nvme also failed?

Pretty sure it didn't touch since I'm on the iso?
I can't chroot and suspend since it ignores any similar commands in the chroot environment.

whether you get the same nature of wakeup failure from the iso

By same nature if you mean it reboots after all the sequence of REISUB, it does. Nothing noticable at least.

As for /mnt/boot and /boot, well, it worked so alls well that ends well I guess.

Last edited by silverfos_ (2026-02-15 06:48:33)

seth · 2026-02-15 09:10:53

Pretty sure it didn't touch since I'm on the iso?

For the iso test, i assume I just need to mount the root and suspend

By same nature if you mean it reboots after all the sequence of REISUB, it does.

Have you tried whether you can get ssh access?

Using only sysrq+v should™ restore a framebuffer console, does that anything for you?

silverfos_ · 2026-02-17 18:10:30

Sorry for the delay. Do you want me to ssh after suspend? If yes, the answer is no. After suspend and wake up attempt by pressing any key, every attempt gives the output:

ssh: connect to host 192.168.x.x port xx: No route to host

As for sysrq+V, I'm not sure what it's supposed to do, but regardless, it does nothing. No response to any sysrq except B for reboot.
and as usual, nothing new from journal after reboot.

Feb 17 23:38:30 snowfall org_kde_powerdevil[946]: [ 992] Device /dev/i2c-5 lacks R/W permissions
Feb 17 23:38:30 snowfall org_kde_powerdevil[946]: [ 992] Device /dev/i2c-6 lacks R/W permissions
Feb 17 23:38:30 snowfall org_kde_powerdevil[946]: [ 992] Device /dev/i2c-7 lacks R/W permissions
Feb 17 23:38:30 snowfall org_kde_powerdevil[946]: [ 992] Device /dev/i2c-8 lacks R/W permissions
Feb 17 23:38:30 snowfall org_kde_powerdevil[946]: [ 992] Removing connected display on bus 8
Feb 17 23:38:30 snowfall org_kde_powerdevil[946]: [ 992] (dw_remove_display_by_businfo) No Display_Ref found for i2c bus: 8
Feb 17 23:38:31 snowfall systemd[1]: nvidia-suspend.service: Deactivated successfully.
Feb 17 23:38:31 snowfall systemd[1]: Finished NVIDIA system suspend actions.
Feb 17 23:38:31 snowfall systemd[1]: nvidia-suspend.service: Consumed 1.107s CPU time over 1.667s wall clock time, 263M memory peak.
Feb 17 23:38:31 snowfall systemd[1]: Starting System Suspend...
Feb 17 23:38:31 snowfall systemd-sleep[1304]: User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
Feb 17 23:38:31 snowfall systemd-sleep[1304]: This is not recommended, and might result in unexpected behavior, particularly
Feb 17 23:38:31 snowfall systemd-sleep[1304]: in suspend-then-hibernate operations or setups with encrypted home directories.
Feb 17 23:38:31 snowfall systemd-sleep[1304]: Performing sleep operation 'suspend'...
Feb 17 23:38:31 snowfall kernel: PM: suspend entry (s2idle)
Feb 17 23:38:31 snowfall kernel: Filesystems sync: 0.329 seconds

Last edited by silverfos_ (2026-02-17 18:18:08)

seth · 2026-02-17 21:54:09

sysrq+v (lowercase is important here) would enforce a framebuffer console.

https://wiki.archlinux.org/title/Kdump
Can you still crash the kernel (sysrq+c) ?

silverfos_ · 2026-02-18 04:22:34

Yes, I meant v. Since I typed in mobile it autocorrected.
As for crashing the kernel, can you tell me what I'm supposed to expect? How would I know if it crashed or not?
Nvm I forgot to read the link u sent. Imma check and update

Last edited by silverfos_ (2026-02-18 09:10:38)

seth · 2026-02-18 09:16:55

Blinking LEDs, but the only way crashing the kernel makes sense is if you have a crash kernel setup.
In that case the crash kernel would take over and you get access to the journal and the coredump/errors of the main kernel.

silverfos_ · 2026-02-18 13:59:04

So it turns out i can't make a crash setup either. I thought I'll reuse linux lts kernel and initramfs. Made a kdump.service file and stuff, checked for crashmemory setup. After standard setup, it fails. Initial crash test gave nothing, screen crashes and stays that way till end of time. Then I added the btrfs root info into the kdump.service append part. Now it does turn dark. But it turns dark just like suspend. No response, no access to ssh, nothing.
Additionally just checked kexec by itself:

sudo kexec -l /boot/vmlinuz-linux-lts --initrd=/boot/initramfs-linux-lts.img --reuse-cmdline
sudo kexec -e

It turns off the display but fails to reboot. It's an advancement from kdump and suspend tho, which has backlight powered on still.

Last edited by silverfos_ (2026-02-18 14:39:59)

seth · 2026-02-18 15:16:02

kexec isn't supposed to turn anything off - you're "rebooting" a different kernel but not the hardware.
Have you attempted kdumpst or simple-kdump ?
The immediate goal would be to setup kdump and https://wiki.archlinux.org/title/Kdump# … the_kernel out of a running system (not suspending it!) to see whether kdump is properly configured and the crash kernel takes over when crashing the main kernel
Iff that works, reboot (for a clean slate), suspend, fail to wake and press ctrl+c to trigger the crash

Sanity check, have we ever tested the behavior w/ nouveau?

silverfos_ · 2026-02-19 01:52:53

Yes we are supposed to reboot, but that's the thing, we're stuck in a suspend like state or a hang state when using kdump. As for kdumpst it is only for grub. And simple-kdump has some PGP signature issue no matter how many times I checked.
Also nope, haven't checked with nouveau. I believe that was the time I switched to LTS to try out a different kernel and forgot about it.

Arch Linux

#26 2026-01-30 16:27:58

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#27 2026-01-30 20:01:02

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#28 2026-01-31 03:30:32

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#29 2026-01-31 14:45:32

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#30 2026-02-01 13:20:22

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#31 2026-02-01 15:11:35

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#32 2026-02-02 02:59:43

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#33 2026-02-02 16:16:55

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#34 2026-02-04 17:01:50

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#35 2026-02-04 20:43:04

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#36 2026-02-12 13:55:53

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#37 2026-02-12 15:09:11

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#38 2026-02-13 06:34:40

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#39 2026-02-13 14:50:52

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#40 2026-02-14 16:25:05

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#41 2026-02-14 19:53:05

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#42 2026-02-15 06:47:40

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#43 2026-02-15 09:10:53

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#44 2026-02-17 18:10:30

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#45 2026-02-17 21:54:09

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#46 2026-02-18 04:22:34

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#47 2026-02-18 09:16:55

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#48 2026-02-18 13:59:04

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#49 2026-02-18 15:16:02

Re: Display doesn't power on after sleep/suspend (lid close or menu)

#50 2026-02-19 01:52:53

Re: Display doesn't power on after sleep/suspend (lid close or menu)

Board footer