[Bug]: Rapid Fn+F3 (power-mode) presses cause hard system freeze on ROG Zephyrus G14 GA403UM

[ujjwalpatil20]

Affected Component

rog-profiles (Power Profiles / Fan Curves)

Issue Description

Pressing the ROG power-mode hotkey (Fn+F3) rapidly and repeatedly can reliably cause the system to hard freeze. In this state, there is no panic, no "oops" message, and no watchdog reset; instead, the journal simply stops mid-write. This issue has occurred twice, both times immediately following a series of profile-change cycles logged by asusd within the same approximate one-second window.

Each hotkey press triggers an ACPI WMI notification, which leads to asus-nb-wmi changing the thermal throttle policy. This, in turn, prompts udev to notify asusd, which immediately rewrites the Energy Performance Preferences (EPP) and all three fan-curve tables over the WMI/EC channel. When the presses occur faster than the embedded controller (EC) can apply the previous write, the WMI notification call eventually fails with an error code of -EIO. As a result, the kernel becomes completely silent (see Relevant Logs). This behavior is consistent with the ACPI global-lock serialized AML interpreter being blocked indefinitely on an incomplete EC transaction, rather than a panic occurring on the Linux side.

Additionally, this firmware's power-mode and thermal ACPI path demonstrates pre-existing read failures even during normal single press use (refer to Relevant Logs). These include an AML symbol-resolution bug related to _TZ.THRM._SCP.CTYP, a message indicating "asus_armoury: No matching power limits found for this system," and NVIDIA PlatformRequestHandler SBIOS read failures, which may contribute to the rapid-fire presses causing the system to freeze completely.

Steps to Reproduce

1. Boot normally; let the desktop settle (asusd running, platform_profile = balanced).
2. Press Fn+F3 several times in quick succession - faster than the on-screen profile OSD can visibly cycle through Balanced/Performance/Quiet.
3. System freezes completely: no input response, no mouse movement, screen static. Requires a hard power-off (no key combo or magic-sysrq recovers it).

Expected vs Actual Behavior

Expected: Rapid hotkey presses should be debounced or queued, ensuring that only the final requested profile is applied. At a minimum, these presses should never cause the machine to freeze.

Actual: The system hard froze on two separate occasions. No crash or panic logs were generated; the kernel ring buffer simply ceased output mid-sequence.

Laptop Model / Board Name

ASUS ROG Zephyrus G14 GA403UM

Linux Distribution

Fedora 44 Workstation

Kernel Version

7.1.8-200.fc44.x86_64

asusctl / asusd / ROG Control Center Version

asusctl v6.3.8 Software version: 6.3.8 Product family: ROG Zephyrus G14 Board name: GA403UM Supported Core Functions: [ "xyz.ljones.AsusArmoury", "xyz.ljones.Slash", "xyz.ljones.Aura", "xyz.ljones.FanCurves", "xyz.ljones.Platform", "xyz.ljones.AsusArmoury", "xyz.ljones.AsusArmoury", "xyz.ljones.AsusArmoury", "xyz.ljones.AsusArmoury", "xyz.ljones.AsusArmoury", "xyz.ljones.AsusArmoury", "xyz.ljones.AsusArmoury", "xyz.ljones.AsusArmoury", "xyz.ljones.AsusArmoury", "xyz.ljones.AsusArmoury", ] Supported Platform Properties: [ ChargeControlEndThreshold, ThrottlePolicy, ] Supported Keyboard Brightness: [ Off, Low, Med, High, ] Supported Aura Modes: [ Static, Breathe, Pulse, ] Supported Aura Zones: [] Supported Aura Power Zones: [ Keyboard, ]

Desktop Environment & Display Server

GNOME (Wayland)

Relevant Logs

$ journalctl -b -1 -u asusd > ~/asusd.log

Startup (for context - shows some armoury attributes already fail to read even before any hotkey use):
<hostname> asusd[1445]: [INFO  asusd::asus_armoury] Reloading nv_dynamic_boost
<hostname> asusd[1445]: [ERROR asusd::asus_armoury] Failed to read: Io(Os { code: 19, kind: Uncategorized, message: "No such device" })
<hostname> asusd[1445]: [INFO  asusd::asus_armoury] Reloading ppt_pl3_fppt
<hostname> asusd[1445]: [ERROR asusd::asus_armoury] Failed to read: Io(Os { code: 19, kind: Uncategorized, message: "No such device" })
(same "No such device" pattern for nv_temp_target, nv_tgp, ppt_pl1_spl, ppt_pl2_sppt)

