On Mon, 26 Oct 2009 07:36:48 -0400 (EDT) Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > On Fri, 23 Oct 2009, Alan Cox wrote: > > > > Yeah. The libata driver however doesn't make use of that register, > > > unlike cmd64x. It doesn't even touch the interrupt bits on PCI0646, only > > > manipulation the "old" bits on PCI-64[89]. > > > > Yes I purposefully left out all the complexity because when I tested the > > cards I had it simply wasn't needed. I'm also not sure we should merge > > anything from the old to the new one until we know why the old one > > corrupts and the new one merely gets upset. Accidentally porting over a > > corruptor would be very bad indeed. > > Well, if Daniela showed that cmd64[36] docs say it needs serialization, > then just add it there. Don't rely on the fact that the corruption didn't > happen in my case. Daniela sent me the relevant document - it doesn't exactly match what is being described here as it relates to motherboards improperly timing out PCI access requests. Basically the fix is "don't touch the task file on one channel while DMA is live on the other". That means that for libata serialize is not sufficient on a shared IRQ set up as we'll touch ALTSTATUS. Plus it is overkill as you can have parallel issue PIO commands. For libata the best way to fix it seems to be to avoid parallel issuing commands with an ATA_PROT_DMA/ATAPI_PROT_DMA command outstanding, and to check the IRQ bits. Patch to follow when I get a moment. -- 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
