u/lexer-1024

I have spent an entire week debugging why my Lenovo LOQ 15APR9 (Ryzen 7 7435HS + RTX 4050) completely fails to wake from sleep on Arch linux after a recent system update. Looking deeper into the issue revealed broken BIOS ACPI tables, NVIDIA drivers internals and a fundamental truth about about how consumer hardware vendors treat linux users.

My Setup

• Lenovo LOQ 15APR9
• Ryzen 7 7435HS, RTX 4050 6GB, 24GB DDR5
• Arch Linux, kernel 6.18.25-1-lts, nvidia-open-dkms 595.71.05
• KDE Plasma on Wayland
• BIOS: PQCN24WW

At the start of this week, I updated my system and sleep became permanently broken. As soon as the device goes to sleep, the screen goes black, the keyboard's light turns off, the power button starts pulsing. Seems all good, then you wake it up and the keyboard would light up, the power button pulsing stops but the screen remains black. Every single time. The only thing to be done now is to force a reboot and then continue using the device.

I tried several different internet fixes. Some that I can remember include:

• Enabling DRM modesetting and setting the fbdev parameter
• Configuring initramfs to load the proprietary NVIDIA drivers before mounting the root filesystem and disabling the generic early KMS hook to prevent race conditions during boot.
• Enabling NVIDIA S0ix Power Management

Then I found this article on ArchWiki for this model: https://wiki.archlinux.org/title/Lenovo_LOQ_15ARP9

It states the laptop only supports S0ix as the power management mechanism and it also mentions the sleep issue on this device. It mentions the fix to this is enabling NVIDIA S0ix power management and no other workarounds are necessary. The cause of the issue and how things play out is mentioned to be a result of unknown factors.

Now this issue was really bugging me out, so, I decided to dig deeper and find those unknown factors and potentially fix the issue. Here's what I found. The NVIDIA systemd suspend/resume services were disabled by default on my machine. Enabling them seemed like a progress but changed nothing. Then I found out the /proc/driver/nvidia/suspend didn't exist. This file is what the nvidia-suspend.service writes "suspend" to, and what nvidia-sleep.sh checks for. Without it, the services run, exist successfully, and no absolutely nothing.

But that file should have existed why is it missing? Looking into the nvidia-open-dkms source code at /usr/src/nvidia-595.71.05/kernel-open/nvidia-/nv-procfs.c, line 1351:

if (NVreg_UseKernelSuspendNotifiers)
{
    create_suspend_file = NV_FALSE;
}

When NVreg_UseKernelSuspendNotifiers=1 (which is the default), the driver deliberately skips creating /proc/driver/nvidia/suspend. So I added options nvidia NVreg_UseKernelSuspendNotifiers=0 to my modprobe config.

So things should be fixed now? No, even with the suspend file present, services running correctly, and S0ix enabled, the kernel still enters s2idle and never returns. The journal ends at PM: suspend entry (s2idle) with nothing after it. No resume, no error, no timeout. A complete hard lock.

At this point I have no idea what is causing the deadlock or how I can look further into the issue as the journals provide me no information after the suspend entry. What I am hypothesising from the journals at this point is this:

ACPI BIOS Error: Could not resolve symbol [\_SB.PCI0.GPP0.PEGP.GPS.NVD1], AE_NOT_FOUND
NVRM: GPU0 _acpiDsmCallbackInit: SBIOS suggested GPS_2X supports function 517, but the call failed!

The BIOS is calling into a Windows-specific NVIDIA driver symbol (NVD1) that doesn't exist in the Linux driver. The ACPI GPS interface is completely broken on Linux because Lenovo wrote the BIOS exclusively for Windows. This likely causes the s2idle freeze because the power state transition for the GPU never completes correctly at the firmware level. That also explains why Windows ran just fine on this till last year before I switched it to Linux. The S0ix implementation was validated against Windows. Linux gets whatever happens to be compatible, which in this case is not much.

The broader question here is, that I purchased this laptop, and I chose to install Linux on it. That's my right. But the vendor has made architectural decisions at the firmware level that effectively lock power management to Windows. This isn't a driver problem that the kernel team can fix. It requires Lenovo to fix their ACPI tables in a BIOS update. I have opened a discussion for this on Lenovo forums: https://forums.lenovo.com/t5/Other-Linux-Discussions/LOQ-15ARP9-BIOS-ACPI-GPS-DSM-failure-breaks-Linux-S0ix-suspend/m-p/10030179

Server vendors like Supermicro, HPE, and Dell publish Linux-compatible firmware as a matter of course because enterprise customers demand it. Consumer laptop vendors don't face that pressure, so Linux users get broken sleep, broken hibernation, and workarounds that half-work. The open source community builds the OS that runs around 70% of the world's servers, the majority of cloud infra, embedded systems, and now increasingly desktop workloads. The least hardware vendors could do is test their firmware against it.

Still looking for a full fix. If anyone solved the s2idle hard lock on this specific mdoel, please share.