On Sun, Aug 21, 2005 at 05:59:31PM -0400, Jeff Garzik wrote: > Tejun Heo wrote: > > Now I see what you're saying. We should be able to know/clear > >interrupt by reading ATA_STATUS. So, not having explicit interrupt > >pending bit can be compensated by following changes in ATA_STATUS (so > >the state machine), right? Thanks a lot for putting up with my ignorance. > > Correct. Just never forget there is a side effect to reading the Status > register -- it clears any interrupt event it also signals. > > > > So, how about a port status bit to tell interrupt handler whether or > >not we are expecting an interrupt currently? That would solve the race > >from I tried to fix in the first patchset. If that's okay with you, > >I'll redo all four patches accordingly. > > I'm a bit skeptical, TBH. I would prefer some sort of approach whereby > the code knows where the port is, inside the host state machine, and may > deduce from that "location" whether or not an interrupt is expected. > That's precisely how the code functions now with ATA DMA and non-data, > at least (or should...). > > If we find out where the bug in the "I know when I expect an interrupt" > logic is, then your race should be easy to fix. Currently, I can see > that (a) ATAPI interrupt can race with called-immediately EH, and (b) > ATAPI may throw an interrupt to indicate CDB is ready to be sent [see > ATA-4], and libata doesn't yet support such a state in its host state > machine (HSM) implementation. > > That said, if you still wish to send such a patch, I will give it an > open and honest review. > > Maybe your bit flag approach plugs the hole in the existing HSM -- I > would just like to know _where_ this hole is. So far I don't see it, > except for (a) and (b) ATAPI examples above.
For example, ATA_PROT_NODATA is processed as follows. Driver Controller ------------------------------------------------------------------------- 1. issue ATA_CMD_PACKET 2. Turns on BSY and sends H2D regs 3. atapi_packet_task poll for BSY 4. D2H regs FIS (!BSY, DRQ) 5. packet_task sends CDB 6. Turns on BSY and sends DATA FIS 7. D2H regs FIS (!BSY, DRDY, INTR) 8. intr handler completes the cmd In step #3, we're waiting for BSY to clear - command is active and NIEN is clear. After step #4 but before #5, command is active, BSY clear and DRQ set, if an interrupt from the other port occurs here, it will incorrectly fail this qc causing EH to kick in for sense data. The problem is that the current interrupt handler is unaware of the HSM state where NIEN and BSY are clear but interrupts are not expected. So, the problem is that the interrupt handler doesn't know enough about HSM state to be able to determine that the interrupt is not its. The flag I've mentioned is to tell just that to the interrupt handler. Otherwise, I think we can implement something like ap->ata_state and fully record where the HSM is, which would also be useful to implement interrupt-driven PIO. What do you think? Thanks. :-) -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
