[PATCH] gpiolib: acpi: Disable edge events on boot on ASUS ROG Strix G16 G614PP

[PATCH] gpiolib: acpi: Disable edge events on boot on ASUS ROG Strix G16 G614PP

[francesco.lauritano1]

From: Francesco Lauritano <francesco.lauritano1@protonmail.com>

On the ASUS ROG Strix G16 G614PP (2025), the kernel can stall for ~36
seconds during late init in acpi_gpio_handle_deferred_request_irqs().

Booting with gpiolib_acpi.run_edge_events_on_boot=0 avoids the stall and
restores normal boot times.

Add a DMI quirk to disable edge events on boot by default on this model.

Link: https://lore.kernel.org/platform-driver-x86/6iFCwGH2vssb7NRUTWGpkubGMNbgIlBHSz40z8ZsezjxngXpoiiRiJaijviNvhiDAGIr43bfUmdxLmxYoHDjyft4DgwFc3Pnu5hzPguTa0s=@protonmail.com/

Tested-by: Francesco Lauritano <francesco.lauritano1@protonmail.com>
Signed-off-by: Francesco Lauritano <francesco.lauritano1@protonmail.com>
---
 drivers/gpio/gpiolib-acpi-quirks.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
index a0116f004..763dd3cbd 100644
--- a/drivers/gpio/gpiolib-acpi-quirks.c
+++ b/drivers/gpio/gpiolib-acpi-quirks.c
@@ -370,6 +370,22 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
 			.ignore_wake = "ASCP1A00:00@8",
 		},
 	},
+	{
+		/*
+		 * The ASUS ROG Strix G16 (2025) has a buggy ACPI GPIO configuration
+		 * causing acpi_gpio_handle_deferred_request_irqs() to stall for
+		 * ~36 seconds during boot.
+		 *
+		 * Found in BIOS G614PP.307.
+		 */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16 G614PP_G614PP"),
+		},
+		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
+			.no_edge_events_on_boot = true,
+		},
+	},
 	{
 		/*
 		 * Spurious wakeups, likely from touchpad controller
-- 
2.52.0

Re: [PATCH] gpiolib: acpi: Disable edge events on boot on ASUS ROG Strix G16 G614PP

[Mika Westerberg]

Hi,

On Wed, Dec 17, 2025 at 12:01:52PM +0000, francesco.lauritano1@protonmail.com wrote:
> From: Francesco Lauritano <francesco.lauritano1@protonmail.com>
> 
> On the ASUS ROG Strix G16 G614PP (2025), the kernel can stall for ~36
> seconds during late init in acpi_gpio_handle_deferred_request_irqs().
> 
> Booting with gpiolib_acpi.run_edge_events_on_boot=0 avoids the stall and
> restores normal boot times.

Okay but it might just accidentally "work" and hides the real issue. Doing
things like this blindly might end up breaking something that relies on
that _AEI.

Can you post full dmesg and acpipdump somewhere so we can try to figure out
what is going on?

> Add a DMI quirk to disable edge events on boot by default on this model.
> 
> Link: https://lore.kernel.org/platform-driver-x86/6iFCwGH2vssb7NRUTWGpkubGMNbgIlBHSz40z8ZsezjxngXpoiiRiJaijviNvhiDAGIr43bfUmdxLmxYoHDjyft4DgwFc3Pnu5hzPguTa0s=@protonmail.com/
> 
> Tested-by: Francesco Lauritano <francesco.lauritano1@protonmail.com>
> Signed-off-by: Francesco Lauritano <francesco.lauritano1@protonmail.com>
> ---
>  drivers/gpio/gpiolib-acpi-quirks.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
> index a0116f004..763dd3cbd 100644
> --- a/drivers/gpio/gpiolib-acpi-quirks.c
> +++ b/drivers/gpio/gpiolib-acpi-quirks.c
> @@ -370,6 +370,22 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
>  			.ignore_wake = "ASCP1A00:00@8",
>  		},
>  	},
> +	{
> +		/*
> +		 * The ASUS ROG Strix G16 (2025) has a buggy ACPI GPIO configuration
> +		 * causing acpi_gpio_handle_deferred_request_irqs() to stall for
> +		 * ~36 seconds during boot.
> +		 *
> +		 * Found in BIOS G614PP.307.
> +		 */
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16 G614PP_G614PP"),
> +		},
> +		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
> +			.no_edge_events_on_boot = true,
> +		},
> +	},
>  	{
>  		/*
>  		 * Spurious wakeups, likely from touchpad controller
> -- 
> 2.52.0
> 

Re: [PATCH] gpiolib: acpi: Disable edge events on boot on ASUS ROG Strix G16 G614PP

[Francesco Lauritano]

Hi Mika,

Thanks for looking into this. Happy to dig deeper.

Here are the requested dumps (boot with initcall_debug, no workaround):

dmesg: https://gist.github.com/kylan11/63ec3ec319cd6bcaa043fa0b1366965a

acpidump: https://gist.githubusercontent.com/kylan11/7956bbf75714265107f0886f6ed2a381/raw/1614845eb1dc6ab7e2effb6fe56b585a746abe4f/gistfile1.txt

Some quick notes:
- The AMD GPIO controller probes successfully (LINE 2077)

- The hang occurs in the deferred IRQ handler (line 2960)

- There are some ACPI errors around 0.285373 to 0.289806, though they complete quickly

- After the 36-second hang, everything else initializes normally. 
touchpad, audio, wifi, nvidia GPU all work fine.

The ACPI tables show there's a _AEI method under \_SB_GPIO. Not sure if those
unresolved GPP2/GPP7 references are related to what's blocking the deferred
IRQ handler, or if it's something else entirely.

Let me know if you need anything else or want me to test something specific.

Thanks,
Francesco


On Wednesday, December 17th, 2025 at 2:08 PM, Mika Westerberg <mika.westerberg@linux.intel.com> wrote:

> Hi,
> 
> On Wed, Dec 17, 2025 at 12:01:52PM +0000, francesco.lauritano1@protonmail.com wrote:
> 
> > From: Francesco Lauritano francesco.lauritano1@protonmail.com
> > 
> > On the ASUS ROG Strix G16 G614PP (2025), the kernel can stall for ~36
> > seconds during late init in acpi_gpio_handle_deferred_request_irqs().
> > 
> > Booting with gpiolib_acpi.run_edge_events_on_boot=0 avoids the stall and
> > restores normal boot times.
> 
> 
> Okay but it might just accidentally "work" and hides the real issue. Doing
> things like this blindly might end up breaking something that relies on
> that _AEI.
> 
> Can you post full dmesg and acpipdump somewhere so we can try to figure out
> what is going on?
> 
> > Add a DMI quirk to disable edge events on boot by default on this model.
> > 
> > Link: https://lore.kernel.org/platform-driver-x86/6iFCwGH2vssb7NRUTWGpkubGMNbgIlBHSz40z8ZsezjxngXpoiiRiJaijviNvhiDAGIr43bfUmdxLmxYoHDjyft4DgwFc3Pnu5hzPguTa0s=@protonmail.com/
> > 
> > Tested-by: Francesco Lauritano francesco.lauritano1@protonmail.com
> > Signed-off-by: Francesco Lauritano francesco.lauritano1@protonmail.com
> > ---
> > drivers/gpio/gpiolib-acpi-quirks.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> > 
> > diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
> > index a0116f004..763dd3cbd 100644
> > --- a/drivers/gpio/gpiolib-acpi-quirks.c
> > +++ b/drivers/gpio/gpiolib-acpi-quirks.c
> > @@ -370,6 +370,22 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
> > .ignore_wake = "ASCP1A00:00@8",
> > },
> > },
> > + {
> > + /*
> > + * The ASUS ROG Strix G16 (2025) has a buggy ACPI GPIO configuration
> > + * causing acpi_gpio_handle_deferred_request_irqs() to stall for
> > + * ~36 seconds during boot.
> > + *
> > + * Found in BIOS G614PP.307.
> > + /
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16 G614PP_G614PP"),
> > + },
> > + .driver_data = &(struct acpi_gpiolib_dmi_quirk) {
> > + .no_edge_events_on_boot = true,
> > + },
> > + },
> > {
> > /
> > * Spurious wakeups, likely from touchpad controller
> > --
> > 2.52.0

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

[Mario Limonciello]

++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?

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

[Francesco Lauritano]

Hi Mario,

+Mika (sent him the dumps earlier)

dmesg: https://gist.github.com/kylan11/63ec3ec319cd6bcaa043fa0b1366965a

acpidump: https://gist.githubusercontent.com/kylan11/7956bbf75714265107f0886f6ed2a381/raw/1614845eb1dc6ab7e2effb6fe56b585a746abe4f/gistfile1.txt

Agreed, got way too excited, still learning. Did some more digging.

The _AEI defines 5 GPIO interrupts. Narrowed it down to two:

gpiolib_acpi.ignore_interrupt=AMDI0030:00@21,AMDI0030:00@24

This fixes the delay. Pins 0x15 and 0x18 both call: \_SB.PCI0.SBRG.HNC0() 
that method stalls around 18s per pin. Ignoring just one cuts the delay in half (32s vs 56s boot), so both are hitting the same broken path.

Also found another similar report on a G614PR (same chassis, different GPU): https://rog-forum.asus.com/t5/rog-strix-series/rog-strix-g614pr-long-boot-time-on-linux/m-p/1112775

Happy to test patches.

(Re: LLM - used it to format the report, debugging was done the old fashioned way :) )

Francesco



On Wednesday, December 17th, 2025 at 3:23 PM, Mario Limonciello <superm1@kernel.org> wrote:

> ++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?

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

[Francesco Lauritano]

On Wednesday, December 17th, 2025 at 4:12 PM, Francesco Lauritano <francesco.lauritano1@protonmail.com> wrote:

> The _AEI defines 5 GPIO interrupts. Narrowed it down to two:
> 
> gpiolib_acpi.ignore_interrupt=AMDI0030:00@21,AMDI0030:00@24
> 
> This fixes the delay. Pins 0x15 and 0x18 both call: \_SB.PCI0.SBRG.HNC0()

Traced it further. HNC0(pin, 0) takes the Else branch and calls:
ATKM(0xC0)
ADTM(Zero)

ADTM calls NOD2(), which is the actual culprit:

While ((Arg0 != RDNT))
{
    If ((Local0 >= 0x0F)) { Break }
    Notify (^^GPP0.PEGP, Arg0)
    Local0++
    Sleep (Local0 * 0x64)
}

It notifies the dGPU and polls RDNT, sleeping 100, 200, ... 1500ms per iteration. 
Max 15 loops = ~12s per pin. GPU doesn't respond at boot so it maxes out.

Two pins, ~12s each, ~24-36s total.

Francesco

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

[Mario Limonciello]

On 12/17/25 10:57 AM, Francesco Lauritano wrote:
> On Wednesday, December 17th, 2025 at 4:12 PM, Francesco Lauritano <francesco.lauritano1@protonmail.com> wrote:
> 
>> The _AEI defines 5 GPIO interrupts. Narrowed it down to two:
>>
>> gpiolib_acpi.ignore_interrupt=AMDI0030:00@21,AMDI0030:00@24
>>
>> This fixes the delay. Pins 0x15 and 0x18 both call: \_SB.PCI0.SBRG.HNC0()
> 
> Traced it further. HNC0(pin, 0) takes the Else branch and calls:
> ATKM(0xC0)
> ADTM(Zero)
> 
> ADTM calls NOD2(), which is the actual culprit:
> 
> While ((Arg0 != RDNT))
> {
>      If ((Local0 >= 0x0F)) { Break }
>      Notify (^^GPP0.PEGP, Arg0)
>      Local0++
>      Sleep (Local0 * 0x64)
> }
> 
> It notifies the dGPU and polls RDNT, sleeping 100, 200, ... 1500ms per iteration.
> Max 15 loops = ~12s per pin. GPU doesn't respond at boot so it maxes out.
> 
> Two pins, ~12s each, ~24-36s total.
> 
> Francesco

Any idea why isn't the dGPU responding?  I would have expected 
https://git.kernel.org/torvalds/c/4d4c10f763d78 sets up policy that it's 
in D0.

Is the dGPU turned off in BIOS or through some reverse engineered 
tool/API or something?

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

[Francesco Lauritano]

On Wednesday, December 17th, 2025 at 7:01 PM, Mario Limonciello <superm1@kernel.org> wrote:

> On 12/17/25 10:57 AM, Francesco Lauritano wrote:
> 
> > On Wednesday, December 17th, 2025 at 4:12 PM, Francesco Lauritano francesco.lauritano1@protonmail.com wrote:
> > 
> > > The _AEI defines 5 GPIO interrupts. Narrowed it down to two:
> > > 
> > > gpiolib_acpi.ignore_interrupt=AMDI0030:00@21,AMDI0030:00@24
> > > 
> > > This fixes the delay. Pins 0x15 and 0x18 both call: \_SB.PCI0.SBRG.HNC0()
> > 
> > Traced it further. HNC0(pin, 0) takes the Else branch and calls:
> > ATKM(0xC0)
> > ADTM(Zero)
> > 
> > ADTM calls NOD2(), which is the actual culprit:
> > 
> > While ((Arg0 != RDNT))
> > {
> > If ((Local0 >= 0x0F)) { Break }
> > Notify (^^GPP0.PEGP, Arg0)
> > Local0++
> > Sleep (Local0 * 0x64)
> > }
> > 
> > It notifies the dGPU and polls RDNT, sleeping 100, 200, ... 1500ms per iteration.
> > Max 15 loops = ~12s per pin. GPU doesn't respond at boot so it maxes out.
> > 
> > Two pins, ~12s each, ~24-36s total.
> > 
> > Francesco
> 
> 
> Any idea why isn't the dGPU responding? I would have expected
> https://git.kernel.org/torvalds/c/4d4c10f763d78 sets up policy that it's
> in D0.
> 
> Is the dGPU turned off in BIOS or through some reverse engineered
> tool/API or something?

dmesg without the workaround:
[    1.005184] pci 0000:01:00.0: PME# supported from D0 D3hot
[    1.288811] pci 0000:01:00.0: vgaarb: VGA device added
[   38.250139] nvidia: loading out-of-tree module taints kernel.
[   38.369358] nvidia 0000:01:00.0: enabling device (0000 -> 0003)
[   39.744421] NVRM: GPS ACPI DSM called before _acpiDsmSupportedFuncCacheInit

GPU is in D0 from 1.0s. nvidia loads at 38.2s after the GPIO hang completes.

No weird tools/APIs besides userspace utils (asusctl/supergfxctl). 

No changes to BIOS factory defaults other than disabling Fast Boot.
dGPU is active, Display Mode is Dynamic (hybrid).

Traced RDNT - it's set by GPS function 19 in the ACPI tables:
Case (0x13)
{
    Debug = "GPS fun 19"
    \_SB.PCI0.SBRG.RDNT = (Local1 + 0xD1)
}

As far as I can understand GPIO initcall blocks at late_initcall_sync, preventing nvidia 
from loading in time to respond. Based on the timing, GPU is awake but nothing can 
register a handler while kernel is stuck at NOD2 polling loop.

Thanks,
Francesco

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

[Mika Westerberg]

On Wed, Dec 17, 2025 at 07:19:56PM +0000, Francesco Lauritano wrote:
> On Wednesday, December 17th, 2025 at 7:01 PM, Mario Limonciello <superm1@kernel.org> wrote:
> 
> > On 12/17/25 10:57 AM, Francesco Lauritano wrote:
> > 
> > > On Wednesday, December 17th, 2025 at 4:12 PM, Francesco Lauritano francesco.lauritano1@protonmail.com wrote:
> > > 
> > > > The _AEI defines 5 GPIO interrupts. Narrowed it down to two:
> > > > 
> > > > gpiolib_acpi.ignore_interrupt=AMDI0030:00@21,AMDI0030:00@24
> > > > 
> > > > This fixes the delay. Pins 0x15 and 0x18 both call: \_SB.PCI0.SBRG.HNC0()
> > > 
> > > Traced it further. HNC0(pin, 0) takes the Else branch and calls:
> > > ATKM(0xC0)
> > > ADTM(Zero)
> > > 
> > > ADTM calls NOD2(), which is the actual culprit:
> > > 
> > > While ((Arg0 != RDNT))
> > > {
> > > If ((Local0 >= 0x0F)) { Break }
> > > Notify (^^GPP0.PEGP, Arg0)
> > > Local0++
> > > Sleep (Local0 * 0x64)
> > > }
> > > 
> > > It notifies the dGPU and polls RDNT, sleeping 100, 200, ... 1500ms per iteration.
> > > Max 15 loops = ~12s per pin. GPU doesn't respond at boot so it maxes out.
> > > 
> > > Two pins, ~12s each, ~24-36s total.
> > > 
> > > Francesco
> > 
> > 
> > Any idea why isn't the dGPU responding? I would have expected
> > https://git.kernel.org/torvalds/c/4d4c10f763d78 sets up policy that it's
> > in D0.
> > 
> > Is the dGPU turned off in BIOS or through some reverse engineered
> > tool/API or something?
> 
> dmesg without the workaround:
> [    1.005184] pci 0000:01:00.0: PME# supported from D0 D3hot
> [    1.288811] pci 0000:01:00.0: vgaarb: VGA device added
> [   38.250139] nvidia: loading out-of-tree module taints kernel.
> [   38.369358] nvidia 0000:01:00.0: enabling device (0000 -> 0003)
> [   39.744421] NVRM: GPS ACPI DSM called before _acpiDsmSupportedFuncCacheInit
> 
> GPU is in D0 from 1.0s. nvidia loads at 38.2s after the GPIO hang completes.
> 
> No weird tools/APIs besides userspace utils (asusctl/supergfxctl). 
> 
> No changes to BIOS factory defaults other than disabling Fast Boot.
> dGPU is active, Display Mode is Dynamic (hybrid).
> 
> Traced RDNT - it's set by GPS function 19 in the ACPI tables:
> Case (0x13)
> {
>     Debug = "GPS fun 19"
>     \_SB.PCI0.SBRG.RDNT = (Local1 + 0xD1)
> }
> 
> As far as I can understand GPIO initcall blocks at late_initcall_sync, preventing nvidia 
> from loading in time to respond. Based on the timing, GPU is awake but nothing can 
> register a handler while kernel is stuck at NOD2 polling loop.

I wonder if you could try with the nouveau driver so that it's built-in to
the kernel proper? Then it should be ready at the time these events
trigger.

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

[Hans de Goede]

Hi,

On 18-Dec-25 07:39, Mika Westerberg wrote:
> On Wed, Dec 17, 2025 at 07:19:56PM +0000, Francesco Lauritano wrote:
>> On Wednesday, December 17th, 2025 at 7:01 PM, Mario Limonciello <superm1@kernel.org> wrote:
>>
>>> On 12/17/25 10:57 AM, Francesco Lauritano wrote:
>>>
>>>> On Wednesday, December 17th, 2025 at 4:12 PM, Francesco Lauritano francesco.lauritano1@protonmail.com wrote:
>>>>
>>>>> The _AEI defines 5 GPIO interrupts. Narrowed it down to two:
>>>>>
>>>>> gpiolib_acpi.ignore_interrupt=AMDI0030:00@21,AMDI0030:00@24
>>>>>
>>>>> This fixes the delay. Pins 0x15 and 0x18 both call: \_SB.PCI0.SBRG.HNC0()
>>>>
>>>> Traced it further. HNC0(pin, 0) takes the Else branch and calls:
>>>> ATKM(0xC0)
>>>> ADTM(Zero)
>>>>
>>>> ADTM calls NOD2(), which is the actual culprit:
>>>>
>>>> While ((Arg0 != RDNT))
>>>> {
>>>> If ((Local0 >= 0x0F)) { Break }
>>>> Notify (^^GPP0.PEGP, Arg0)
>>>> Local0++
>>>> Sleep (Local0 * 0x64)
>>>> }
>>>>
>>>> It notifies the dGPU and polls RDNT, sleeping 100, 200, ... 1500ms per iteration.
>>>> Max 15 loops = ~12s per pin. GPU doesn't respond at boot so it maxes out.
>>>>
>>>> Two pins, ~12s each, ~24-36s total.
>>>>
>>>> Francesco
>>>
>>>
>>> Any idea why isn't the dGPU responding? I would have expected
>>> https://git.kernel.org/torvalds/c/4d4c10f763d78 sets up policy that it's
>>> in D0.
>>>
>>> Is the dGPU turned off in BIOS or through some reverse engineered
>>> tool/API or something?
>>
>> dmesg without the workaround:
>> [    1.005184] pci 0000:01:00.0: PME# supported from D0 D3hot
>> [    1.288811] pci 0000:01:00.0: vgaarb: VGA device added
>> [   38.250139] nvidia: loading out-of-tree module taints kernel.
>> [   38.369358] nvidia 0000:01:00.0: enabling device (0000 -> 0003)
>> [   39.744421] NVRM: GPS ACPI DSM called before _acpiDsmSupportedFuncCacheInit
>>
>> GPU is in D0 from 1.0s. nvidia loads at 38.2s after the GPIO hang completes.
>>
>> No weird tools/APIs besides userspace utils (asusctl/supergfxctl). 
>>
>> No changes to BIOS factory defaults other than disabling Fast Boot.
>> dGPU is active, Display Mode is Dynamic (hybrid).
>>
>> Traced RDNT - it's set by GPS function 19 in the ACPI tables:
>> Case (0x13)
>> {
>>     Debug = "GPS fun 19"
>>     \_SB.PCI0.SBRG.RDNT = (Local1 + 0xD1)
>> }
>>
>> As far as I can understand GPIO initcall blocks at late_initcall_sync, preventing nvidia 
>> from loading in time to respond. Based on the timing, GPU is awake but nothing can 
>> register a handler while kernel is stuck at NOD2 polling loop.
> 
> I wonder if you could try with the nouveau driver so that it's built-in to
> the kernel proper? Then it should be ready at the time these events
> trigger.

That is not really a workable solution though.

I think either we need to DMI quirk the 2 models with this issue;

Or perhaps it is time to rethink the whole running of edge handlers
on boot thing.

Based on the existing DMI quirks, which fix some much more serious
breakage (breaking HDMI out port DCC, causing a USB-A port to not
get 5V out) I would say it is safe to say that Windows does not do
this.

As for the original reasons mentioned in the commit message
introducing this:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ca876c7483b6

The BYT tabled ID pin handling has been sowewhat controversial. Some
people actually liked that many BYT BIOSes leave the USB data pins in
host mode even when a charger is connected as this allows using
a USB-otg-charging HUB charging and being in host mode at the same time.

That just leaves the original LID handling on microsoft surface 3
tablets case as somewhat of a problem.

But we can just pick an initial LID state of LID not closed there,
booting up with the LID closed is unusual and if done, the user
likely does *not* want to suspend right away which would happen
when reporting the LID as closed.

I still have a Surface 3 and I can check if that is the default and
if not this could be fixed with a quirk in the ACPI LID handling code.

TL;DR: I think this is a case where we can fix things by ripping
out a whole bunch of code + quirks and stop running edge event
handlers on boot.

Regards,

Hans

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

[Mika Westerberg]

On Thu, Dec 18, 2025 at 11:33:14AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 18-Dec-25 07:39, Mika Westerberg wrote:
> > On Wed, Dec 17, 2025 at 07:19:56PM +0000, Francesco Lauritano wrote:
> >> On Wednesday, December 17th, 2025 at 7:01 PM, Mario Limonciello <superm1@kernel.org> wrote:
> >>
> >>> On 12/17/25 10:57 AM, Francesco Lauritano wrote:
> >>>
> >>>> On Wednesday, December 17th, 2025 at 4:12 PM, Francesco Lauritano francesco.lauritano1@protonmail.com wrote:
> >>>>
> >>>>> The _AEI defines 5 GPIO interrupts. Narrowed it down to two:
> >>>>>
> >>>>> gpiolib_acpi.ignore_interrupt=AMDI0030:00@21,AMDI0030:00@24
> >>>>>
> >>>>> This fixes the delay. Pins 0x15 and 0x18 both call: \_SB.PCI0.SBRG.HNC0()
> >>>>
> >>>> Traced it further. HNC0(pin, 0) takes the Else branch and calls:
> >>>> ATKM(0xC0)
> >>>> ADTM(Zero)
> >>>>
> >>>> ADTM calls NOD2(), which is the actual culprit:
> >>>>
> >>>> While ((Arg0 != RDNT))
> >>>> {
> >>>> If ((Local0 >= 0x0F)) { Break }
> >>>> Notify (^^GPP0.PEGP, Arg0)
> >>>> Local0++
> >>>> Sleep (Local0 * 0x64)
> >>>> }
> >>>>
> >>>> It notifies the dGPU and polls RDNT, sleeping 100, 200, ... 1500ms per iteration.
> >>>> Max 15 loops = ~12s per pin. GPU doesn't respond at boot so it maxes out.
> >>>>
> >>>> Two pins, ~12s each, ~24-36s total.
> >>>>
> >>>> Francesco
> >>>
> >>>
> >>> Any idea why isn't the dGPU responding? I would have expected
> >>> https://git.kernel.org/torvalds/c/4d4c10f763d78 sets up policy that it's
> >>> in D0.
> >>>
> >>> Is the dGPU turned off in BIOS or through some reverse engineered
> >>> tool/API or something?
> >>
> >> dmesg without the workaround:
> >> [    1.005184] pci 0000:01:00.0: PME# supported from D0 D3hot
> >> [    1.288811] pci 0000:01:00.0: vgaarb: VGA device added
> >> [   38.250139] nvidia: loading out-of-tree module taints kernel.
> >> [   38.369358] nvidia 0000:01:00.0: enabling device (0000 -> 0003)
> >> [   39.744421] NVRM: GPS ACPI DSM called before _acpiDsmSupportedFuncCacheInit
> >>
> >> GPU is in D0 from 1.0s. nvidia loads at 38.2s after the GPIO hang completes.
> >>
> >> No weird tools/APIs besides userspace utils (asusctl/supergfxctl). 
> >>
> >> No changes to BIOS factory defaults other than disabling Fast Boot.
> >> dGPU is active, Display Mode is Dynamic (hybrid).
> >>
> >> Traced RDNT - it's set by GPS function 19 in the ACPI tables:
> >> Case (0x13)
> >> {
> >>     Debug = "GPS fun 19"
> >>     \_SB.PCI0.SBRG.RDNT = (Local1 + 0xD1)
> >> }
> >>
> >> As far as I can understand GPIO initcall blocks at late_initcall_sync, preventing nvidia 
> >> from loading in time to respond. Based on the timing, GPU is awake but nothing can 
> >> register a handler while kernel is stuck at NOD2 polling loop.
> > 
> > I wonder if you could try with the nouveau driver so that it's built-in to
> > the kernel proper? Then it should be ready at the time these events
> > trigger.
> 
> That is not really a workable solution though.

Yeah, I did not meant it to be the "solution" rather just to check whether
it is related if the GPU driver is there or not. You cannot build the
proprietary driver into the kernel so that's why I suggested the
open-source one.

Re: [PATCH] gpiolib: acpi: Disable edge events on boot on ASUS ROG Strix G16 G614PP

[Andy Shevchenko]

On Wed, Dec 17, 2025 at 02:01:51PM +0000, Francesco Lauritano wrote:
> 
> Thanks for looking into this. Happy to dig deeper.
> 
> Here are the requested dumps (boot with initcall_debug, no workaround):

(Usually we also use `ignore_loglevel`, but I think dmesg should have it anyway.)

> dmesg: https://gist.github.com/kylan11/63ec3ec319cd6bcaa043fa0b1366965a
> 
> acpidump: https://gist.githubusercontent.com/kylan11/7956bbf75714265107f0886f6ed2a381/raw/1614845eb1dc6ab7e2effb6fe56b585a746abe4f/gistfile1.txt

> Some quick notes:
> - The AMD GPIO controller probes successfully (LINE 2077)
> 
> - The hang occurs in the deferred IRQ handler (line 2960)
> 
> - There are some ACPI errors around 0.285373 to 0.289806, though they complete quickly

This looks like related to USB4 (thubderbolt) dock? Mika, does it look familiar?

> - After the 36-second hang, everything else initializes normally.
> touchpad, audio, wifi, nvidia GPU all work fine.
> 
> The ACPI tables show there's a _AEI method under \_SB_GPIO. Not sure if those
> unresolved GPP2/GPP7 references are related to what's blocking the deferred
> IRQ handler, or if it's something else entirely.
> 
> Let me know if you need anything else or want me to test something specific.
> 
> On Wednesday, December 17th, 2025 at 2:08 PM, Mika Westerberg <mika.westerberg@linux.intel.com> wrote:
> > On Wed, Dec 17, 2025 at 12:01:52PM +0000, francesco.lauritano1@protonmail.com wrote:
> > 
> > > On the ASUS ROG Strix G16 G614PP (2025), the kernel can stall for ~36
> > > seconds during late init in acpi_gpio_handle_deferred_request_irqs().
> > > 
> > > Booting with gpiolib_acpi.run_edge_events_on_boot=0 avoids the stall and
> > > restores normal boot times.
> > 
> > Okay but it might just accidentally "work" and hides the real issue. Doing
> > things like this blindly might end up breaking something that relies on
> > that _AEI.
> > 
> > Can you post full dmesg and acpipdump somewhere so we can try to figure out
> > what is going on?

> > > Link: https://lore.kernel.org/platform-driver-x86/6iFCwGH2vssb7NRUTWGpkubGMNbgIlBHSz40z8ZsezjxngXpoiiRiJaijviNvhiDAGIr43bfUmdxLmxYoHDjyft4DgwFc3Pnu5hzPguTa0s=@protonmail.com/

Not sure what this means. Maybe better tag like Closes should be used?

> > > Tested-by: Francesco Lauritano francesco.lauritano1@protonmail.com

This is implied that the author of the patch tested it before sending.

> > > Signed-off-by: Francesco Lauritano francesco.lauritano1@protonmail.com

-- 
With Best Regards,
Andy Shevchenko

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

[Marco Scardovi]

On 12/18/25 11:38, Mika Westerberg wrote:
> On Thu, Dec 18, 2025 at 11:33:14AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 18-Dec-25 07:39, Mika Westerberg wrote:
>>> On Wed, Dec 17, 2025 at 07:19:56PM +0000, Francesco Lauritano wrote:
>>>> On Wednesday, December 17th, 2025 at 7:01 PM, Mario Limonciello <superm1@kernel.org> wrote:
>>>>
>>>>> On 12/17/25 10:57 AM, Francesco Lauritano wrote:
>>>>>
>>>>>> On Wednesday, December 17th, 2025 at 4:12 PM, Francesco Lauritano francesco.lauritano1@protonmail.com wrote:
>>>>>>
>>>>>>> The _AEI defines 5 GPIO interrupts. Narrowed it down to two:
>>>>>>>
>>>>>>> gpiolib_acpi.ignore_interrupt=AMDI0030:00@21,AMDI0030:00@24
>>>>>>>
>>>>>>> This fixes the delay. Pins 0x15 and 0x18 both call: \_SB.PCI0.SBRG.HNC0()
>>>>>> Traced it further. HNC0(pin, 0) takes the Else branch and calls:
>>>>>> ATKM(0xC0)
>>>>>> ADTM(Zero)
>>>>>>
>>>>>> ADTM calls NOD2(), which is the actual culprit:
>>>>>>
>>>>>> While ((Arg0 != RDNT))
>>>>>> {
>>>>>> If ((Local0 >= 0x0F)) { Break }
>>>>>> Notify (^^GPP0.PEGP, Arg0)
>>>>>> Local0++
>>>>>> Sleep (Local0 * 0x64)
>>>>>> }
>>>>>>
>>>>>> It notifies the dGPU and polls RDNT, sleeping 100, 200, ... 1500ms per iteration.
>>>>>> Max 15 loops = ~12s per pin. GPU doesn't respond at boot so it maxes out.
>>>>>>
>>>>>> Two pins, ~12s each, ~24-36s total.
>>>>>>
>>>>>> Francesco
>>>>>
>>>>> Any idea why isn't the dGPU responding? I would have expected
>>>>> https://git.kernel.org/torvalds/c/4d4c10f763d78 sets up policy that it's
>>>>> in D0.
>>>>>
>>>>> Is the dGPU turned off in BIOS or through some reverse engineered
>>>>> tool/API or something?
>>>> dmesg without the workaround:
>>>> [    1.005184] pci 0000:01:00.0: PME# supported from D0 D3hot
>>>> [    1.288811] pci 0000:01:00.0: vgaarb: VGA device added
>>>> [   38.250139] nvidia: loading out-of-tree module taints kernel.
>>>> [   38.369358] nvidia 0000:01:00.0: enabling device (0000 -> 0003)
>>>> [   39.744421] NVRM: GPS ACPI DSM called before _acpiDsmSupportedFuncCacheInit
>>>>
>>>> GPU is in D0 from 1.0s. nvidia loads at 38.2s after the GPIO hang completes.
>>>>
>>>> No weird tools/APIs besides userspace utils (asusctl/supergfxctl).
>>>>
>>>> No changes to BIOS factory defaults other than disabling Fast Boot.
>>>> dGPU is active, Display Mode is Dynamic (hybrid).
>>>>
>>>> Traced RDNT - it's set by GPS function 19 in the ACPI tables:
>>>> Case (0x13)
>>>> {
>>>>      Debug = "GPS fun 19"
>>>>      \_SB.PCI0.SBRG.RDNT = (Local1 + 0xD1)
>>>> }
>>>>
>>>> As far as I can understand GPIO initcall blocks at late_initcall_sync, preventing nvidia
>>>> from loading in time to respond. Based on the timing, GPU is awake but nothing can
>>>> register a handler while kernel is stuck at NOD2 polling loop.
>>> I wonder if you could try with the nouveau driver so that it's built-in to
>>> the kernel proper? Then it should be ready at the time these events
>>> trigger.
>> That is not really a workable solution though.
> Yeah, I did not meant it to be the "solution" rather just to check whether
> it is related if the GPU driver is there or not. You cannot build the
> proprietary driver into the kernel so that's why I suggested the
> open-source one.

Hi Everyone,

I would start saying sorry for the necrobump. I faced the same problem 
on my G614PR and fixed the same way as Francesco.

Do you happen to know if there is any news about this? I'm currently on 
CachyOS with kernel 7.0 and noticed it behaves the same way as 6.19.

I'm on to try patches or provide more infos if needed, even if I have to 
admit I know Linux but not that deeply.

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

[Mika Westerberg]

Hi,

On Wed, Apr 22, 2026 at 09:51:01AM +0200, Marco Scardovi wrote:
> 
> On 12/18/25 11:38, Mika Westerberg wrote:
> > On Thu, Dec 18, 2025 at 11:33:14AM +0100, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 18-Dec-25 07:39, Mika Westerberg wrote:
> > > > On Wed, Dec 17, 2025 at 07:19:56PM +0000, Francesco Lauritano wrote:
> > > > > On Wednesday, December 17th, 2025 at 7:01 PM, Mario Limonciello <superm1@kernel.org> wrote:
> > > > > 
> > > > > > On 12/17/25 10:57 AM, Francesco Lauritano wrote:
> > > > > > 
> > > > > > > On Wednesday, December 17th, 2025 at 4:12 PM, Francesco Lauritano francesco.lauritano1@protonmail.com wrote:
> > > > > > > 
> > > > > > > > The _AEI defines 5 GPIO interrupts. Narrowed it down to two:
> > > > > > > > 
> > > > > > > > gpiolib_acpi.ignore_interrupt=AMDI0030:00@21,AMDI0030:00@24
> > > > > > > > 
> > > > > > > > This fixes the delay. Pins 0x15 and 0x18 both call: \_SB.PCI0.SBRG.HNC0()
> > > > > > > Traced it further. HNC0(pin, 0) takes the Else branch and calls:
> > > > > > > ATKM(0xC0)
> > > > > > > ADTM(Zero)
> > > > > > > 
> > > > > > > ADTM calls NOD2(), which is the actual culprit:
> > > > > > > 
> > > > > > > While ((Arg0 != RDNT))
> > > > > > > {
> > > > > > > If ((Local0 >= 0x0F)) { Break }
> > > > > > > Notify (^^GPP0.PEGP, Arg0)
> > > > > > > Local0++
> > > > > > > Sleep (Local0 * 0x64)
> > > > > > > }
> > > > > > > 
> > > > > > > It notifies the dGPU and polls RDNT, sleeping 100, 200, ... 1500ms per iteration.
> > > > > > > Max 15 loops = ~12s per pin. GPU doesn't respond at boot so it maxes out.
> > > > > > > 
> > > > > > > Two pins, ~12s each, ~24-36s total.
> > > > > > > 
> > > > > > > Francesco
> > > > > > 
> > > > > > Any idea why isn't the dGPU responding? I would have expected
> > > > > > https://git.kernel.org/torvalds/c/4d4c10f763d78 sets up policy that it's
> > > > > > in D0.
> > > > > > 
> > > > > > Is the dGPU turned off in BIOS or through some reverse engineered
> > > > > > tool/API or something?
> > > > > dmesg without the workaround:
> > > > > [    1.005184] pci 0000:01:00.0: PME# supported from D0 D3hot
> > > > > [    1.288811] pci 0000:01:00.0: vgaarb: VGA device added
> > > > > [   38.250139] nvidia: loading out-of-tree module taints kernel.
> > > > > [   38.369358] nvidia 0000:01:00.0: enabling device (0000 -> 0003)
> > > > > [   39.744421] NVRM: GPS ACPI DSM called before _acpiDsmSupportedFuncCacheInit
> > > > > 
> > > > > GPU is in D0 from 1.0s. nvidia loads at 38.2s after the GPIO hang completes.
> > > > > 
> > > > > No weird tools/APIs besides userspace utils (asusctl/supergfxctl).
> > > > > 
> > > > > No changes to BIOS factory defaults other than disabling Fast Boot.
> > > > > dGPU is active, Display Mode is Dynamic (hybrid).
> > > > > 
> > > > > Traced RDNT - it's set by GPS function 19 in the ACPI tables:
> > > > > Case (0x13)
> > > > > {
> > > > >      Debug = "GPS fun 19"
> > > > >      \_SB.PCI0.SBRG.RDNT = (Local1 + 0xD1)
> > > > > }
> > > > > 
> > > > > As far as I can understand GPIO initcall blocks at late_initcall_sync, preventing nvidia
> > > > > from loading in time to respond. Based on the timing, GPU is awake but nothing can
> > > > > register a handler while kernel is stuck at NOD2 polling loop.
> > > > I wonder if you could try with the nouveau driver so that it's built-in to
> > > > the kernel proper? Then it should be ready at the time these events
> > > > trigger.
> > > That is not really a workable solution though.
> > Yeah, I did not meant it to be the "solution" rather just to check whether
> > it is related if the GPU driver is there or not. You cannot build the
> > proprietary driver into the kernel so that's why I suggested the
> > open-source one.
> 
> Hi Everyone,
> 
> I would start saying sorry for the necrobump. I faced the same problem on my
> G614PR and fixed the same way as Francesco.
> 
> Do you happen to know if there is any news about this? I'm currently on
> CachyOS with kernel 7.0 and noticed it behaves the same way as 6.19.
> 
> I'm on to try patches or provide more infos if needed, even if I have to
> admit I know Linux but not that deeply.

As far as I can tell no updates unfortunately. I guess we could go with
slightly updated patch from Francesco, like below that just ignores those
two interrupts. Can you try if that works for you?

This list of devices that suffer from the "edge events on boot" seems to be
growing so maybe we should re-think if that should be enabled for all
systems or limit to the problematic ones (although that list could get big
too ;-))

diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
index a0116f004975..4e60a176ac93 100644
--- a/drivers/gpio/gpiolib-acpi-quirks.c
+++ b/drivers/gpio/gpiolib-acpi-quirks.c
@@ -392,6 +392,23 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
 			.ignore_wake = "VEN_0488:00@355",
 		},
 	},
+	{
+		/*
+		 * The ASUS ROG Strix G16 (2025) ACPI GPIO configuration
+		 * causes acpi_gpio_handle_deferred_request_irqs() to
+		 * stall for ~36 seconds during boot so ignore the two
+		 * interrupts involved.
+		 *
+		 * Found in BIOS G614PP.307.
+		 */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16 G614PP_G614PP"),
+		},
+		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
+			.ignore_interrupt = "AMDI0030:00@21,AMDI0030:00@24",
+		},
+	},
 	{} /* Terminating entry */
 };
 

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

