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. > 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. -- [EMAIL PROTECTED] Andy Warner Voice: (612) 801-8549 Fax: (208) 575-5634 - 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
