On Thu, Dec 14, 2017 at 11:36 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > 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. That's my understanding too. Thanks, Rafael
