[Bug 216230] "irq9: nobody cared" on Thinkpad T14 Gen1 (AMD) when s2idle is enabled

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=216230

--- Comment #7 from madcatx@atlas.cz ---
(In reply to Mario Limonciello (AMD) from comment #6)
> The tough thing with this bug is that in this design the IRQ is shared both
> for the ACPI SCI as well as for the GPIO controller.  There are patches in
> the kernel's s2idle handling created specifically for that case.  But it
> means when you're dealing with a spurious interrupt you don't know which
> device it was REALLY destined for.
> 
> Looking at your GPIO output it seems that pin 32 switches from output pin in
> the good scenario to input pin in the bad scenario.  Can you try to
> correlate if this happens every single time you see a problem or it's also a
> red herring?
> 
> Good 
> > pin32     interrupt is disabled| interrupt is masked| disable wakeup in
> S0i3
> > state| disable wakeup in S3 state|
>  disable wakeup in S4/S5 state|     pull-up is disabled| Pull-down is
> disabled| output is high| output is enabled| debouncing filter disabled|  
> 0xc50000
> 
> Bad
> > pin32     interrupt is disabled| interrupt is masked| disable wakeup in
> S0i3
> > state| disable wakeup in S3 state|
>  disable wakeup in S4/S5 state| input is high|   pull-up is disabled|
> Pull-down is disabled|   output is disabled| debouncing filter disabled|  
> 0x50000

I noticed the difference there. I'll keep an eye on it whenever I run into
this,

> > My machine is affected by the NVMe slow wakeup bug so I only started to use
> > s2idle since kernel 5.18.
> 
> Sorry what bug?  Are you talking about
> https://github.com/torvalds/linux/commit/
> 455cd867b85b53fd3602345f9b8a8facc551adc9 ?

Yes, that one, at least I think this is what made s2idle usable for me.

> > I'll see if I can downgrade the firmware if you think that'd help you track
> > this down. FTR I'm on version 1.40 which seems to be the latest one as of
> > now.
> 
> > I attached the requested logs.
> 
> I didn't see the issue listed there, I was hoping to understand the timing
> of it.

Apologies, I'll grab a fresh dmesg when it happens again. Although I'm afraid
it won't be very interesting.

> 
> Something I'm wondering is if maybe it's an IRQ destined for the GPIO
> controller but the GPIO controller driver isn't yet loaded?  This could be
> particularly relevant if it's not in your initramfs but rather loaded after
> you entered your encryption key (noticed root=/dev/mapper/cryptroot)

Okay. Would adding pinctrl_amd to initramfs be enough to rule out this
possibility?

> 
> Could you please turn on dynamic debugging for pinctrl_amd
> (pinctrl.dyndbg=+p on your kernel command line )and share a log with it
> reproducing?

Will do.

> 
> > pcie_aspm=force
> 
> FYI - this is generally not a safe thing to do.  If you remove this from
> your kernel command line can you reproduce the issue?

I'm aware but I've been using this machine with forced ASPM for about 2 years
with no apparent issues related to that. I'll give it a go.

> > As such I don't know if this is a regression. I'll see if I can downgrade
> the
> > firmware if you think that'd help you track this down. FTR I'm on version
> > 1.40 which seems to be the latest one as of now.
> 
> I think Mark will have to comment whether it's something they're aware of,
> tracking, etc regression wise.

Thanks a lot! I'll see what I can do and let you know...

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.