[Marco Scardovi]

On 4/22/26 11:07, Mika Westerberg wrote:
> Hi,
>
> On Wed, Apr 22, 2026 at 09:51:01AM +0200, Marco Scardovi wrote:
>> On 12/18/25 11:38, Mika Westerberg wrote:
>>> On Thu, Dec 18, 2025 at 11:33:14AM +0100, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 18-Dec-25 07:39, Mika Westerberg wrote:
>>>>> On Wed, Dec 17, 2025 at 07:19:56PM +0000, Francesco Lauritano wrote:
>>>>>> On Wednesday, December 17th, 2025 at 7:01 PM, Mario Limonciello <superm1@kernel.org> wrote:
>>>>>>
>>>>>>> On 12/17/25 10:57 AM, Francesco Lauritano wrote:
>>>>>>>
>>>>>>>> On Wednesday, December 17th, 2025 at 4:12 PM, Francesco Lauritano francesco.lauritano1@protonmail.com wrote:
>>>>>>>>
>>>>>>>>> The _AEI defines 5 GPIO interrupts. Narrowed it down to two:
>>>>>>>>>
>>>>>>>>> gpiolib_acpi.ignore_interrupt=AMDI0030:00@21,AMDI0030:00@24
>>>>>>>>>
>>>>>>>>> This fixes the delay. Pins 0x15 and 0x18 both call: \_SB.PCI0.SBRG.HNC0()
>>>>>>>> Traced it further. HNC0(pin, 0) takes the Else branch and calls:
>>>>>>>> ATKM(0xC0)
>>>>>>>> ADTM(Zero)
>>>>>>>>
>>>>>>>> ADTM calls NOD2(), which is the actual culprit:
>>>>>>>>
>>>>>>>> While ((Arg0 != RDNT))
>>>>>>>> {
>>>>>>>> If ((Local0 >= 0x0F)) { Break }
>>>>>>>> Notify (^^GPP0.PEGP, Arg0)
>>>>>>>> Local0++
>>>>>>>> Sleep (Local0 * 0x64)
>>>>>>>> }
>>>>>>>>
>>>>>>>> It notifies the dGPU and polls RDNT, sleeping 100, 200, ... 1500ms per iteration.
>>>>>>>> Max 15 loops = ~12s per pin. GPU doesn't respond at boot so it maxes out.
>>>>>>>>
>>>>>>>> Two pins, ~12s each, ~24-36s total.
>>>>>>>>
>>>>>>>> Francesco
>>>>>>> Any idea why isn't the dGPU responding? I would have expected
>>>>>>> https://git.kernel.org/torvalds/c/4d4c10f763d78 sets up policy that it's
>>>>>>> in D0.
>>>>>>>
>>>>>>> Is the dGPU turned off in BIOS or through some reverse engineered
>>>>>>> tool/API or something?
>>>>>> dmesg without the workaround:
>>>>>> [    1.005184] pci 0000:01:00.0: PME# supported from D0 D3hot
>>>>>> [    1.288811] pci 0000:01:00.0: vgaarb: VGA device added
>>>>>> [   38.250139] nvidia: loading out-of-tree module taints kernel.
>>>>>> [   38.369358] nvidia 0000:01:00.0: enabling device (0000 -> 0003)
>>>>>> [   39.744421] NVRM: GPS ACPI DSM called before _acpiDsmSupportedFuncCacheInit
>>>>>>
>>>>>> GPU is in D0 from 1.0s. nvidia loads at 38.2s after the GPIO hang completes.
>>>>>>
>>>>>> No weird tools/APIs besides userspace utils (asusctl/supergfxctl).
>>>>>>
>>>>>> No changes to BIOS factory defaults other than disabling Fast Boot.
>>>>>> dGPU is active, Display Mode is Dynamic (hybrid).
>>>>>>
>>>>>> Traced RDNT - it's set by GPS function 19 in the ACPI tables:
>>>>>> Case (0x13)
>>>>>> {
>>>>>>       Debug = "GPS fun 19"
>>>>>>       \_SB.PCI0.SBRG.RDNT = (Local1 + 0xD1)
>>>>>> }
>>>>>>
>>>>>> As far as I can understand GPIO initcall blocks at late_initcall_sync, preventing nvidia
>>>>>> from loading in time to respond. Based on the timing, GPU is awake but nothing can
>>>>>> register a handler while kernel is stuck at NOD2 polling loop.
>>>>> I wonder if you could try with the nouveau driver so that it's built-in to
>>>>> the kernel proper? Then it should be ready at the time these events
>>>>> trigger.
>>>> That is not really a workable solution though.
>>> Yeah, I did not meant it to be the "solution" rather just to check whether
>>> it is related if the GPU driver is there or not. You cannot build the
>>> proprietary driver into the kernel so that's why I suggested the
>>> open-source one.
>> Hi Everyone,
>>
>> I would start saying sorry for the necrobump. I faced the same problem on my
>> G614PR and fixed the same way as Francesco.
>>
>> Do you happen to know if there is any news about this? I'm currently on
>> CachyOS with kernel 7.0 and noticed it behaves the same way as 6.19.
>>
>> I'm on to try patches or provide more infos if needed, even if I have to
>> admit I know Linux but not that deeply.
> As far as I can tell no updates unfortunately. I guess we could go with
> slightly updated patch from Francesco, like below that just ignores those
> two interrupts. Can you try if that works for you?
>
> This list of devices that suffer from the "edge events on boot" seems to be
> growing so maybe we should re-think if that should be enabled for all
> systems or limit to the problematic ones (although that list could get big
> too ;-))
>
> diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
> index a0116f004975..4e60a176ac93 100644
> --- a/drivers/gpio/gpiolib-acpi-quirks.c
> +++ b/drivers/gpio/gpiolib-acpi-quirks.c
> @@ -392,6 +392,23 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
>   			.ignore_wake = "VEN_0488:00@355",
>   		},
>   	},
> +	{
> +		/*
> +		 * The ASUS ROG Strix G16 (2025) ACPI GPIO configuration
> +		 * causes acpi_gpio_handle_deferred_request_irqs() to
> +		 * stall for ~36 seconds during boot so ignore the two
> +		 * interrupts involved.
> +		 *
> +		 * Found in BIOS G614PP.307.
> +		 */
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16 G614PP_G614PP"),
> +		},
> +		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
> +			.ignore_interrupt = "AMDI0030:00@21,AMDI0030:00@24",
> +		},
> +	},
>   	{} /* Terminating entry */
>   };
>   

