Re: [GIT PATCH v4 0/2] libsas: eh reworks (ata-eh vs discovery, races, ...)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux