https://bugzilla.kernel.org/show_bug.cgi?id=221578
Bug ID: 221578
Summary: [BUG] ASUS M5451UA (Adol 14) — Kernel hangs during
ACPI initialization on AMD Ryzen 9 8945H platform
Product: ACPI
Version: 2.5
Hardware: AMD
OS: Linux
Status: NEW
Severity: blocking
Priority: P3
Component: Config-Tables
Assignee: [email protected]
Reporter: [email protected]
Regression: No
Created attachment 310200
--> https://bugzilla.kernel.org/attachment.cgi?id=310200&action=edit
acpidump file
================================================================================
[BUG] ASUS M5451UA (Adol 14) — Kernel hangs during ACPI initialization
on AMD Ryzen 9 8945H platform
================================================================================
================================================================================
PLATFORM INFORMATION
================================================================================
Laptop Model : ASUS Adol 14 Air M5451UADOL
Motherboard : ASUSTeK M5451UA v1.0
BIOS Version : M5451UA.310
CPU : AMD Ryzen 9 8945H
GPU : AMD Radeon 780M
RAM : 32 GB
Storage : 1TB NVMe SSD (TWSC TSC3CN1T0-F1T40S)
================================================================================
SOFTWARE ENVIRONMENT
================================================================================
Distribution : Ubuntu 26.04 LTS (also tested debian 13 and fedora 44 and
debian testing...)
Kernel Version : 7.0.0-15-generic (HWE)
Install Method : Live USB, dual-boot with Windows 11
================================================================================
PROBLEM DESCRIPTION
================================================================================
The system COMPLETELY HANGS during early kernel boot, immediately after ACPI
table initialization. The last visible kernel message is:
[137.444450] printk: legacy bootconsole [efifb] disabled
After this line, there is NO FURTHER OUTPUT, no panic, no error — the system
is simply dead (requires hard power-off).
This happens with EVERY kernel/distribution tested, UNLESS "acpi=off" is
passed as a kernel parameter.
================================================================================
BOOT LOG (Verbose / Loglevel=7)
================================================================================
The system boots normally through memory initialization, then hangs at the
ACPI transition point:
[ 97.586] Early memory node ranges
[ 98.091] Early memory node ranges
[ 99.269] node 0: [mem 0x0000000000001000-0x000000000009ffff]
[100.438] node 0: [mem 0x0000000000100000-0x0000000009a7efff]
...
[110.482] setup_percpu: NR_CPUS:8192 nr_cpumask_bits:16 nr_cpu_ids:16
nr_node_ids:1
[113.327] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-... root=UUID=...
ro loglevel=7 systemd.log_level=debug acpi_osi=!
"acpi_osi=Windows 2022" earlycon=efifb ignore_loglevel
log_buf_len=16M video=efifb:off nomodeset ...
...
[134.773] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[135.554] Console: colour dummy device 80x25
[136.444] printk: legacy console [tty0] enabled
[137.444] printk: legacy bootconsole [efifb] disabled
<<< SYSTEM HANGS HERE — NO FURTHER OUTPUT >>>
Note: The timestamps are approximate, reconstructed from a photograph of the
screen.
================================================================================
KERNEL PARAMETERS TESTED
================================================================================
All combinations below were tested — NONE resolved the hang. Only "acpi=off"
allows booting:
Kernel Parameter(s) Result
---------------------------------------------------------------------------
(no parameters) HANG
nomodeset HANG
nomodeset amdgpu.dc=0 amdgpu.aspm=0 HANG
acpi_osi=! "acpi_osi=Windows 2022" HANG
acpi_osi=! "acpi_osi=Linux" HANG
acpi=noirq HANG
pci=noacpi HANG
noapic nolapic HANG
pci=noacpi noapic acpi=noirq HANG
nosmp maxcpus=1 HANG
amd_iommu=off iommu=off HANG
processor.max_cstate=0 idle=halt HANG
amdgpu.dc=0 amdgpu.aspm=0 pci=noacpi acpi=noirq nomodeset
HANG
---------------------------------------------------------------------------
acpi=off BOOTS (but limited)
- no SMP
- no power management
- no USB4
================================================================================
DSDT ANALYSIS
================================================================================
The DSDT was extracted from the live system and disassembled (iasl -d).
ACPI table header:
DSDT @ 0x00000000 (40582 bytes)
OEM ID: "_ASUS_"
OEM Table ID: "Notebook"
OEM Revision: 0x01072009
Compiler: INTL 20200717
--------------------------------------------------------------------------------
ROOT CAUSE ANALYSIS: 3 FATAL ISSUES IDENTIFIED
--------------------------------------------------------------------------------
ISSUE 1: Hard-coded Memory OpRegions (3 instances)
---------------------------------------------------------------------------
The DSDT defines multiple OperationRegion fields at FIXED PHYSICAL MEMORY
ADDRESSES that are BIOS-private ranges. When the kernel parses these during
ACPI initialization, these addresses are not mapped in the kernel page tables,
causing a hang when the AML interpreter attempts to access them.
Region Address Size Line in DSDT
---------------------------------------------------------------------------
GNVS 0x953E6F18 0x0D 389
GRWA 0x953D3000 0x002E 6784
NRSV 0x953D4000 0x1000 2146
---------------------------------------------------------------------------
These addresses fall in the 0x953XXXXX range, which is RESERVED BY BIOS for
SMM/ASL runtime communication. The kernel does not own these pages during
early boot, and the AML interpreter walks off a cliff when parsing the Field
definitions within these OpRegions.
ISSUE 2: ALIB Method Calls (3 instances)
---------------------------------------------------------------------------
The \_SB.ALIB method is an AMD PROPRIETARY ASUS ALIB (AMD Library Interface)
used for SMU/Power management communication. Linux has NO IMPLEMENTATION of
this interface. When the DSDT calls ALIB(), the AML interpreter invokes a
method that tries to communicate with AMD SMU hardware in a Windows-specific
manner, resulting in a system hang.
Line Context Call
---------------------------------------------------------------------------
6988 AC adapter device ALIB (One, XX00)
(\_SB.PCI0.SBRG.EC0.AC0._PSR)
7312 Thermal management (STTM method) ALIB (0x0C, DPTI)
7460 Thermal management (MPLI path) ALIB (0x0C, DPTI)
---------------------------------------------------------------------------
ISSUE 3: NAPE Method — Dynamic PCI Config Access
---------------------------------------------------------------------------
The NAPE method (line 2521) computes a runtime memory address (PEBS + 0xB8)
and uses it to create a TEMPORARY OperationRegion to access PCI configuration
space:
Method (NAPE, 0, NotSerialized)
{
Acquire (NAPM, 0xFFFF)
DBG8 = 0x11
Local0 = (PEBS + 0xB8) // dynamic
address
OperationRegion (VARM, SystemMemory, Local0, 0x08) // temporary
OpRegion
Field (VARM, DWordAcc, NoLock, Preserve)
{
NAPX, 32,
NAPD, 32
}
Local1 = NAPX
NAPX = 0x14300000 // writes to PCI config space
...
}
If PEBS is not properly initialized by the firmware at the time the kernel
calls NAPE (from \_SB.PCI0._INI), the address computation produces an invalid
address and the OperationRegion access hangs.
--------------------------------------------------------------------------------
ADDITIONAL SUSPICIOUS CODE
--------------------------------------------------------------------------------
- _Q79 EC Query Method (line 7741):
Transfers EC data to \_SB.UBTC (USB4/TBT controller) via 16 field
assignments + Notify(UBTC, 0x80). The UBTC device is referenced as
External — if the kernel hasn't enumerated it yet, these references
may hang.
- PMRG OpRegion (line 435):
Fixed address 0xFED80300, 256 bytes — accesses AMD chipset power
management registers. Potentially also problematic.
================================================================================
IMPACT
================================================================================
This is a BLOCKER for Linux support on the ASUS M5451UA platform.
The only workaround (acpi=off) disables:
- All CPU cores except 1 (no SMP)
- ACPI power management (battery status, sleep/wake, thermal management)
- USB4 / Thunderbolt
- Keyboard backlight control
- Fan control
- Proper interrupt routing
This makes the system FUNCTIONALLY UNUSABLE for daily Linux use.
================================================================================
PROPOSED FIX DIRECTION
================================================================================
1. ALIB stubs in the kernel:
Add \_SB.ALIB to a kernel-level method blocklist or provide a no-op stub
in the AMD ACPI subsystem (drivers/acpi/acpica/ or
drivers/platform/x86/asus-wmi.c).
2. GRWA/GNVS/NRSV OpRegion quirk:
These fixed-address OpRegions should be detected and skipped during early
ACPI table loading, or their addresses should be remapped to
kernel-accessible memory.
3. DSDT override workaround exists:
Patching the 6 items above via acpi_override initramfs hook, but this is
a workaround — the root cause needs a proper kernel-level fix.
================================================================================
ATTACHMENTS AVAILABLE
================================================================================
- Full DSDT binary (dsdt.dat, 40582 bytes) — can be provided
- Full DSDT disassembly (dsdt.dsl, 9093 lines) — can be provided
- Screenshot of boot hang point — available
- acpidump output — can be produced on request
================================================================================
END OF BUG REPORT
================================================================================
Bug reporter: User of ASUS M5451UA laptop attempting Ubuntu 24.04 dual-boot
installation.
DSDT analysis performed with iasl (Intel ACPI Component Architecture,
version 20260408).
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