Hi Mika,

thank you for the quick reply. AFAICS the patch as is would only works 
for the G614PP and not for the others (for eg I have G614PR_G614PR).

Assuming all the variants suffer the same problem would it be ok to use 
a wildcard for it?

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

[Mika Westerberg]

On Wed, Apr 22, 2026 at 11:45:33AM +0200, Marco Scardovi wrote:
> 
> On 4/22/26 11:07, Mika Westerberg wrote:
> > Hi,
> > 
> > On Wed, Apr 22, 2026 at 09:51:01AM +0200, Marco Scardovi wrote:
> > > On 12/18/25 11:38, Mika Westerberg wrote:
> > > > On Thu, Dec 18, 2025 at 11:33:14AM +0100, Hans de Goede wrote:
> > > > > Hi,
> > > > > 
> > > > > On 18-Dec-25 07:39, Mika Westerberg wrote:
> > > > > > On Wed, Dec 17, 2025 at 07:19:56PM +0000, Francesco Lauritano wrote:
> > > > > > > On Wednesday, December 17th, 2025 at 7:01 PM, Mario Limonciello <superm1@kernel.org> wrote:
> > > > > > > 
> > > > > > > > On 12/17/25 10:57 AM, Francesco Lauritano wrote:
> > > > > > > > 
> > > > > > > > > On Wednesday, December 17th, 2025 at 4:12 PM, Francesco Lauritano francesco.lauritano1@protonmail.com wrote:
> > > > > > > > > 
> > > > > > > > > > The _AEI defines 5 GPIO interrupts. Narrowed it down to two:
> > > > > > > > > > 
> > > > > > > > > > gpiolib_acpi.ignore_interrupt=AMDI0030:00@21,AMDI0030:00@24
> > > > > > > > > > 
> > > > > > > > > > This fixes the delay. Pins 0x15 and 0x18 both call: \_SB.PCI0.SBRG.HNC0()
> > > > > > > > > Traced it further. HNC0(pin, 0) takes the Else branch and calls:
> > > > > > > > > ATKM(0xC0)
> > > > > > > > > ADTM(Zero)
> > > > > > > > > 
> > > > > > > > > ADTM calls NOD2(), which is the actual culprit:
> > > > > > > > > 
> > > > > > > > > While ((Arg0 != RDNT))
> > > > > > > > > {
> > > > > > > > > If ((Local0 >= 0x0F)) { Break }
> > > > > > > > > Notify (^^GPP0.PEGP, Arg0)
> > > > > > > > > Local0++
> > > > > > > > > Sleep (Local0 * 0x64)
> > > > > > > > > }
> > > > > > > > > 
> > > > > > > > > It notifies the dGPU and polls RDNT, sleeping 100, 200, ... 1500ms per iteration.
> > > > > > > > > Max 15 loops = ~12s per pin. GPU doesn't respond at boot so it maxes out.
> > > > > > > > > 
> > > > > > > > > Two pins, ~12s each, ~24-36s total.
> > > > > > > > > 
> > > > > > > > > Francesco
> > > > > > > > Any idea why isn't the dGPU responding? I would have expected
> > > > > > > > https://git.kernel.org/torvalds/c/4d4c10f763d78 sets up policy that it's
> > > > > > > > in D0.
> > > > > > > > 
> > > > > > > > Is the dGPU turned off in BIOS or through some reverse engineered
> > > > > > > > tool/API or something?
> > > > > > > dmesg without the workaround:
> > > > > > > [    1.005184] pci 0000:01:00.0: PME# supported from D0 D3hot
> > > > > > > [    1.288811] pci 0000:01:00.0: vgaarb: VGA device added
> > > > > > > [   38.250139] nvidia: loading out-of-tree module taints kernel.
> > > > > > > [   38.369358] nvidia 0000:01:00.0: enabling device (0000 -> 0003)
> > > > > > > [   39.744421] NVRM: GPS ACPI DSM called before _acpiDsmSupportedFuncCacheInit
> > > > > > > 
> > > > > > > GPU is in D0 from 1.0s. nvidia loads at 38.2s after the GPIO hang completes.
> > > > > > > 
> > > > > > > No weird tools/APIs besides userspace utils (asusctl/supergfxctl).
> > > > > > > 
> > > > > > > No changes to BIOS factory defaults other than disabling Fast Boot.
> > > > > > > dGPU is active, Display Mode is Dynamic (hybrid).
> > > > > > > 
> > > > > > > Traced RDNT - it's set by GPS function 19 in the ACPI tables:
> > > > > > > Case (0x13)
> > > > > > > {
> > > > > > >       Debug = "GPS fun 19"
> > > > > > >       \_SB.PCI0.SBRG.RDNT = (Local1 + 0xD1)
> > > > > > > }
> > > > > > > 
> > > > > > > As far as I can understand GPIO initcall blocks at late_initcall_sync, preventing nvidia
> > > > > > > from loading in time to respond. Based on the timing, GPU is awake but nothing can
> > > > > > > register a handler while kernel is stuck at NOD2 polling loop.
> > > > > > I wonder if you could try with the nouveau driver so that it's built-in to
> > > > > > the kernel proper? Then it should be ready at the time these events
> > > > > > trigger.
> > > > > That is not really a workable solution though.
> > > > Yeah, I did not meant it to be the "solution" rather just to check whether
> > > > it is related if the GPU driver is there or not. You cannot build the
> > > > proprietary driver into the kernel so that's why I suggested the
> > > > open-source one.
> > > Hi Everyone,
> > > 
> > > I would start saying sorry for the necrobump. I faced the same problem on my
> > > G614PR and fixed the same way as Francesco.
> > > 
> > > Do you happen to know if there is any news about this? I'm currently on
> > > CachyOS with kernel 7.0 and noticed it behaves the same way as 6.19.
> > > 
> > > I'm on to try patches or provide more infos if needed, even if I have to
> > > admit I know Linux but not that deeply.
> > As far as I can tell no updates unfortunately. I guess we could go with
> > slightly updated patch from Francesco, like below that just ignores those
> > two interrupts. Can you try if that works for you?
> > 
> > This list of devices that suffer from the "edge events on boot" seems to be
> > growing so maybe we should re-think if that should be enabled for all
> > systems or limit to the problematic ones (although that list could get big
> > too ;-))
> > 
> > diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
> > index a0116f004975..4e60a176ac93 100644
> > --- a/drivers/gpio/gpiolib-acpi-quirks.c
> > +++ b/drivers/gpio/gpiolib-acpi-quirks.c
> > @@ -392,6 +392,23 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
> >   			.ignore_wake = "VEN_0488:00@355",
> >   		},
> >   	},
> > +	{
> > +		/*
> > +		 * The ASUS ROG Strix G16 (2025) ACPI GPIO configuration
> > +		 * causes acpi_gpio_handle_deferred_request_irqs() to
> > +		 * stall for ~36 seconds during boot so ignore the two
> > +		 * interrupts involved.
> > +		 *
> > +		 * Found in BIOS G614PP.307.
> > +		 */
> > +		.matches = {
> > +			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> > +			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16 G614PP_G614PP"),
> > +		},
> > +		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
> > +			.ignore_interrupt = "AMDI0030:00@21,AMDI0030:00@24",
> > +		},
> > +	},
> >   	{} /* Terminating entry */
> >   };
> 
> Hi Mika,
> 
> thank you for the quick reply. AFAICS the patch as is would only works for
> the G614PP and not for the others (for eg I have G614PR_G614PR).

