Re: libata oops 2.6.11-rc4 yesterdays BK

[Jeff Garzik <jgarzik@pobox.com>]

Andy Warner wrote:
> Jeff Garzik wrote:
> 
>>[...]
>>Unfortunately, that's what you're _supposed_ to do, busy-wait for every 
>>"block" (where block == 1 sector for PIO, and <n> sectors for PIO-Mult).
> 
> 
> The logic surrounding PIO-multi in PATA-land looked markedly different.

Not surprising, as the path when interrupts are enabled looks different.

I'm starting to wonder if polling isn't just a dismal failure on SATA, 
since the status register/etc. is all emulated.  Thinking further along 
those lines (how an ATA shadow register set is faked by the host 
controller using FIS data), I wonder if polling -- per ATA spec -- 
exposes a race between FIS reception and processing, and the update of 
the ATA shadow register block.


>>Wasn't it you that had a patch that used ata_altstatus() to mitigate 
>>this somewhat?
> 
> 
> Yeah - and to not call queue_work() to accomplish the polling
> (which could start the next poll immediately on an SMP machine),
> I suppose that _could_ just as easily point to a locking problem,
> as a state machine logic flaw. My proof-of-concept kludge was to
> call queue_delayed_work() instead.
> 
> 
>>It's entirely possible that I'm one of the first to punish SATA 
>>controllers with PIO polling data transfer, rather than interrupt-driven 
>>xfer.  The SMP aspect makes me suspicious that something else might be 
>>involved, as well.  Ever since the 2.6.10-bkN kernel updated ACPI, the 
>>one SMP machine I had that failed on libata started working.
> 
> 
> I saw errors on both SiI (3114) and Promise (20319) cards, so
> I'm not convinced that (these) problems are at the chip-level
> (not that there aren't plenty of those to go around.)
> 
> 
>>Any chance you could debug this further?
> 
> 
> I'll see what I can do.

Thanks,

	Jeff