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