Ah sorry missed that.

> Assuming all the variants suffer the same problem would it be ok to use a
> wildcard for it?

Yeah, we could expand it to all "ROG Strix G16" I think:

diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
index a0116f004975..e3a6111854e8 100644
--- a/drivers/gpio/gpiolib-acpi-quirks.c
+++ b/drivers/gpio/gpiolib-acpi-quirks.c
@@ -392,6 +392,23 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
 			.ignore_wake = "VEN_0488:00@355",
 		},
 	},
+	{
+		/*
+		 * The ASUS ROG Strix G16 (2025) ACPI GPIO configuration
+		 * causes acpi_gpio_handle_deferred_request_irqs() to
+		 * stall for ~36 seconds during boot so ignore the two
+		 * interrupts involved.
+		 *
+		 * Found in BIOS G614PP.307.
+		 */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16"),
+		},
+		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
+			.ignore_interrupt = "AMDI0030:00@21,AMDI0030:00@24",
+		},
+	},
 	{} /* Terminating entry */
 };
 

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

[Marco Scardovi]

On 4/22/26 11:55, Mika Westerberg wrote:
> On Wed, Apr 22, 2026 at 11:45:33AM +0200, Marco Scardovi wrote:
>> On 4/22/26 11:07, Mika Westerberg wrote:
>>> Hi,
>>>
>>> On Wed, Apr 22, 2026 at 09:51:01AM +0200, Marco Scardovi wrote:
>>>> On 12/18/25 11:38, Mika Westerberg wrote:
>>>>> On Thu, Dec 18, 2025 at 11:33:14AM +0100, Hans de Goede wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 18-Dec-25 07:39, Mika Westerberg wrote:
>>>>>>> On Wed, Dec 17, 2025 at 07:19:56PM +0000, Francesco Lauritano wrote:
>>>>>>>> On Wednesday, December 17th, 2025 at 7:01 PM, Mario Limonciello <superm1@kernel.org> wrote:
>>>>>>>>
>>>>>>>>> On 12/17/25 10:57 AM, Francesco Lauritano wrote:
>>>>>>>>>
>>>>>>>>>> On Wednesday, December 17th, 2025 at 4:12 PM, Francesco Lauritano francesco.lauritano1@protonmail.com wrote:
>>>>>>>>>>
>>>>>>>>>>> The _AEI defines 5 GPIO interrupts. Narrowed it down to two:
>>>>>>>>>>>
>>>>>>>>>>> gpiolib_acpi.ignore_interrupt=AMDI0030:00@21,AMDI0030:00@24
>>>>>>>>>>>
>>>>>>>>>>> This fixes the delay. Pins 0x15 and 0x18 both call: \_SB.PCI0.SBRG.HNC0()
>>>>>>>>>> Traced it further. HNC0(pin, 0) takes the Else branch and calls:
>>>>>>>>>> ATKM(0xC0)
>>>>>>>>>> ADTM(Zero)
>>>>>>>>>>
>>>>>>>>>> ADTM calls NOD2(), which is the actual culprit:
>>>>>>>>>>
>>>>>>>>>> While ((Arg0 != RDNT))
>>>>>>>>>> {
>>>>>>>>>> If ((Local0 >= 0x0F)) { Break }
>>>>>>>>>> Notify (^^GPP0.PEGP, Arg0)
>>>>>>>>>> Local0++
>>>>>>>>>> Sleep (Local0 * 0x64)
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> It notifies the dGPU and polls RDNT, sleeping 100, 200, ... 1500ms per iteration.
>>>>>>>>>> Max 15 loops = ~12s per pin. GPU doesn't respond at boot so it maxes out.
>>>>>>>>>>
>>>>>>>>>> Two pins, ~12s each, ~24-36s total.
>>>>>>>>>>
>>>>>>>>>> Francesco
>>>>>>>>> Any idea why isn't the dGPU responding? I would have expected
>>>>>>>>> https://git.kernel.org/torvalds/c/4d4c10f763d78 sets up policy that it's
>>>>>>>>> in D0.
>>>>>>>>>
>>>>>>>>> Is the dGPU turned off in BIOS or through some reverse engineered
>>>>>>>>> tool/API or something?
>>>>>>>> dmesg without the workaround:
>>>>>>>> [    1.005184] pci 0000:01:00.0: PME# supported from D0 D3hot
>>>>>>>> [    1.288811] pci 0000:01:00.0: vgaarb: VGA device added
>>>>>>>> [   38.250139] nvidia: loading out-of-tree module taints kernel.
>>>>>>>> [   38.369358] nvidia 0000:01:00.0: enabling device (0000 -> 0003)
>>>>>>>> [   39.744421] NVRM: GPS ACPI DSM called before _acpiDsmSupportedFuncCacheInit
>>>>>>>>
>>>>>>>> GPU is in D0 from 1.0s. nvidia loads at 38.2s after the GPIO hang completes.
>>>>>>>>
>>>>>>>> No weird tools/APIs besides userspace utils (asusctl/supergfxctl).
>>>>>>>>
>>>>>>>> No changes to BIOS factory defaults other than disabling Fast Boot.
>>>>>>>> dGPU is active, Display Mode is Dynamic (hybrid).
>>>>>>>>
>>>>>>>> Traced RDNT - it's set by GPS function 19 in the ACPI tables:
>>>>>>>> Case (0x13)
>>>>>>>> {
>>>>>>>>        Debug = "GPS fun 19"
>>>>>>>>        \_SB.PCI0.SBRG.RDNT = (Local1 + 0xD1)
>>>>>>>> }
>>>>>>>>
>>>>>>>> As far as I can understand GPIO initcall blocks at late_initcall_sync, preventing nvidia
>>>>>>>> from loading in time to respond. Based on the timing, GPU is awake but nothing can
>>>>>>>> register a handler while kernel is stuck at NOD2 polling loop.
>>>>>>> I wonder if you could try with the nouveau driver so that it's built-in to
>>>>>>> the kernel proper? Then it should be ready at the time these events
>>>>>>> trigger.
>>>>>> That is not really a workable solution though.
>>>>> Yeah, I did not meant it to be the "solution" rather just to check whether
>>>>> it is related if the GPU driver is there or not. You cannot build the
>>>>> proprietary driver into the kernel so that's why I suggested the
>>>>> open-source one.
>>>> Hi Everyone,
>>>>
>>>> I would start saying sorry for the necrobump. I faced the same problem on my
>>>> G614PR and fixed the same way as Francesco.
>>>>
>>>> Do you happen to know if there is any news about this? I'm currently on
>>>> CachyOS with kernel 7.0 and noticed it behaves the same way as 6.19.
>>>>
>>>> I'm on to try patches or provide more infos if needed, even if I have to
>>>> admit I know Linux but not that deeply.
>>> As far as I can tell no updates unfortunately. I guess we could go with
>>> slightly updated patch from Francesco, like below that just ignores those
>>> two interrupts. Can you try if that works for you?
>>>
>>> This list of devices that suffer from the "edge events on boot" seems to be
>>> growing so maybe we should re-think if that should be enabled for all
>>> systems or limit to the problematic ones (although that list could get big
>>> too ;-))
>>>
>>> diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
>>> index a0116f004975..4e60a176ac93 100644
>>> --- a/drivers/gpio/gpiolib-acpi-quirks.c
>>> +++ b/drivers/gpio/gpiolib-acpi-quirks.c
>>> @@ -392,6 +392,23 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
>>>    			.ignore_wake = "VEN_0488:00@355",
>>>    		},
>>>    	},
>>> +	{
>>> +		/*
>>> +		 * The ASUS ROG Strix G16 (2025) ACPI GPIO configuration
>>> +		 * causes acpi_gpio_handle_deferred_request_irqs() to
>>> +		 * stall for ~36 seconds during boot so ignore the two
>>> +		 * interrupts involved.
>>> +		 *
>>> +		 * Found in BIOS G614PP.307.
>>> +		 */
>>> +		.matches = {
>>> +			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>>> +			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16 G614PP_G614PP"),
>>> +		},
>>> +		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
>>> +			.ignore_interrupt = "AMDI0030:00@21,AMDI0030:00@24",
>>> +		},
>>> +	},
>>>    	{} /* Terminating entry */
>>>    };
>> Hi Mika,
>>
>> thank you for the quick reply. AFAICS the patch as is would only works for
>> the G614PP and not for the others (for eg I have G614PR_G614PR).
> Ah sorry missed that.
>
>> Assuming all the variants suffer the same problem would it be ok to use a
>> wildcard for it?
> Yeah, we could expand it to all "ROG Strix G16" I think:
>
> diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
> index a0116f004975..e3a6111854e8 100644
> --- a/drivers/gpio/gpiolib-acpi-quirks.c
> +++ b/drivers/gpio/gpiolib-acpi-quirks.c
> @@ -392,6 +392,23 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
>   			.ignore_wake = "VEN_0488:00@355",
>   		},
>   	},
> +	{
> +		/*
> +		 * The ASUS ROG Strix G16 (2025) ACPI GPIO configuration
> +		 * causes acpi_gpio_handle_deferred_request_irqs() to
> +		 * stall for ~36 seconds during boot so ignore the two
> +		 * interrupts involved.
> +		 *
> +		 * Found in BIOS G614PP.307.
> +		 */
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16"),
> +		},
> +		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
> +			.ignore_interrupt = "AMDI0030:00@21,AMDI0030:00@24",
> +		},
> +	},
>   	{} /* Terminating entry */
>   };
>   
As for now it seems working. I've reverted it on my kernel as I prefer 
remain as much as possible close to the CachyOS' one but hopefully it 
will be implemented on 7.1, if someone propose the patch and it is 
accepted. It would be amazing to see Asus more interested on Linux and 
more strict with their BIOS but in the end I understand it's like asking 
for the moon.

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

