Re: [PATCH RESEND number 2] libata: eliminate the home grown dma padding in favour of that provided by the block layer

[Tejun Heo <htejun@gmail.com>]

James Bottomley wrote:
> I'm only really going by what Tejun says about AHCI.  The problem as I
> understand it is data overrun on PIO mode commands.  AHCI apparently
> (like aic94xx) processes these internally and doesn't actually use the
> libata pio handlers, so it just uses an internal buffer to receive the
> PIO and DMA it into memory.  However, Tejun says (and he'll correct me
> if I'm paraphrasing wrongly, since this was on IRC a while ago) that jmb
> ahci and sata_sil24 both error out in different (but fairly nasty) ways
> if they get extra PIO data that there's no place in the SG list to
> deposit.  This seems to be why he wants to introduce a DMA drain in
> addition to the existing PIO drain.  I'd certainly characterise this
> behaviour as "broken" ... especially as not all AHCI implementations
> apparently have the bug ... some do exactly the right thing on PIO
> overruns and don't need the drain element.

JMB ahci triggers internal error (or was it timeout?  my memory is a bit
blurry now) on overflow.  ICHx ahci and sata_sil24 corrupt data by
offsetting the last FIS containing odd bytes by a byte if data buffer is
not aligned to 4bytes under certain conditions.

[and some explanations on why the aligning and draining stuff]

Also note that ignoring overflow and/or appending draining buffer
shouldn't be applied to READ/WRITE.  Over/underflow should just cause
HSM violation on RWs and friends.  We can do this for each driver or
rather each controller by enabling OFS (ahci), DRD (sil24) but the catch
is that it's pretty darn difficult to verify it actually works.  It not
only depends on specific controller but also on which ATAPI device is
attached and how it behaves depending on chunk size, transfer size in
CDB and command protocol including where it splits data FISes.

For example, IIRC, the above offset-by-one condition occurs on ICHx
ahci's (I've tested 7, 8 and 9), under PIO protocol, when the device
determines to use a separate data FIS for the last three bytes and I
don't know why it doesn't happen for DMA.  It's probably because the
ATAPI devices I have don't split FIS there but who knows?

So, I think we're far better off implementing a generic mechanism at
some higher layer.  libata core was okay.  Block layer is much better.
The overhead is insignificant and the aligning and draining aren't
needed for hot path commands anyway.

Thanks.

-- 
tejun