[ Sorry in advance, only have webmail access ATM. ] > The problem seems to be caused by unmasking the IRQ in > handle_fasteoi_irq(), and with a hack along the lines of > > --- a/kernel/irq/chip.c > +++ b/kernel/irq/chip.c > @@ -586,7 +586,8 @@ handle_fasteoi_irq(unsigned int irq, struct irq_desc > *desc) > raw_spin_lock(&desc->lock); > desc->status &= ~IRQ_INPROGRESS; > #ifdef CONFIG_IPIPE > - desc->irq_data.chip->irq_unmask(&desc->irq_data); > + if (irq != WHICHEVER_IRQ_CAUSES_THE_STORM) > + desc->irq_data.chip->irq_unmask(&desc->irq_data); > out: > #else > out: > > the issue is solved. > > So the question is: Why is it okay to unconditionally unmask > all interrupts in the fasteoi handler? All cards that re-send > interrupts at high frequencies unless they are properly handled > by their device driver should cause the same problem. > I take the early unmasking is an optimisation, or are there any > further reasons for the unconditional unmasking in > handle_fasteoi_irq()? >
It think the proper fix is to check for IRQD_IRQ_MASKED and only unmask the line if it isn't masked from Linux' perspective. That should be a long pending i-pipe bug, surfaced by the IRQ thread mask flow that (not only) KVM's device assignment code depends on. Can you give this a try as well? Thanks for digging out the reason! Cheers from Schiphol, Jan ___________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 _______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
