On Tue, 25 Jun 2019, Thomas Gleixner wrote: > Robert, > > On Tue, 25 Jun 2019, Hodaszi, Robert wrote: > > On Mon, 25 Jun 2019, Gleixner, Thomas wrote: > > > > So I assume, only the local APIC has info about the pending IRQ. But as > > free_irq() is running on CPU#0 and the IRQ is pending on CPU#1, CPU#0 > > cannot read CPU#1's local APIC, right? Or maybe I'm missing something? > > The thing is that the interrupt is in edge mode which my tried brain did s/tried/[fried|tired]/ chose one :) > not notice yesterday evening. > > In edge mode the remote-irr bit meaning is undefined and as the docs are > unclear it might eventually give the wrong answer. From a hardware view > this makes sense because edge will just fire and forget, while level needs > the explicit ack before sending it again (if still raised at the pin) > > So for edge the issue is different. The spurious interrupt is harmless as > it does not leave stale state in the IO-APIC around. > > I'm working on a clean fix for both the level and the edge problems. Just > at the point to start testing. Will post the result in a couple of hours. > > Thanks, > > tglx > > >