[Mika Westerberg]

Hi,

On Wed, Apr 22, 2026 at 02:08:29PM +0200, Marco Scardovi wrote:
> > > Assuming all the variants suffer the same problem would it be ok to use a
> > > wildcard for it?
> > Yeah, we could expand it to all "ROG Strix G16" I think:
> > 
> > diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
> > index a0116f004975..e3a6111854e8 100644
> > --- a/drivers/gpio/gpiolib-acpi-quirks.c
> > +++ b/drivers/gpio/gpiolib-acpi-quirks.c
> > @@ -392,6 +392,23 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
> >   			.ignore_wake = "VEN_0488:00@355",
> >   		},
> >   	},
> > +	{
> > +		/*
> > +		 * The ASUS ROG Strix G16 (2025) ACPI GPIO configuration
> > +		 * causes acpi_gpio_handle_deferred_request_irqs() to
> > +		 * stall for ~36 seconds during boot so ignore the two
> > +		 * interrupts involved.
> > +		 *
> > +		 * Found in BIOS G614PP.307.
> > +		 */
> > +		.matches = {
> > +			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> > +			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16"),
> > +		},
> > +		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
> > +			.ignore_interrupt = "AMDI0030:00@21,AMDI0030:00@24",
> > +		},
> > +	},
> >   	{} /* Terminating entry */
> >   };
> As for now it seems working. I've reverted it on my kernel as I prefer
> remain as much as possible close to the CachyOS' one but hopefully it will
> be implemented on 7.1, if someone propose the patch and it is accepted. It
> would be amazing to see Asus more interested on Linux and more strict with
> their BIOS but in the end I understand it's like asking for the moon.

