Re: libata oops 2.6.11-rc4 yesterdays BK

[Andy Warner <andyw@pobox.com>]

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.
-- 
andyw@pobox.com

Andy Warner		Voice: (612) 801-8549	Fax: (208) 575-5634