David C Somayajulu wrote:
On Wed, 2008-04-30 at 14:36 -0500, Mike Christie wrote:
Mike Christie wrote:
David C Somayajulu wrote:
+ }
+ if (sshdr.asc == 0x3f && sshdr.ascq == 0x0e) {
+ /* induce rescan */
+ iscsi_block_session(ddb_entry->sess);
+ iscsi_unblock_session(ddb_entry->sess);
+ }
I think I was wrong off list. We could actually just call
iscsi_unblock_session, but we do not know the state of the session do
we? If we got a event that indicated the session was failed could we
have a block queued up and this would reverse it by accident?
I was thinking that because qla4xxx_process_aen is called before this we
could just check the ddb state, but we can call iscsi_block_session from
the interrupt handler to queue up a block so I think that could race
with the unblock call here.
Maybe to handle the race we do not want to call qla4xxx_mark_device_busy
when we get SCS_TIMEOUT. If we get a ddb aen then could we just wait for
that and all those events would be serialized through the dpc thread?
What does SCS_TIMEOUT mean?
I think the driver on receiving the Async Message PDU of type
ISCSI_ASYNC_MSG_SCSI_EVENT, should first retrieve the DDB state. If the
session is still not active, it should block it. If the DDB state
You should not need to block it though. qla4xxx_process_aen will have
done this already when it set the ddb state, wouldn't it? I am saying if
the ddb state indicates that it is not active then the session should be
in the blocked state by the time we get to handling the iscsi async event.
indicates the session is active, then call iscsi_unblock_session() if
rescan is needed. What do you think of this solution ?
SCS_TIMEOUT is generated when there is a transport layer timeout for one
of the PDUs issued as result of an IOCB.
Do you need some locking or something then? If the dpc thread is about
to check the ddb state to handle the iscsi async pdu like we said above,
then we get a SCS_TIMEOUT, could the dpc thread read the ddb state and
see a good ddb state, then the SCS_TIMEOUT handling would set the state
to DDB_STATE_MISSING and queue a block. The dpc thread would then queue
a unblock early?
--
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