~15s after startup, six more of the same read failures fire on their own (no user action):
<hostname> asusd[1445]: [ERROR asusd::asus_armoury] Failed to read: Io(Os { code: 19, kind: Uncategorized, message: "No such device" })
  (x6, all identical, same timestamp)

Then nothing until the Fn+F3 burst just before the freeze - one full cycle shown, this exact block repeats 4 times inside ~1 second (one cycle per hotkey press):
<hostname> asusd[1445]: [DEBUG asusd::ctrl_platform] Platform: watch_platform_profile changed
<hostname> asusd[1445]: [INFO  asusd::ctrl_platform] ThrottlePolicy setting EPP
<hostname> asusd[1445]: [DEBUG asusd::ctrl_platform] Available EPP: [Default, Performance, BalancePerformance, BalancePower, Power, Default]
<hostname> asusd[1445]: [DEBUG asusd::ctrl_platform] Setting BalancePower
<hostname> asusd[1445]: [DEBUG rog_profiles] write_profile_curve_to_platform: writing profile:(balanced), CurveData { fan: GPU, pwm: [2, 20, 33, 45, 56, 81, 99, 135], temp: [47, 59, 62, 65, 67, 69, 71, 73], enabled: false }
<hostname> asusd[1445]: [DEBUG rog_profiles] write_profile_curve_to_platform: writing profile:(balanced), CurveData { fan: MID, pwm: [2, 40, 40, 71, 89, 119, 173, 206], temp: [47, 62, 65, 68, 70, 72, 74, 76], enabled: false }
<hostname> asusd[1445]: [DEBUG rog_profiles] write_profile_curve_to_platform: writing profile:(balanced), CurveData { fan: CPU, pwm: [2, 20, 33, 45, 56, 81, 99, 135], temp: [47, 62, 65, 68, 70, 72, 74, 76], enabled: true }
<hostname> asusd[1445]: [DEBUG asusd::asus_armoury] Tuning group is not enabled, skipping   (x6)
<hostname> asusd[1445]: [ERROR asusd::asus_armoury] Failed to emit updated limits for attribute 'nv_dynamic_boost': Zbus(FDO(Failed("Could not read current value")))
<hostname> asusd[1445]: [ERROR asusd::asus_armoury] Failed to emit updated limits for attribute 'ppt_pl3_fppt': Zbus(FDO(Failed("Could not read current value")))
<hostname> asusd[1445]: [ERROR asusd::asus_armoury] Failed to emit updated limits for attribute 'nv_temp_target': Zbus(FDO(Failed("Could not read current value")))
<hostname> asusd[1445]: [ERROR asusd::asus_armoury] Failed to emit updated limits for attribute 'nv_tgp': Zbus(FDO(Failed("Could not read current value")))
<hostname> asusd[1445]: [ERROR asusd::asus_armoury] Failed to emit updated limits for attribute 'ppt_pl1_spl': Zbus(FDO(Failed("Could not read current value")))
<hostname> asusd[1445]: [ERROR asusd::asus_armoury] Failed to emit updated limits for attribute 'ppt_pl2_sppt': Zbus(FDO(Failed("Could not read current value")))
<hostname> asusd[1445]: [ERROR asusd::ctrl_platform] Failed to emit armoury updates after profile change: Zbus(FDO(Failed("Could not read current value")))
-- this whole block repeats 4 times total, all within roughly 1 second, then the journal for this boot ends. No shutdown/reboot target is ever reached.

For context, journalctl -b -1 -k (kernel) for the same boot ends with these two lines - the very last kernel output in that boot, immediately after the asusd burst above, with no panic/oops/hung-task/watchdog messages following:
kernel: Failed to notify asus-wmi (retval): 0x1
kernel: asus 0003:0B05:19B6.0001: Failed to notify asus-wmi: -5

[scardracs]

I see you are using 6.3.8 while latest version is 6.4.0. Can you please try again against latest released version (you can find it on terra https://terrapkg.com)?

[scardracs]

I've been able to reproduce same bug on CachyOS with latest build. I'm wondering, though, why someone would normally press Fn+F5 (in my case) so many times and that fast to make the system freeze

[ujjwalpatil20]

I just wanted to go from Performance mode to Power saver, so I pressed it twice and my laptop froze.

Then I tried it again to confirm. So I just thought that I should report it.

[scardracs]

I just wanted to go from Performance mode to Power saver, so I pressed it twice and my laptop froze.

Then I tried it again to confirm. So I just thought that I should report it.

You did well on reporting it. The point is that I had to do it at least 5 times in less a second to trigger it so I was wondering why someone would do so