(digging through old email)
Darrick J. Wong wrote:
On Tue, Dec 04, 2007 at 05:48:33PM -0500, Jeff Garzik wrote:
As an aside, issues like this really really imply a need to move libsas
away from the old libata EH stuff (like brking did with ipr, in patches).
Hm... does the new libata EH handle the case of "device was
unplugged, don't bother trying to send any more commands"?
Yes, most certainly :) We wouldn't have hotplug support without that...
In general, I agree that sas-ata should adopt the new EH.
Unfortunately, I believe the old way of sas-ata configuring ATA ports is
somehow not compatible with the new EH stuff and causes a crash during
the device probe with my patch to move sas-ata to the new EH. If I
apply the patch that migrates sas-ata to use brking's latest ata-sas
configuration mechanism (the one that creates real ata_hosts), I see
(a) lots and lots of ATA hosts getting created (one per ATA port;
possibly undesirable if you've a SAS topology with a lot of SATA disks)
and (b) NCQ disks don't seem to work if you unplug the disk and plug
it back in (unless NCQ is disabled entirely). Jeff, by any chance have
you tried plugging SATA devices into your SAS controllers?
Just tested mvsas here...
James Bottomley wondered if it would be easier to have sas-ata call only
into the parts of libata that convert SCSI commands to ATA taskfiles,
though I'm unsure how many wormy cans that would open.
Like Brian K noted, libata-EH is heavily involved in "anything not
hotpath read/write", including but not limited to: PMP, hotplug, device
probing, device revalidation, explicit sequencing of ATA commands during
initialization (critical for getting many ATA devices working)
You don't want to reinvent or duplicate all those ATA device
initialization/revalidation quirks.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
