Hibernate/suspend from X = dark panel; from TTY = works (ASUS G14, hyb

NTGuardian · Yesterday 02:04:07

System

Laptop:    ASUS ROG Zephyrus G14, model GA401QM (2021)
CPU:       AMD Ryzen 7 5800HS with integrated Radeon graphics
iGPU:      Integrated AMD Radeon (Vega-arch, on the 5800HS package)
           — drives the laptop's eDP panel via amdgpu (DRM card2)
dGPU:      NVIDIA RTX 3060 Mobile / Max-Q (GA106M, Ampere)
           — used only for PRIME render offload (DRM card1)
Driver:    nvidia-open 595.71.05 (open kernel modules)
Kernel:    7.0.2-arch1-1
Display:   Xorg 21 via `startx` on VT1, no display manager, WM is dwm
Hibernate: btrfs swapfile (38.6 GiB), resume= and resume_offset= set

Problem

Plain suspend and hibernate both succeed mechanically — the system goes down, comes back, services restart, Bluetooth reconnects, audio plays. The failure is with the window system: the laptop's eDP panel stays dark on resume, but only when sleep was triggered from an active X session. Furthermore, when I turn off the laptop in this state, I can see visuals during shutdown (messages, splash screen).

What does and does not work:

• Suspend or hibernate from a non-graphical TTY (X never started, or cleanly exited first): works perfectly. Panel comes back.
• Suspend or hibernate from an active X session: panel dark on resume; system fully alive otherwise.
• Cleanly exit X back to TTY → hibernate → resume → `startx`: works perfectly.

So the bug is specifically "X alive across the sleep boundary."

Probably-related symptom (no hibernate involved)

From an active X session: pressing Ctrl+Alt+F2 switches to TTY2 fine. Pressing Ctrl+Alt+F1 to return to X freezes the panel — same recovery (hard reboot). So "VT switch back into the VT X is on" appears broken too, and hibernate-resume-into-X is structurally similar. I suspect a single underlying bug.

What I've already tried

• In /etc/modprobe.d/,

options nvidia_drm fbdev=0

mkinitcpio rebuilt: no change.
• Masked nvidia-suspend, nvidia-hibernate, nvidia-suspend-then-hibernate, nvidia-resume systemd services. Driver runtime params: PreserveVideoMemoryAllocations=2, UseKernelSuspendNotifiers=1, EnableResizableBar=0.

Resume parameters on the kernel command line:

resume=PARTUUID=… resume_offset=189797632

The kernel writes/reads the hibernate image successfully. mkinitcpio uses the `systemd` hook (not `udev`), so resume is handled in the initramfs without a separate `resume` hook.

What I'm looking for

(a) A workaround that doesn't require tearing X down across the sleep boundary (that would lose the session every cycle, defeating most of the point), or

(b) The actual root cause / a Xorg-side or kernel-side flag I haven't tried. Pointers to existing freedesktop, kernel.org, or NVIDIA bug reports for this specific failure mode (X-alive S4 resume blank on a hybrid AMD-iGPU + NVIDIA-Ampere laptop) would also be very welcome.

Happy to share `journalctl -b -1`, Xorg.0.log, modprobe configs, dmesg around the resume boundary, or anything else on request.

seth · Yesterday 10:47:50

Happy to share `journalctl -b -1`, Xorg.0.log, modprobe configs, dmesg around the resume boundary, or anything else on request.

Journal - the syptoms fit a pattern where a VT switch triggers some udev rule that stumbles over bogus rules - and nvidia siwtches the VT for the suspend and the VRAM preservation hooks.
Not sure whether that hinges on the PreserveVideoMemoryAllocations parameter, the services themselves or happens unconditionally.

See https://bbs.archlinux.org/viewtopic.php?id=309989 and friends.

NTGuardian · Yesterday 18:58:32

So, as a heads up, I am using Claude to help me with this, and I was using it originally for troubleshooting. I had Claude create a Markdown file describing the process, what we were doing, why we were doing it (partly for my own education), and other things. I can paste that Markdown if you want.

One of the things I did with Claude was mask the NVIDIA sleep services because of freezes associated with VT switching. I was testing if the VT switching visual freeze (which happens when X is running) was the reason why I was having this issue. But masking those services does not help the problem, and I still have it.

I have six logs for you:

Journal before failed hibernate, from a clean boot; X was started.
Journal after failed resume from hibernate. (Part 1 and Part 2, due to file size restrictions.)
Xorg log taken after failed attempt to resume.
Journal before successful hibernate, from a clean boot; X was not started (all was done in TTY2).
Journal after successful resume from hibernate from hibernate.
Xorg log taken after successful attempt to resume in TTY2 (switching back to TTY1 to start X).

seth · Yesterday 19:16:18

Remove or disable https://aur.archlinux.org/packages/input-remapper-bin
Do you have a regular $5 (+$3 Trump-Tariff) office supply keyboard & mouse?

Just to be clear:

From an active X session: pressing Ctrl+Alt+F2 switches to TTY2 fine. Pressing Ctrl+Alt+F1 to return to X freezes the panel

You can trigger this simply by switching from X11 to some console (and then trying to switch back) or S3 - no hibernation (S4) is required?
Does any of the above cover that failure?

NTGuardian · Today 02:30:35

seth wrote:

Remove or disable https://aur.archlinux.org/packages/input-remapper-bin

It seems to not be installed;

sudo pacman -R input-remapper-bin

says

error: target not found: input-remapper-bin

seth wrote:

Do you have a regular $5 (+$3 Trump-Tariff) office supply keyboard & mouse?

No, I have a Viper Gaming keyboard (from maybe eight years ago). Here is the entry for the keyboard from lsusb:

Bus 001 Device 006: ID 04d9:a124 Holtek Semiconductor, Inc. USB-HID Keyboard

seth wrote:

You can trigger this simply by switching from X11 to some console (and then trying to switch back) or S3 - no hibernation (S4) is required?

Correct, all that is needed is for X11 to be running. Attempting to sleep also triggers it, as does suspend.

Last edited by NTGuardian (Today 02:34:08)

seth · Today 05:58:03

Some input-remapper instance is running, the package was a guess and isn't relevant - just make sure to stop input-remapper

No, I have a Viper Gaming keyboard

At least try the behavior w/o the mouse and with either keyboard.

Arch Linux

#1 Yesterday 02:04:07

Hibernate/suspend from X = dark panel; from TTY = works (ASUS G14, hyb

#2 Yesterday 10:47:50

Re: Hibernate/suspend from X = dark panel; from TTY = works (ASUS G14, hyb

#3 Yesterday 18:58:32

Re: Hibernate/suspend from X = dark panel; from TTY = works (ASUS G14, hyb

#4 Yesterday 19:16:18

Re: Hibernate/suspend from X = dark panel; from TTY = works (ASUS G14, hyb

#5 Today 02:30:35

Re: Hibernate/suspend from X = dark panel; from TTY = works (ASUS G14, hyb

#6 Today 05:58:03

Re: Hibernate/suspend from X = dark panel; from TTY = works (ASUS G14, hyb

Board footer