On Thu, 14 Dec 2017, Linus Torvalds wrote: > On Thu, Dec 14, 2017 at 3:54 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > I just wanted to pipe up about that "irq7", because judging from your > email it seems like you think it's a real irq: > > > Now there is a race > > whether the kernel resume path manages to mask the PIC again early enough > > before something triggers IRQ7 or not. > > ..and that's not how the PIC works. > > In fact, "legacy irq 7" is the _normal_ and very traditional spurious > interrupt, and it's documented. If the PIC gets an interrupt from > _any_ source, but the interrupt goes away before the PIC gets an > acknowledge from the CPU (and by "acknowledge", I'm not talking about > the explicit software IRQ ACK, I'm talking about the hardware > protocol, between the PIC and the CPU), the PIC will then report irq 7 > as the interrupt - regardless of what the original was. > > The reason is almost always something like > > - CPU interrupts are disabled or masked > > - driver does a write to the external hardware that causes an > interrupt to be raised Which should be a non issue because _ALL_ PIC irq lines are masked at the PIC itself. All interrupts are routed through IOAPIC. So unless the IOAPIC sports similar behaviour the PIC should not ever observe that scenario. But, because the silly firmware comes out of suspend with all PIC lines unmasked for whatever reason, the PIC can observe that IRQ being raised and the CPU not handling it. So yes, I forgot about 7 being magic, but I still think it's the firmware which causes it by unmasking the PIC irqs. Thanks, tglx
