On Thu, Jan 12, 2012 at 4:57 PM, Jack Wang [off-list ref] wrote:

quoted

Hi Dan,

Thanks for your fix, I do test this with new patchset, this works good for
me.
Only one thing confuse me, kernel sometimes print cmd timed out when disk
attached.
Like :
"
[  312.732468] sd 4:0:11:0: [sdl] command ffff88032c6eaa00 timed out
[  312.753114] sd 4:0:13:0: [sdn] command ffff88032c6eb000 timed out
[  312.753257] sd 4:0:4:0: [sde] command ffff88032903e800 timed out
[  312.753266] sd 4:0:14:0: [sdo] command ffff880329284c00 timed out
[  312.755304] sd 4:0:1:0: [sdb] command ffff8801b4b80600 timed out
[  312.797458] sd 4:0:15:0: [sdp] command ffff880329285900 timed out
"
Although, this is no harm.

These were probably timeouts that were happening before but did not
get reported by the old sas_scsi_timed_out().

So, I'm still trying to figure out what to do about the "failure to
transmit signature-fis" case that you sent a patch to address.  I'm
wondering if we need to schedule rediscovery after a longer timeout?
I agree with skipping sas_set_ex_phy(), but for initial discovery it
would be nice to know that we have a device out there that is trying
to connect and hold off ->scan_finished() until libsas has given up on
waiting for that phy to settle.

For example libata will reset 3 times with increasing wait times (10s,
10s, 35s).  On the last attempt it will slow down the phy to give the
ata device a better chance of connecting.  libsas is just doing 3
500ms tries at full speed and then giving up.

[Jack Wang] 
Yes， in our internal test I expand the time to 10s, but I'm not sure this will be accepted by mainline kernel.

Wouldn't mind someone from libata land commenting on how libsas can be
more helpful to struggling sata devices.

"Let libata do it" would be my first choice, but at the point where we
are discovering this condition we don't yet have an ata_port, and
libsas only creates an ata_port *after* receiving a signature-fis.
Maybe we could create an unattached ata_port (i.e. with a stand-in
domain_device), but libsas would need to learn how to attach and probe
the domain_device after the fact.

--
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