Full system freeze on boot with charger connected — ACPI BIOS Error (AE_AML_BUFFER_LIMIT) on HP Victus 15-fb3xxx
https://askubuntu.com/questions/1568308/full-system-freeze-on-boot-with-charger-connected-acpi-bios-error-ae-aml-buff
I have an HP Victus 15-fb3xxx (Ryzen 7 7445HS, RTX 3050 laptop, BIOS F.14) running Ubuntu 26.04 (kernel 7.0.0-27-generic). The system freezes completely (hard freeze, requires forced shutdown) consistently when booting with the charger connected, even without any heavy workload.
In journalctl -b -1 -p err from the boot right before the freeze, I consistently see this:
kernel: No irq handler for 1.55
kernel: No irq handler for 2.55
[...]
kernel: ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Index (0x000000032) is beyond end of object (length 0x32) (20251212/exoparg2-393)
kernel: ACPI Error: Aborting method \_SB.WMID.WQBZ due to previous error (AE_AML_BUFFER_LIMIT) (20251212/psparse-529)
kernel: ACPI Error: Aborting method \_SB.WMID.WQBE due to previous error (AE_AML_BUFFER_LIMIT) (20251212/psparse-529)
WQBZ/WQBE appear to be HP-proprietary WMI methods related to temperature/power-mode reporting (also queried by the NVIDIA driver via PlatformRequestHandler, which in a separate log reports failed to get target temp from SBIOS).
I've already ruled out the WiFi driver (RTL8852BE-VT, rtw89_8852bte module) as the cause of this specific freeze — it had a separate, unrelated power-save-mode bug that I already fixed with rtw89_core.disable_ps_mode=1 via GRUB, and it no longer shows up in recent logs.
Concrete questions:
- Has anyone with an HP laptop (Victus, Omen, or similar) seen this exact AE_AML_BUFFER_LIMIT error on the WQBZ/WQBE methods, and correlated it with freezes specifically when the charger is connected/detected?
- Is there a kernel parameter or a way to blacklist the hp_wmi module that mitigates this without losing critical functionality (fan control, function keys)?
- Has HP fixed this ACPI table bug in any BIOS version newer than F.14 for this laptop line?
Happy to attach a full acpidump if that helps diagnose it further.
Update (July 10):
Some important corrections and new findings since posting:
The charger is NOT the trigger. I initially correlated the freeze with the charger, but it also happens on battery, with no charger connected, after ~40 minutes of normal uptime. So the charger connection was a red herring — please disregard that part of the title.
NVIDIA D3 power-state failure found. On one freeze I caught this on screen: nvidia 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible (plus the same for snd_hda_intel and an nvidia-modeset HDMI-0 pixel clock error). I mitigated it with nvidia.NVreg_DynamicPowerManagement=0x00 in GRUB (confirmed Runtime D3 status: Disabled), but the freeze still occurs, so this was a symptom, not the root cause.
The freeze leaves no trace in the local journal. journalctl -b -1 simply cuts off mid-activity with no error, oops, or panic — a silent hard hang. To capture it, I've set up netconsole / live journal streaming to a second machine over the network. Still waiting to catch a freeze with usable output.
The ACPI AE_AML_BUFFER_LIMIT errors on WQBZ/WQBE remain present in every boot regardless of the mitigations above.
Current GRUB cmdline: rtw89_core.disable_ps_mode=1 rtw89_pci.disable_aspm_l1=1 rtw89_pci.disable_aspm_l1ss=1 pcie_aspm=off nvidia.NVreg_DynamicPowerManagement=0x00
Will update again once I capture the hang over netconsole and/or after testing noapic and a BIOS update to F.15.
Update 2 (July 10, later):
Caught a hard freeze with actual output on screen this time (previously it was a silent hang with nothing in the local journal). The screen showed:
kernel: nvidia 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible
kernel: snd_hda_intel 0000:01:00.1: Unable to change power state from D3hot to D0, device inaccessible
nvidia-modeset: ERROR: GPU:0: Failure reading maximum pixel clock value for display device HDMI-0.
kernel: BUG: unable to handle page fault for address: ffffcb14037700d0
So the D3hot→D0 resume failure I mentioned in Update 1 isn't just a cosmetic error — it culminates in a real kernel page fault (likely nvidia-modeset dereferencing an invalid pointer after the device dropped off the PCI bus), which is what causes the full hang.
Root cause of the gap: nvidia.NVreg_DynamicPowerManagement=0x00 (which I'd already set) only disables NVIDIA's own internal power management — it does NOT disable the kernel's generic PCI runtime power management, which is a separate control. Checking:
cat /sys/bus/pci/devices/0000:01:00.0/power/control
returned auto, meaning the kernel could still autosuspend the GPU independently of the NVIDIA driver setting.
Fix applied: forced it to on and made it persistent via udev:
echo on | sudo tee /sys/bus/pci/devices/0000:01:00.0/power/control
/etc/udev/rules.d/99-nvidia-no-pm.rules:
SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{power/control}="on"
Currently monitoring to see if this closes the gap. Also using netconsole/live journal streaming to a second machine to catch any future freeze with full context, since local journalctl doesn't survive a hang this violent.
Update 3 (July 11):
Progress and new findings:
The freeze produces a real kernel page fault. After disabling runtime PM at the PCI level (echo on > /sys/bus/pci/devices/0000:01:00.0/power/control, made persistent via udev rule + systemd service), the freeze still occurred, and I caught this on screen before the black-screen hang:
nvidia 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible
snd_hda_intel 0000:01:00.1: Unable to change power state from D3hot to D0, device inaccessible
nvidia-modeset: ERROR: GPU:0: Failure reading maximum pixel clock value for display device HDMI-0.
BUG: unable to handle page fault for address: ffffcb14037700d0
So the failed D3hot->D0 transition leads to a kernel page fault. power/control was confirmed on at freeze time, so standard runtime PM wasn't the trigger — something else is still driving the GPU into D3.
Already in hybrid mode. prime-select query returns on-demand, so the hybrid configuration by itself does not prevent the freezes. HP Support has confirmed on their forums that Victus laptops aren't officially validated for Linux (GPU/audio/thermal only validated for Windows 11), consistent with the ACPI firmware bug being the root cause.
Currently testing noapic (boot logs show repeated No irq handler for X.55 messages, so interrupt routing via the broken ACPI tables seemed worth ruling out). Current cmdline:
rtw89_core.disable_ps_mode=1 rtw89_pci.disable_aspm_l1=1 rtw89_pci.disable_aspm_l1ss=1 pcie_aspm=off nvidia.NVreg_DynamicPowerManagement=0x00 noapic
Next isolated test, only if noapic proves insufficient, is fully disabling the dGPU via prime-select intel. The AE_AML_BUFFER_LIMIT / WQBZ/WQBE ACPI errors remain constant across every boot regardless of any mitigation.
Update (July 11) — root cause pinpointed in the ACPI method:
Captured the full AML failure via dmesg. The WQBZ method aborts on an off-by-one buffer access:
ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Index (0x32) is beyond end of object (length 0x32) (20251212/exoparg2-393)
Initialized Local Variables for Method [WQBZ]:
Local1: Integer 0x32
Local5: Integer 0x32
ACPI Error: Aborting method _SB.WMID.WQBZ due to previous error (AE_AML_BUFFER_LIMIT)
ACPI Error: Aborting method _SB.WMID.WQBE due to previous error (AE_AML_BUFFER_LIMIT)
hp_bioscfg: Returned error 0x3, "Invalid command value/Feature not supported"
The object length is 0x32 (50) and the method tries to index element 0x32 — one past the last valid index (0–49). A classic off-by-one in HP's AML bytecode. This is a firmware bug, not fixable via kernel parameters.
Things I've now ruled out as the freeze cause:
- WiFi driver (rtw89) — mitigated, no longer in logs.
- NVIDIA dGPU — freeze still happens with
prime-select intel (dGPU fully off, nvidia-smi reports no device).
- External mouse/keyboard — they enumerate cleanly (
Dell KB216, generic USB optical mouse), no i2c/usb errors tied to them.
noapic — tested and removed; it introduced new amd_gpio / atkbd / i2c_designware controller timed out errors without fixing the hang.- PCI runtime PM forced to
on — freeze persists regardless.
Also note amdgpu 0000:06:00.0: Runtime PM not available — even the integrated AMD GPU can't do runtime PM here, consistent with the ACPI power subsystem being broken at the firmware level.
Current plan: attempt a BIOS update to F.15 (via HP's USB flash mechanism if supported, to avoid needing Windows), since the root cause is in firmware. If HP hasn't fixed the WQBZ off-by-one in F.15, the fallback is an ACPI table override (acpidump + iasl) patching the method. Will report back.
