From: James Smart <james.smart@emulex.com>
To: Mike Christie <michaelc@cs.wisc.edu>
Cc: "brking@linux.vnet.ibm.com" <brking@linux.vnet.ibm.com>,
Andrew Vasquez <andrew.vasquez@qlogic.com>,
SCSI Mailing List <linux-scsi@vger.kernel.org>,
"Desai, Kashyap" <Kashyap.Desai@lsi.com>,
Giridhar Malavali <giridhar.malavali@qlogic.com>,
Christof Schmitt <christof.schmitt@de.ibm.com>,
"Love, Robert W" <robert.w.love@intel.com>,
Jing Huang <huangj@Brocade.COM>,
"Smart, James" <James.Smart@Emulex.Com>
Subject: Re: dev_loss_tmo behavior question
Date: Wed, 28 Jul 2010 12:07:06 -0400 [thread overview]
Message-ID: <4C5055AA.7080703@emulex.com> (raw)
In-Reply-To: <4C4F4B94.1070009@cs.wisc.edu>
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.
>
> 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.
-- james s
next prev parent reply other threads:[~2010-07-28 16:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-27 21:11 dev_loss_tmo behavior question Mike Christie
2010-07-28 8:45 ` Christof Schmitt
2010-07-28 16:07 ` James Smart [this message]
2010-07-28 16:57 ` Andrew Vasquez
2010-07-30 17:21 ` Mike Christie
2010-07-30 17:28 ` James Smart
2010-07-30 22:15 ` Andrew Vasquez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C5055AA.7080703@emulex.com \
--to=james.smart@emulex.com \
--cc=Kashyap.Desai@lsi.com \
--cc=andrew.vasquez@qlogic.com \
--cc=brking@linux.vnet.ibm.com \
--cc=christof.schmitt@de.ibm.com \
--cc=giridhar.malavali@qlogic.com \
--cc=huangj@Brocade.COM \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
--cc=robert.w.love@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.