Mark Lord wrote: > Tejun Heo wrote: >> >> I don't really know how to fix this. It seems the only options are 1. >> disable_irq() as IDE does which sucks if the IRQ is shared 2. doing PIO >> transfers with local IRQ disabled and spinlock locked which makes the >> system stutter like hell. Oh crap, all this because we don't have >> simple reliable IRQ pending bit. :-( >> >> Oh, BTW, we do have reliable IRQ pending bit on ata_piix's. The IRQ bit >> in BMDMA status acts as a IRQ pending even if the command isn't a DMA >> one. This is why we clear BMDMA IRQ even after nodata or PIO commands, >> so we can probably solve the problem nicely for ata_piix by calling >> ata_port_freeze() if IRQ is received while ATA_PFLAG_HSM_WQ is set. >> sata_sil also has reliable IRQ pending bit. > > I'm not sure if this suggestion is the same as what you just described, > but what we can do here is just set a flag before the PIO block, > and clear it again after PIO completes. > > The libata IRQ handler for that channel would then check for this flag > on entry, before touching any chipset registers, and if it sees the flag > then it should self-disable the IRQ and return immediately. > > The PIO block would then also have to know to re-enable the IRQ on > completion. > > This way, we only disable the IRQ when it is actually necessary > for the specific hardware at run-time. Heh heh, that was the first approach tried and we couldn't solve unexpected IRQ problem which can be triggered by cable problem or whatever. If the work thread doesn't turn off IRQ and the IRQ handler doesn't clear it when it happens, we end up with nobody-cared. -- tejun - 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
