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
- 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