Okay thanks for checking. I guess this is what we have to live with for now
until someone finds a better way of dealing with these.

@Francesco, would you like to submit a new version of the patch similar to
above or you want me to do that?

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

[Mario Limonciello]

On 4/22/26 23:42, Mika Westerberg wrote:
> Hi,
> 
> On Wed, Apr 22, 2026 at 02:08:29PM +0200, Marco Scardovi wrote:
>>>> Assuming all the variants suffer the same problem would it be ok to use a
>>>> wildcard for it?
>>> Yeah, we could expand it to all "ROG Strix G16" I think:
>>>
>>> diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
>>> index a0116f004975..e3a6111854e8 100644
>>> --- a/drivers/gpio/gpiolib-acpi-quirks.c
>>> +++ b/drivers/gpio/gpiolib-acpi-quirks.c
>>> @@ -392,6 +392,23 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
>>>    			.ignore_wake = "VEN_0488:00@355",
>>>    		},
>>>    	},
>>> +	{
>>> +		/*
>>> +		 * The ASUS ROG Strix G16 (2025) ACPI GPIO configuration
>>> +		 * causes acpi_gpio_handle_deferred_request_irqs() to
>>> +		 * stall for ~36 seconds during boot so ignore the two
>>> +		 * interrupts involved.
>>> +		 *
>>> +		 * Found in BIOS G614PP.307.
>>> +		 */
>>> +		.matches = {
>>> +			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>>> +			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16"),
>>> +		},
>>> +		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
>>> +			.ignore_interrupt = "AMDI0030:00@21,AMDI0030:00@24",
>>> +		},
>>> +	},
>>>    	{} /* Terminating entry */
>>>    };
>> As for now it seems working. I've reverted it on my kernel as I prefer
>> remain as much as possible close to the CachyOS' one but hopefully it will
>> be implemented on 7.1, if someone propose the patch and it is accepted. It
>> would be amazing to see Asus more interested on Linux and more strict with
>> their BIOS but in the end I understand it's like asking for the moon.
> 
> Okay thanks for checking. I guess this is what we have to live with for now
> until someone finds a better way of dealing with these.
> 
> @Francesco, would you like to submit a new version of the patch similar to
> above or you want me to do that?

