On Thu, Jan 12, 2012 at 4:57 PM, Jack Wang <jack_wang@xxxxxxxxx> wrote: > 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. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
