Re: [BUG] 36-second boot delay due to by acpi_gpio_handle_deferred_request_irqs on ASUS ROG Strix G16 (2025)

[Mario Limonciello <superm1@kernel.org>]

++linux-gpio, Hans

On 12/17/25 4:06 AM, Francesco Lauritano wrote:
> ASUS ROG Strix G16 G614PP (2025) experiences a 36-second kernel boot delay caused by `acpi_gpio_handle_deferred_request_irqs()` hanging during late_initcall_sync. The workaround is `gpiolib_acpi.run_edge_events_on_boot=0`.
> 
> System Information
> ------------------
> 
> -   Hardware: ASUS ROG Strix G16 G614PP_G614PP
> -   DMI Product: ROG Strix G16 G614PP_G614PP
> -   DMI Vendor: ASUSTeK COMPUTER INC.
> -   BIOS Version: G614PP.307 (08/14/2025)
> -   CPU: AMD Ryzen (Strix Point)
> -   GPU: NVIDIA (with nvidia-open 580.105.08)
> -   Distribution: EndeavourOS
> -   Kernel: 6.17.9 (also reproduced on zem)
> -   Bootloader: systemd-boot with dracut
> 
> Problem Description
> -------------------
> 
> The system takes approximately 56 seconds to boot, with 37.8 seconds spent in the kernel phase. Using `initcall_debug`, the culprit was identified as:
> 
>      [    1.739645] calling  acpi_gpio_handle_deferred_request_irqs+0x0/0x40 @ 1
>      [   38.077788] initcall acpi_gpio_handle_deferred_request_irqs+0x0/0x40 returned 0 after 36338138 usecs
> 
> The kernel goes completely silent between ~2 seconds and ~38 seconds (no dmesg output during this period):
> 
>      [    2.607764] clocksource: Switched to clocksource tsc
>      [   37.828217] clk: Disabling unused clocks
> 
> Windows boots normally on the same hardware, indicating this is a Linux-specific ACPI handling issue.
> 
> systemd-analyze output
> ----------------------
> 
>      Startup finished in 8.593s (firmware) + 1.273s (loader) + 37.877s (kernel) + 4.645s (initrd) + 3.831s (userspace) = 56.221s
> 
> ACPI Errors During Boot
> -----------------------
> 
> The following ACPI errors appear in dmesg (though these complete quickly and are not the direct cause of the delay):
> 
>      ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.GPP2], AE_NOT_FOUND (20250404/dswload2-162)
>      ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20250404/psobject-220)
>      ACPI: Skipping parse of AML opcode: Scope (0x0010)
>      ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - \_SB_.PCI0.GPP7.UP00.DP00.U4UP.U4P3.UHI0 (20250404/dspkginit-438)
>      ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
> 
> GPIO-related dmesg output
> -------------------------
> 
>      [    0.257981] calling  pinctrl_init+0x0/0xc0 @ 1
>      [    0.257982] pinctrl core: initialized pinctrl subsystem
>      [    0.257994] initcall pinctrl_init+0x0/0xc0 returned 0 after 0 usecs
>      [    1.612848] calling  amd_gpio_driver_init+0x0/0x20 @ 1
>      [    1.613779] initcall amd_gpio_driver_init+0x0/0x20 returned 0 after 930 usecs
>      [    1.739645] calling  acpi_gpio_handle_deferred_request_irqs+0x0/0x40 @ 1
>      [   38.077788] initcall acpi_gpio_handle_deferred_request_irqs+0x0/0x40 returned 0 after 36338138 usecs
> 
> Workaround
> ----------
> 
> Adding the following kernel parameter resolves the issue and reduces boot time to ~10 seconds:
> 
>      gpiolib_acpi.run_edge_events_on_boot=0
> 
> Impact of Workaround
> --------------------
> 
> Testing with the workaround applied, no obvious regressions have been observed:
> 
> -   Lid switch works
> -   Power button works
> -   Keyboard function keys work
> -   Sleep/wake works
> 
> Long-term, a DMI quirk entry for this device would be preferable.
> 
> Suggested Fix
> -------------
> 
> Add a DMI quirk entry to `drivers/gpio/gpiolib-acpi.c` for the ASUS ROG Strix G16 G614PP, though it may be needed on other ROG/Strix/Zephyrus models from 2021-2025.
> 
> Steps to Reproduce
> ------------------
> 
> 1.  Install Linux on ASUS ROG Strix G16 G614PP (2025)
> 2.  Boot without `gpiolib_acpi.run_edge_events_on_boot=0`
> 3.  Observe ~40 second boot time with `systemd-analyze time`
> 4.  Add `initcall_debug` to kernel parameters and observe the 36-second hang in `acpi_gpio_handle_deferred_request_ir`
> 
> 
> 

The behavior to run these interrupts at boot was introduced by:

https://git.kernel.org/torvalds/c/ca876c7483b6

Have you already analyzed the ACPI tables to understand where the large 
delay is coming from?  I think before jumping into the quirk like the 
LLM you used suggests we should understand which deferred interrupt 
handler is causing the issue to make sure we're not masking another issue.

Could you please attach the acpidump to a kernel Bugzilla to look over?