From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Marco Scardovi <mscardovi95@gmail.com>
Cc: Hans de Goede <hansg@kernel.org>,
Francesco Lauritano <francesco.lauritano1@protonmail.com>,
Mario Limonciello <superm1@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"open list:GPIO ACPI SUPPORT" <linux-gpio@vger.kernel.org>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"westeri@kernel.org" <westeri@kernel.org>,
Benjamin Tissoires <bentiss@kernel.org>
Subject: Re: [BUG] 36-second boot delay due to by acpi_gpio_handle_deferred_request_irqs on ASUS ROG Strix G16 (2025)
Date: Wed, 22 Apr 2026 11:55:58 +0200 [thread overview]
Message-ID: <20260422095558.GC557136@black.igk.intel.com> (raw)
In-Reply-To: <4e55e31e-a5e8-4098-8a7f-bb52476b882a@gmail.com>
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 */
};
next prev parent reply other threads:[~2026-04-22 9:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2kSCn4XaoXsXJ3EUR0syTdmip8Z1cBuUr0Br4sFVnwnsA8q4GlhiHOmsJkeBxvxYoLnetp4r44wIPXw42yTAFl-BtMROnIwR-NkckKgA5EY=@protonmail.com>
2025-12-17 10:06 ` [BUG] 36-second boot delay due to by acpi_gpio_handle_deferred_request_irqs on ASUS ROG Strix G16 (2025) Francesco Lauritano
2025-12-17 12:01 ` [PATCH] gpiolib: acpi: Disable edge events on boot on ASUS ROG Strix G16 G614PP francesco.lauritano1
2025-12-17 13:08 ` Mika Westerberg
2025-12-17 14:01 ` Francesco Lauritano
2025-12-28 20:15 ` Andy Shevchenko
2025-12-17 14:23 ` [BUG] 36-second boot delay due to by acpi_gpio_handle_deferred_request_irqs on ASUS ROG Strix G16 (2025) Mario Limonciello
2025-12-17 15:12 ` Francesco Lauritano
2025-12-17 16:57 ` Francesco Lauritano
2025-12-17 18:01 ` Mario Limonciello
2025-12-17 19:19 ` Francesco Lauritano
2025-12-18 6:39 ` Mika Westerberg
2025-12-18 10:33 ` Hans de Goede
2025-12-18 10:38 ` Mika Westerberg
2026-04-22 7:51 ` Marco Scardovi
2026-04-22 9:07 ` Mika Westerberg
2026-04-22 9:45 ` Marco Scardovi
2026-04-22 9:55 ` Mika Westerberg [this message]
2026-04-22 12:08 ` Marco Scardovi
2026-04-23 4:42 ` Mika Westerberg
2026-04-23 5:15 ` Mario Limonciello
2026-04-23 17:46 ` Marco Scardovi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260422095558.GC557136@black.igk.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=bentiss@kernel.org \
--cc=francesco.lauritano1@protonmail.com \
--cc=hansg@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mscardovi95@gmail.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=superm1@kernel.org \
--cc=westeri@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox