On Wed, 28 Jul 2010, James Smart wrote: > Mike Christie wrote: > > Hi FC driver developers, > > > > I am trying to figure out what is the correct behavior when setting > > dev_loss_tmo. > > > > With lpfc, qla2xx, and ibmfc if I set dev_loss_tmo using > > /sys/class/fc_remote_port/rport-xx/dev_loss_tmo, and then we add devices > > the slave_configure functions for these drivers reset the dev_loss_tmo > > to a driver value. > > > > The addition of devs could be from something like a user rescan, or from > > a scan started by a remote port addition. > > Looking at lpfc - this is a totally insane thing to do, and definitely a bug. > Addition or removal of sdevs should not change a rport setting. Completely agree... > > With fcoe, fnic, mptfc, bfa and zfcp the dev_loss_tmo value set from > > sysfs will not be reset by a driver value on rescans. > > > > Which drivers should be changed? > > lpfc, qla2xx, and ibmfc. I'm curious though, each driver would still need to seed the rport's dev_loss_tmo value (in the case of qla2xxx, ha->port_down_retry_count), but, by doing so after rport-addition (fc_remote_port_add()), the driver could still overwrite a previous sysfs setting. Internally, upon rport creation, the dev_loss_tmo value is seeding with fc_dev_loss_tmo (a module parameter -- 60 seconds). Should we extend the transport so the the 'default seeding value' can be specified once at fc_host creation-time? BTW: fnic looks to be doing the same 'bad' behaviour in their slave_alloc() call too... -- av -- 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
