On 11/18/2010 01:25 PM, Eddie Wai wrote:
On Wed, 2010-11-17 at 19:40 -0800, Mike Christie wrote:
On 11/10/2010 05:04 PM, Eddie Wai wrote:
In the case the chip is undergoing different invasive operation
which requires a chip reset, all NOPOUT request during this period
For these invasive operations that reset the chip, do we always end up
having to relogin the connection/session or once the reset is done are
we able to just go on happily like nothing ever happened?
Operations like mtu change/ifupdown/etc will require the chip to undergo
reset. Prior to this, the connections will be cleaned up via the
conn_failure->ep_disconnect path and eventually put into the reopen
recovery path. During this period, we must disallow any send pdu
requests to be queued to the chip for a more immediately connection tear
down time (so we don't have to wait for the pdu's completion).
We had to treat NOPOUT requests differently as the routine in libiscsi
would continuously loop until the NOPOUT send request returns with
success. This is the why we added the NOPOUT workaround.
At this time, have you already called iscsi_conn or session failure? If
so then I think it sounds like there is bug in iscsi_send_nopout or
__iscsi_conn_send_pdu. If the conn/session has been failed, I think we
want to add a check in __iscsi_conn_send_pdu where if the conn/session
is down then we do not send NOPs. There is no point iSCSI RFC wise and
it screws up drivers.
--
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
