> We are both half-right.  I reverted my version of that completely, 
quoted text
> applied your version verbatim, and pushed it upstream.  The result: 
> atapi_xlat _did_ start programming lbam/lbah for DMA (another behavior 
> change), but request-sense DMA path was not changed to program lba[mh] 
> for DMA.

I didn't realise we ever issued reques sense by DMA ?

quoted text
> > Only if your transfer is actually 8K or more.
> 
> No, that's precisely the problem cause for what Daniel is reporting.  We 
> are setting blimit=xfer_len(==10), when the device wants to return more 
> than 10 bytes.  When set to the old limit (8k), the problem didn't occur.

Lots of *other* problems occur instead. Daniel is reporting that if he
makes a stupid request to a buggy drive he gets a reset and the system
continues happily. Even that reset being a reset not a new command issue
is actually us being excessively paranoid.

Prior to these changes people were reporting things like "I cannot
use my CD-ROM".

So given we have ten years of experience of the method I put in taken
from the old IDE layer versus a good way to make one buggy request work
and break everything else - I *know* which I consider to be the right
path.

And PIO drains of DMA controllers do not work for most controllers, some
will simply hang solid if you touch the data register as part of a DMA
sequence (eg promise 2026x)

Alan
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/