https://bugzilla.kernel.org/show_bug.cgi?id=216230 --- Comment #7 from madcatx@xxxxxxxx --- (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.
