https://bugzilla.kernel.org/show_bug.cgi?id=216230 --- Comment #18 from Mario Limonciello (AMD) (mario.limonciello@xxxxxxx) --- > IIRC this means that those debugging statements are enabled. The only > relevant line from dmesg is this though: Yeah the other two messages you won't be seeing generally. They're relevant to certain circumstances. > [ 0.668575] amd_gpio AMDI0030:00: amd gpio driver loaded The really important thing here is the kernel timestamp. If you compare it to the failing log you have above, you can see that the failure happens a lot later in the boot. [ 4.295441] kernel: irq 9: nobody cared (try booting with the "irqpoll" option) > I just noticed another case where the number of interrupts reached about > 12000. With a bit of careful optimism I think that loading pinctrl_amd early > during boot puts an early stop to the IRQ storm before the kernel intervenes > and disables the interrupt channel. > As for reproducibility, I think that the machine needs to run for some time > before the problem can be "re-reproduced". This is why it looked like it was > happening only on cold boots. Assuming there an EC connected to these GPIOs I > guess it's some kind of timer overflow...? Careful optimism sounds appropriate, but fingers crossed! As a general statement it seems that by using an encrypted partition you exacerbated this problem because you will by definition have a longer boot that you don't have access to pinctrl-amd's kernel object while getting your passphrase entered. I'd say if you don't hit this in the next few days with this change we should close it as "DOCUMENTED". Mayyybe we should add something to the Kconfig text to warn about this? Not sure what else can really be done from the kernel. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
