Re: [PATCH 14/14] libata: use PIO for misc ATAPI commands

[Tejun Heo <htejun@gmail.com>]

Alan Cox wrote:
>> Well, if we change that in #upstream now, -mm will receive it and after
>> 2.6.24 is released, it will end up in -rc1.  We can change it back if
>> the damage is too grave.
> 
> Getting it in -rc is going to mess up other testing. It's perfect for -mm
> testing not -rc testing.

It eventually has to end up in -rc.  If not for 2.6.25-rc1 is too early,
we can put it in #testing and put it into #upstream later.

>> Yeah, ALi seems to be genuine driver problem.  I don't think using PIO
>> for misc ATAPI commands is extreme considering Windows is doing it.
> 
> Windows does a lot of things that are bad and ugly workarounds for messes
> in the past. We have the ability to do a lot better than that.

I agree.  It's double edged sword tho.  We're not gonna get much test
coverage over those messes of the past and as I said, those are what I'm
primarily worried about.  Command type dependent quick fallback might
help but ancient controllers are more likely to bring the whole machine
down when a DMA transaction goes south.

>> Another thing is check_atapi_dma in sata_promise.  It mentions losing
>> interrupt which is exactly what happens if the drive tries to transfer
>> more data but DMA buffer is short on several controllers.  I wonder
>> whether this is unnecessary with DMA draining added.
> 
> Is it like the inic where you must do transfers in specific chunk sizes ?

I don't think so.  It does READ_CD and READ_DVD_STRUCTURE via DMA.  The
first one isn't 2k aligned the second is of variable size.  I think the
driver was just working around buggy userland which issues commands like
mode sense with longer allocation size than actual buffer size.

-- 
tejun