> Even if the unsolicited irq happens, maybe the current code has > good chance to handle it? > e.g. ata_irq_task() already reads the status before data transfer, > thus possibly clearing some of unsolicited irqs. > e.g. maybe the data transfer in the workqueue is quick enough? Probably not given the PIO cycle time. > If yes, hopefully the ATA_PFLAG_HSM_WQ is soon cleared, and > then the interrupt handler can come in ack the irq. (Much the same > way when the irq handler encounters "early irq" by bad devices.) We seem to have three classes of controller here - Those that need IRQs off for transfers anyway (eg ancient VIA) - Those that we must not touch the status bits for but can otherwise behave sanely (Some PIIX, ICH and possibly some others) - Those that behave sanely The first lot are really "No change" and not found on SMP boxes anyway The final ones would I think work with your patch (some testing required) The best I can see that we could do with the Intel ones would be to use disable_irq/enable_irq, especially as they are rarely found in native mode so usually have a private IRQ. The only problem is that we must disable_irq before we take the other locks otherwise we can deadlock in disable_irq waiting for the irq handlers to finish while the IRQ handler is trying to take the lock so never does. - 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
