Boot freeze at Plasma desktop on AC→battery transition, correlated with nvidia_wmi_ec_backlight crash-loop + asusd-user panics

[DidYouGetSniped]

• ASUS ROG Strix G16 (2026), AMD Ryzen 9 9955HX3D + NVIDIA RTX 5070 Ti (hybrid)
• OS: Bazzite (bazzite-nvidia-open:stable), image version 44.20260629
• NVIDIA driver: 610.43.02 (open kernel module)
• Kernel: 7.0.9-ogc3.2.fc44.x86_64

Problem

System freezes at the KDE Plasma wallpaper (Wayland/KWin) specifically when:

1. Shutting down while on AC power
2. Booting on battery power

Booting on AC after AC shutdown, or booting on battery after battery shutdown, does not reproduce the freeze, it's specific to the AC→battery transition across a reboot.

I haven't confirmed the exact mechanism connecting the errors below to the freeze, but masking the crash-looping unit resolves it, so I'm reporting the asusd/asusd-user-side symptoms even if the root trigger turns out to be firmware-level.

Root cause (identified via journalctl)

1. ACPI firmware bug causes nvidia_wmi_ec_backlight to fail and its systemd unit to crash-loop:

ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SBRG.BPWM], AE_NOT_FOUND (20251212/psargs-332)
ACPI Error: Aborting method _SB.PCI0.AWMI.WMAA due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
nvidia-wmi-ec-backlight 603E9613-EF25-4338-A3D0-C46177516DB7-0: EC backlight control failed: AE_NOT_FOUND
systemd-backlight@backlight:nvidia_wmi_ec_backlight.service: Start request repeated too quickly.
systemd-backlight@backlight:nvidia_wmi_ec_backlight.service: Failed with result 'exit-code'.

This repeats dozens of times in rapid succession during boot.

2. asusd-user panics repeatedly around the same time:

asusd-user[3103]: thread 'main' (3103) panicked at asusd-user/src/daemon.rs:167:72:
asusd-user[3675]: thread 'main' (3675) panicked at asusd-user/src/daemon.rs:167:72:
asusd-user[3735]: thread 'main' (3735) panicked at asusd-user/src/daemon.rs:167:72:

asusd is also seen repeatedly probing the broken backlight path:

asusd[2131]: [INFO rog_platform::backlight] Backlight: Checking "/sys/devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7-0/backlight/nvidia_wmi_ec_backlight"

What I tried

• Blacklisting the nvidia_wmi_ec_backlight kernel module entirely (module_blacklist=nvidia_wmi_ec_backlight): fixed the freeze, but removed backlight control completely — no fallback backlight device appears in /sys/class/backlight/ on this hardware.
• Masking only the systemd unit (sudo systemctl mask systemd-backlight@backlight:nvidia_wmi_ec_backlight.service) while leaving the kernel module loaded: this fixed the freeze and kept backlight/keyboard-light control fully functional. Confirmed working across multiple AC-shutdown → battery-boot cycles.

[scardracs]

I'm not able to reproduce on the 2025 model (G614PR) but that's normal because it is an ACPI table bug introduced on the 2026 model AFAICS. Asusd has a sync lock for it and that's why it can't continue the boot process: the system register a /sys/class/backlight/nvidia_wmi_ec_backlight value before it fails and when it finds out that it's failed it tries over and over again to restore the correct value using the same wrong /sys/class/backlight/nvidia_wmi_ec_backlight.

We can make it non-blocking so it finds the wrong value, log it and continue to boot, even if /sys/class/backlight/nvidia_wmi_ec_backlight is wrong. Unfortunately we can't do much more if Asus does not fix it on their ACPI tables

[DidYouGetSniped]

Just looking over my issue report and I did make a small mistake.

To clarify, mine is actually the 2025 model line (specifically the G614FR revision), not a 2026.

Here is my exact hardware info:

• Model: ASUS ROG Strix G16 (G614FR-DS96)
• Specs: AMD Ryzen 9 9955HX3D, NVIDIA RTX 5070 Ti, 2.5K 240Hz screen

