> Right, and see also: > > commit 6b5cde3629701258004b94cde75dd1089b556b02 > Author: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx> > Date: Mon Dec 29 20:27:32 2008 +0100 > > cmd64x: set IDE_HFLAG_SERIALIZE explictly for CMD646 > > Which is how we got there. > > The most conservative thing to do is to set the flag as > is done by mpatocka's patch but I'd like Frans to regression > test that on his ultra5. > > Frans can you do that? > > Thanks. I read the thread about wild interrupts that Frans was observing and that led to disabling the serialization. The thing is tricky --- if we read status register on interrupt, we break the serialization principle and introduce potential data corruption. If we don't read the status register, the wild interrupt kills the whole interrupt line. I think the interrupt handler should read the BM-status register on both channels (it reflects the interrupt state even in PIO mode) to test if there is an unexpected interrupt on the inactive channel --- this should be much more safe than reading the status register. If there is an interrupt, then --- read the status of the inactive channel? (potential data corruption, but it is reported to happen only on boot). --- Or can the interrupt be acknowledged only in BM-status without touching the device? I believe yes, it shoud shut the PCI interrupt but it would leave the IDE interrupt line on (should be cleared on next command). Mikulas -- 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
