Suspend / resume failure after long suspend on ASUS Zenbook 14 OLED (UX3405MA)

[Emilio246L]

Is this a new report?

Yes

System Info

Void 6.12.64_1 x86_64 GenuineIntel notuptodate hold FF

Package(s) Affected

linux6.12-6.12.64_1 linux-firmware-intel- elogind-

Does a report exist for this bug with the project's home (upstream) and/or another distro?

No upstream report yet. Issue appears Void-specific or kernel/firmware interaction.

Expected behaviour

System should suspend and resume reliably.
Power events (lid close, power button, idle suspend) should not result in a black screen, forced reboot, or temporary boot failure.
elogind and runit services should remain available and responsive after long uptime.

Actual behaviour

After several hours of uptime, suspend or power events intermittently fail.
System may enter a black screen with keyboard backlight on and no display output.
On some occurrences the system fails to boot immediately after reboot, showing a black screen for ~1 minute before eventually booting.
Issue reproduces on multiple kernels (6.12.64 and 6.18.x).
Problem did not occur on this hardware previously and appeared after recent updates.

Steps to reproduce

1. Boot Void Linux on ASUS Zenbook 14 OLED UX3405MA.
2. Use system normally.
3. Leave the system suspended or idle for several hours (overnight).
4. Attempt to wake the system using the power button or lid open.
5. Observe that the screen remains black with keyboard backlight on.
6. Hold power button ~30 seconds to force shutdown.
7. Power on again; system may show black screen for up to ~1 minute before booting, or require a second forced reboot.

dmesg-current.txt
dmesg-readable.txt
lspci.txt
mem_sleep.txt
uname.txt

[oreo639]

Problem did not occur on this hardware previously and appeared after recent updates.

How recent?

[Emilio246L]

I think it's elogind s causing this issue I am not completely sure.

[oreo639]

Feel free to try #58486 and let me know if you still have the issue after restarting with it.

[dogknowsnx]

I'm still experiencing a similar issue on an old Asus laptop (2017-ish) running swayidle (invoking zzz) depending on libelogind-255.22_2 (tried w/ different kernels, as well).
The screen remains black after waking from suspend, I have to e.g. switch ttys in order to fully wake up the device. (did not help the last time)

$ cat /sys/power/mem_sleep
s2idle [deep]

[classabbyamp]

zzz doesn't do anything with elogind

[dogknowsnx]

zzz doesn't do anything with elogind

zzz modifies /sys/power/mem_sleepstate

Anyway, had to REISUB in order to write this :P

EDIT: tested elogind v255.22 built w/ the chimera patch to no avail - had to revert to libelogind-252.9_2

[oreo639]

EDIT: tested elogind v255.22 built w/ the chimera patch to no avail - had to revert to libelogind-252.9_2

Was this with elogind installed or just libelogind?

[jl4c]

Enable the elogind service.

[classabbyamp]

that will not help

[dogknowsnx]

libelogind only, which is required by libseat and swayidle on my system - so patching elogind that way is futile when it comes to the library, I guess

EDIT: Upstream suggests downgrading to v255.17 - will test later so far so good (v255.17 built w/o any sleep.patch) (EDIT#2: fyi v255.17 requires the lowercase "v" in the distfile)

[oreo639]

libelogind only, which is required by libseat and swayidle on my system - so patching elogind that way is futile when it comes to the library, I guess

Yeah, the patch is for a different issue.

EDIT: Upstream suggests downgrading to v255.17 - will test later so far so good (v255.17 built w/o any sleep.patch) (EDIT#2: fyi v255.17 requires the lowercase "v" in the distfile)

That is unfortunate, but thank you. I will look into it once I am available tonight/tomorrow. Sorry for any trouble.

[oreo639]

@dogknowsnx When you are available, can you check if you experience the issue with 252.39? https://github.com/oreo639/void-packages/tree/elogind