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

[Marco Scardovi <mscardovi95@gmail.com>]

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?