> > 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. [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-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
