On Wed, Feb 29, 2012 at 2:40 PM, Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote: > On 12-02-29 04:55 PM, James Bottomley wrote: >> >> On Fri, 2012-02-10 at 00:45 -0800, Dan Williams wrote: >>> >>> It is possible for a host to get "locked out" from talking to sata >>> devices in the domain if, for example, its sas address changes but the >>> expander topology has existing affiliations with the old address. If >>> the system is booted userspace can write to >>> /sys/class/sas_phy/<phy-X>/hard_reset to clear the affiliation, however >>> if this condition exists for the root device the module parameter can be >>> used to promote all ata resets to hard resets. > > > A point of order: SAS has link resets and hard resets. The > hard reset is a superset of link reset. A "link reset sequence > serves as a hard reset for SATA devices" and hence is > sufficient to reset a SATA device. To reset a SAS device > (e.g. a SAS disk) you need a SAS hard reset. Therefore a link > reset is the appropriately sized "gun" to reset a SATA device. > > I have a SAS-2 expander that annoyingly powers up with the > programmed maximum physical link rate of its phys at 3 Gbps > even though its hardware maximum rate is 6 Gbps. For expander > phys connected to SAS-2 disks I can up the programmed maximum > value to 6 Gbps on the expander phy then do a link reset on > that phy. So without upsetting Linux (or any other OS) I can > switch that path from 3 Gbps to 6 Gbps. Can't do that with a > SATA disk without the OS finding out. At least now (with these pending patches) if you trigger a link-reset via the sysfs interface libsas will manage the link recovery like any other error-recovery initiated reset. Something like a libsas.force_max_phys_link_rate module parameter might not be a bad idea for this scenario, since libsas sata discovery always forces at least one reset of the disk after the phy reports "attached sata device". -- Dan -- 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