Your explanation about the sync lock makes total sense. Making asusd non-blocking so it logs the error and moves on sounds like a good idea, especially since masking the systemd unit kept my actual backlight controls working anyway.

[scardracs]

Just looking over my issue report and I did make a small mistake.

To clarify, mine is actually the 2025 model line (specifically the G614FR revision), not a 2026.

Here is my exact hardware info:

• Model: ASUS ROG Strix G16 (G614FR-DS96)
• Specs: AMD Ryzen 9 9955HX3D, NVIDIA RTX 5070 Ti, 2.5K 240Hz screen

Your explanation about the sync lock makes total sense. Making asusd non-blocking so it logs the error and moves on sounds like a good idea, especially since masking the systemd unit kept my actual backlight controls working anyway.

That's strange, though: I have the G614PR and it doesn't happen to me. Which BIOS version do you have? As per https://rog.asus.com/laptops/rog-strix/rog-strix-g16-2025-g614/helpdesk_bios/ you should have the v316, which was released back in june.

EDIT

I assume the _SB.PCI0.SBRG.BPWM call is valid for my Zen4 Ryzen 9 8940HX and not for the Zen5 Ryzen 9 9955HX. Probably it was removed/moved to another place and was not fixed on the ACPI Tables.

[DidYouGetSniped]

Yep, I am already on BIOS v316.

Manufacturer: ASUSTeK COMPUTER INC.
Product Name: G614FR
Version: G614FR.316
Release Date: 05/14/2026

[scardracs]

So, with the help of Antigravity I wrote down a complete analisys. You may want to send it to Asus to ask for a BIOS update with it fixed.

Analysis of the NVIDIA WMI EC Backlight Issue on ASUS ROG Strix G16 (2026 - G614FR)

This document details the root cause of the system freeze and asusd-user daemon panic on the ASUS ROG Strix G16 (2026 - G614FR) model equipped with AMD Ryzen 9 9955HX3D and NVIDIA RTX 5070 Ti.

---

1. Symptom Summary

During boot or transitions, the system freezes or hangs on a black screen/wallpaper (specifically in Wayland sessions like KDE Plasma/KWin). The logs reveal:

1. ACPI WMI execution failures:

   ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SBRG.BPWM], AE_NOT_FOUND (20251212/psargs-332)
   ACPI Error: Aborting method \_SB.PCI0.AWMI.WMAA due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
   nvidia-wmi-ec-backlight 603E9613-EF25-4338-A3D0-C46177516DB7-0: EC backlight control failed: AE_NOT_FOUND
   

2. systemd-backlight crash-loop:

   systemd-backlight@backlight:nvidia_wmi_ec_backlight.service: Start request repeated too quickly.
   systemd-backlight@backlight:nvidia_wmi_ec_backlight.service: Failed with result 'exit-code'.
   

3. asusd-user panic:

   asusd-user[3103]: thread 'main' (3103) panicked at asusd-user/src/daemon.rs:167:72:
   

---

2. Root Cause Analysis

We extracted the ACPI tables directly from the official ASUS BIOS update G614FRAS.316 and decompiled them using iasl. The findings confirm a major firmware regression in the DSDT/SSDT tables for this model.

Finding A: The NVIDIA Backlight SSDT Reference (ssdt_nv20dds.dsl)

The nvidia-wmi-ec-backlight driver exposes backlight control to the OS by interacting with the ASUS WMI interface mapped to the GUID 603E9613-EF25-4338-A3D0-C46177516DB7 (defined in the _WDG buffer).

When the kernel requests a brightness change, it evaluates the WMI method WMAA. Under ssdt_nv20dds.dsl, this method attempts to write the brightness value to the Embedded Controller (EC) using two fields:

External (_SB_.PCI0.SBRG.BPWM, FieldUnitObj) // Declared as an external object

Method (WMAA, 3, Serialized)
{
    ...
    ElseIf ((MODF == One))
    {
        LEDC = (LEDB & 0xFF)
        \_SB.PCI0.SBRG.MBDF = LEDC /* Writes to motherboard field MBDF */
        \_SB.PCI0.SBRG.BPWM = LEDC /* Writes to backlight PWM field BPWM (CRASH!) */
        Return (Zero)
    }
}