Hans suggested that we might want to look at ripping out this edge 
triggered events at boot earlier in the thread.

https://lore.kernel.org/platform-driver-x86/20260423044211.GD557136@black.igk.intel.com/T/#mdca882e6606d3a894ec7499d3b742d040933dbdb

Hans - as you pointed out that the Surface lid state is the only real 
issue left and you happen to have one do you think you could work up 
some patches?

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

[Marco Scardovi]

On 4/23/26 07:15, Mario Limonciello wrote:
> On 4/22/26 23:42, Mika Westerberg wrote:
>> Hi,
>>
>> On Wed, Apr 22, 2026 at 02:08:29PM +0200, Marco Scardovi wrote:
>>>>> Assuming all the variants suffer the same problem would it be ok 
>>>>> to use a
>>>>> wildcard for it?
>>>> Yeah, we could expand it to all "ROG Strix G16" I think:
>>>>
>>>> diff --git a/drivers/gpio/gpiolib-acpi-quirks.c 
>>>> b/drivers/gpio/gpiolib-acpi-quirks.c
>>>> index a0116f004975..e3a6111854e8 100644
>>>> --- a/drivers/gpio/gpiolib-acpi-quirks.c
>>>> +++ b/drivers/gpio/gpiolib-acpi-quirks.c
>>>> @@ -392,6 +392,23 @@ static const struct dmi_system_id 
>>>> gpiolib_acpi_quirks[] __initconst = {
>>>>                .ignore_wake = "VEN_0488:00@355",
>>>>            },
>>>>        },
>>>> +    {
>>>> +        /*
>>>> +         * The ASUS ROG Strix G16 (2025) ACPI GPIO configuration
>>>> +         * causes acpi_gpio_handle_deferred_request_irqs() to
>>>> +         * stall for ~36 seconds during boot so ignore the two
>>>> +         * interrupts involved.
>>>> +         *
>>>> +         * Found in BIOS G614PP.307.
>>>> +         */
>>>> +        .matches = {
>>>> +            DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>>>> +            DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16"),
>>>> +        },
>>>> +        .driver_data = &(struct acpi_gpiolib_dmi_quirk) {
>>>> +            .ignore_interrupt = "AMDI0030:00@21,AMDI0030:00@24",
>>>> +        },
>>>> +    },
>>>>        {} /* Terminating entry */
>>>>    };
>>> As for now it seems working. I've reverted it on my kernel as I prefer
>>> remain as much as possible close to the CachyOS' one but hopefully 
>>> it will
>>> be implemented on 7.1, if someone propose the patch and it is 
>>> accepted. It
>>> would be amazing to see Asus more interested on Linux and more 
>>> strict with
>>> their BIOS but in the end I understand it's like asking for the moon.
>>
>> Okay thanks for checking. I guess this is what we have to live with 
>> for now
>> until someone finds a better way of dealing with these.
>>
>> @Francesco, would you like to submit a new version of the patch 
>> similar to
>> above or you want me to do that?
>
> Hans suggested that we might want to look at ripping out this edge 
> triggered events at boot earlier in the thread.
>
> https://lore.kernel.org/platform-driver-x86/20260423044211.GD557136@black.igk.intel.com/T/#mdca882e6606d3a894ec7499d3b742d040933dbdb 
>
>
> Hans - as you pointed out that the Surface lid state is the only real 
> issue left and you happen to have one do you think you could work up 
> some patches?
>
I see. Well, that makes totally sense