Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> writes: > On Fri, 2008-07-11 at 15:59 -0700, Eric W. Biederman wrote: >> >> Working mask/unmask. With MSI-X as specced if I mask an irq and then unmask >> it, an msi message will fire if something happened while the irq was masked >> and not taken care of before the irq was unmasked. That is the correct >> behavior for an irq and a mmu won't let me get that. > > And ? It's just a message, we can ignore it if masked, ie, do > software-masking. Not a big deal... no ? It is edge triggered so it won't refire when unmasked (especially if we don't know). So it is easy to wind up in a state where the device is waiting for the software and the software is waiting for the device because an irq gets dropped. There are enough places that have problems that we have a fairly standard work around to the problem (listed above) by just taking the first irq (after we have disabled the irq) and setting it pending in software and then actually masking it in hardware. That works, but it is still isn't quite correct. Because we can run the interrupt handler once to often. For interrupts that are never shared and always in order with the DMA, generally don't require reading a status register on the card, and are otherwise highly optimized that might actually be a problem. Which is why I said that it doesn't look like even using an iommu can fix all of the issues with treating msi multi message mode messages as individual irqs. We can get very close but not quite there. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