Finding B: Missing Field Definition in the DSDT (dsdt.dsl)

Since the SSDT references _SB.PCI0.SBRG.BPWM as External, the symbol must be defined in the primary ACPI table (DSDT).

However, searching the decompiled dsdt.dsl reveals that BPWM is completely missing from the DSDT fields.

For comparison, the companion field MBDF is correctly declared in the DSDT under the LPC bridge (SBRG) operation region (line 8003):

Offset (0xDF), 
MBDF,   8, 

But BPWM (which should map the Backlight PWM register) is absent.

---

3. Explaining the Chain Reaction and System Freeze

1. Driver Load Failure: When the nvidia-wmi-ec-backlight kernel module loads, it evaluates WMAA which triggers a write to \_SB.PCI0.SBRG.BPWM. Because BPWM does not exist in the ACPI namespace, the execution aborts with AE_NOT_FOUND.
2. Systemd Boot Loop: Systemd automatically spawns systemd-backlight@backlight:nvidia_wmi_ec_backlight.service to restore the display brightness. Since the sysfs write fails, the service crashes. Systemd repeatedly restarts the service in a tight loop, spamming udev and the kernel.
3. Daemon Hangups: The system daemon asusd listens to udev events and probes backlight paths synchronously. Reading from the failing ACPI backlight path causes the main thread of asusd to block on I/O.
4. asusd-user Panic: Because asusd is hung, it cannot service D-Bus requests. The user daemon asusd-user attempts to query the Aura/Anime interfaces on startup. When the D-Bus calls time out or return errors, asusd-user panics and exits due to unhandled .unwrap() calls in the daemon initialization code.
5. Graphical Interface Freeze: KWin/Wayland or KPowerDevil attempt to query the backlight interfaces during session startup. The synchronous block on the broken ACPI/sysfs path freezes KWin's event loop, locking up the entire graphical desktop.

---

4. Workaround

Masking the systemd backlight restore service for the broken device breaks the loop and allows the system to boot without freezing:

sudo systemctl mask systemd-backlight@backlight:nvidia_wmi_ec_backlight.service

This prevents systemd from continuously attempting to write to the missing ACPI register. The backlight and keyboard-light controls remain functional because they fall back to other interfaces (like GPU native backlight or asusd direct addressing) that do not rely on the broken nvidia_wmi_ec_backlight WMI path.

[DidYouGetSniped]

Thanks, this is extremely helpful.

[scardracs]

I wrote down a new one compared with my own and that explain why I'm not experiencing it

Analysis of the NVIDIA WMI EC Backlight Issue: ASUS ROG G614FR vs. G614PR

This document details the root cause of the system freeze and asusd-user daemon panic on the ASUS ROG Strix G16 (2026 - G614FR) model, contrasted with the working ASUS ROG Strix G16 (2025 - G614PR) model.

---

1. Symptom Summary

On the G614FR (2026) model, during boot or transitions, the system freezes or hangs on a black screen/wallpaper (specifically in Wayland sessions like KDE Plasma/KWin). The logs reveal:

1. ACPI WMI execution failures:

   ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SBRG.BPWM], AE_NOT_FOUND (20251212/psargs-332)
   ACPI Error: Aborting method \_SB.PCI0.AWMI.WMAA due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
   nvidia-wmi-ec-backlight 603E9613-EF25-4338-A3D0-C46177516DB7-0: EC backlight control failed: AE_NOT_FOUND
   

2. systemd-backlight crash-loop:

   systemd-backlight@backlight:nvidia_wmi_ec_backlight.service: Start request repeated too quickly.
   systemd-backlight@backlight:nvidia_wmi_ec_backlight.service: Failed with result 'exit-code'.
   

3. asusd-user panic:

   asusd-user[3103]: thread 'main' (3103) panicked at asusd-user/src/daemon.rs:167:72:
   

No such symptoms occur on the G614PR model.

---

2. Root Cause Analysis

