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