Re: [PATCH v8 08/13] libsas: libsas.force_hard_reset module parameter
From: Dan Williams <hidden>
Date: 2012-02-29 23:27:55
Also in:
linux-scsi
On Wed, Feb 29, 2012 at 2:40 PM, Douglas Gilbert [off-list ref] wrote:
On 12-02-29 04:55 PM, James Bottomley wrote:quoted
On Fri, 2012-02-10 at 00:45 -0800, Dan Williams wrote:quoted
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html