We extracted the ACPI tables directly from both the G614FR (G614FRAS.316) and G614PR (G614PRAS.316) official ASUS BIOS updates and decompiled them using iasl.

The findings confirm a major firmware regression in the DSDT/SSDT tables for the G614FR model.

Finding A: Side-by-Side WMI Backlight Method Comparison (ssdt_nv20dds.dsl)

The nvidia-wmi-ec-backlight driver exposes backlight control to the OS by interacting with the ASUS WMI interface mapped to the GUID 603E9613-EF25-4338-A3D0-C46177516DB7 (defined in the _WDG buffer).

When the kernel requests a brightness change, it evaluates the WMI method WMAA.

Here is the side-by-side comparison of the WMI WMAA handler (specifically when writing brightness, Case (One) and MODF == One) between both laptop models:

ASUS ROG Strix G16 G614PR (Working Model)

ElseIf ((MODF == One))
{
    LEDC = (LEDB & 0xFF)
    \_SB.PCI0.SBRG.MBDF = LEDC /* Writes ONLY to motherboard field MBDF */
    Return (Zero)
}

ASUS ROG Strix G16 G614FR (Buggy Model)

ElseIf ((MODF == One))
{
    LEDC = (LEDB & 0xFF)
    \_SB.PCI0.SBRG.MBDF = LEDC /* Writes to motherboard field MBDF */
    \_SB.PCI0.SBRG.BPWM = LEDC /* Attempt to write to BPWM register (CRASH!) */
    Return (Zero)
}

Finding B: Missing Field Definition in the DSDT

In the buggy G614FR SSDT, the symbol BPWM is declared as external (External (_SB_.PCI0.SBRG.BPWM, FieldUnitObj)). This means it must be defined in the primary ACPI table (DSDT).

However:

• ASUS G614FR DSDT: BPWM is completely absent from the DSDT fields.
• ASUS G614PR DSDT: BPWM is also absent, but since the G614PR SSDT never attempts to write to it, no error occurs.

For comparison, the companion field MBDF is correctly declared in the DSDT under the LPC bridge (SBRG) operation region on both models:

Offset (0xDF), 
MBDF,   8, 

Because the G614FR motherboard firmware tries to update BPWM (which was never defined in its DSDT fields), any backlight adjustment throws AE_NOT_FOUND and crashes.

---

3. Explaining the Chain Reaction and System Freeze

1. Driver Load Failure: When the nvidia-wmi-ec-backlight kernel module loads, it evaluates WMAA which triggers a write to \_SB.PCI0.SBRG.BPWM. Because BPWM does not exist in the ACPI namespace, the execution aborts with AE_NOT_FOUND.
2. Systemd Boot Loop: Systemd automatically spawns systemd-backlight@backlight:nvidia_wmi_ec_backlight.service to restore the display brightness. Since the sysfs write fails, the service crashes. Systemd repeatedly restarts the service in a tight loop, spamming udev and the kernel.
3. Daemon Hangups: The system daemon asusd listens to udev events and probes backlight paths synchronously. Reading from the failing ACPI backlight path causes the main thread of asusd to block on I/O.
4. asusd-user Panic: Because asusd is hung, it cannot service D-Bus requests. The user daemon asusd-user attempts to query the Aura/Anime interfaces on startup. When the D-Bus calls time out or return errors, asusd-user panics and exits due to unhandled .unwrap() calls in the daemon initialization code.
5. Graphical Interface Freeze: KWin/Wayland or KPowerDevil attempt to query the backlight interfaces during session startup. The synchronous block on the broken ACPI/sysfs path freezes KWin's event loop, locking up the entire graphical desktop.

---

4. Workaround

Masking the systemd backlight restore service for the broken device breaks the loop and allows the system to boot without freezing:

sudo systemctl mask systemd-backlight@backlight:nvidia_wmi_ec_backlight.service

This prevents systemd from continuously attempting to write to the missing ACPI register. The backlight and keyboard-light controls remain functional because they fall back to other interfaces (like GPU native backlight or asusd direct addressing) that do not rely on the broken nvidia_wmi_ec_backlight WMI path.