A note on libata passthru patch

A note on libata passthru patch

[Jeff Garzik]

Something that Alan unintentionally reminded me, about the libata 
passthru patch:  Some controllers require certain ATA commands to be 
synchronized at the host-wide level.

An example is SET FEATURES - XFER MODE on Promise controllers.  The 
controller snoops the taskfile for the xfer mode, and uses that info to 
program certain timing-related registers.  If you issue a SET FEATURES - 
XFER MODE command on one port while doing data xfer on another port, 
then data corruption can occur.

I'm pretty sure at least one other controller does similar taskfile 
snooping.

Currently probing is 100% synchronous, so our internal use of SET 
FEATURES - XFER MODE is safe.  But when you turn on ATA passthru, it is 
not safe.

This is another issue that needs fixing before we can merge the ATA 
passthru feature, since the consequences can be serious.

	Jeff

Re: A note on libata passthru patch

[Mark Lord]

I'm certain there are lots of vendor-specific commands
that might assume exclusive bus access, if not exclusive
host access.  All of this makes a reasonable case for
having libata stop other host activity before/while
performing any passthru command.

Cheers
-- 
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

Re: A note on libata passthru patch

[Jeff Garzik]

Mark Lord wrote:
> I'm certain there are lots of vendor-specific commands
> that might assume exclusive bus access, if not exclusive
> host access.  All of this makes a reasonable case for
> having libata stop other host activity before/while
> performing any passthru command.

We also have internal commands during error handling (and soon PM) to 
worry about, so its not as simple as that.  It implies a larger good at 
when we can queue commands, and how to synchronize them across multiple 
ports.  We need to do this for Simplex DMA, too.

	Jeff

Re: A note on libata passthru patch

[John W. Linville]

On Sun, Aug 21, 2005 at 05:37:18PM -0400, Jeff Garzik wrote:
> 
> Something that Alan unintentionally reminded me, about the libata 
> passthru patch:  Some controllers require certain ATA commands to be 
> synchronized at the host-wide level.

<snip>

> Currently probing is 100% synchronous, so our internal use of SET 
> FEATURES - XFER MODE is safe.  But when you turn on ATA passthru, it is 
> not safe.

...except that the passthru code specifically filters-out the SET
FEATURES - XFER MODE command. (libata_scsi.c:1976)
 
> This is another issue that needs fixing before we can merge the ATA 
> passthru feature, since the consequences can be serious.

I am by no means an expert either on ATA in general or on the oddities
and quirks of specific SATA controllers.  I don't know if anyone else
interested in the fate of the passthru patch is such an expert or not,
but either way it would likely be helpful to list any other specific
synchronization issues known to date which might be problematic.

Presuming that such a list either exists or is likely to exist, does
anyone have suggestions for what needs to be done in the general
case here?  Perhaps some infrastructure needs to be added to verify
that it is okay for the passthru stuff to issue a given command at a
given time on a given controller?  Sounds complicated...  Maybe some
infrastructure to quiesce _everything_ on the controller before
issuing a passthru command?  Just thinking "out loud"...

I'd like to help (and I'd like the passthru stuff to be "in"), but
I need some guidance...

John
-- 
John W. Linville
linville@tuxdriver.com