https://bugzilla.kernel.org/show_bug.cgi?id=216230 --- Comment #6 from Mario Limonciello (AMD) (mario.limonciello@xxxxxxx) --- 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 > 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 ? > 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. 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) 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? > 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? > 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. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
