Hi Alex, On Fri, 2014-03-07 at 02:04 +0000, Alex Leung wrote: > Hi All, > > I'm working on getting task management functions working with the > Emulex OCS SDK FC/FCoE driver on LIO/TCM. I have a couple of questions > about the handling of ABORT_TASK and LUN_RESET. First, here's what I > see happening for ABORT_TASK: > > ABORT_TASK > ========== > > 1. target_submit_tmr() upcall from OCS fabric module to TCM > 2. target_tmr_work(): core_tmr_abort_task: loop through sess_cmd_list > a. if (tmr->ref_task_tag == get_task_tag) > i. cmd->transport_state |= CMD_T_ABORTED > ii. transport_send_task_abort(): > 1. cmd->scsi_status = SAM_STAT_TASK_ABORTED > 2. .queue_status() downcall > > It's not obvious to me why the queue_status() downcall would be made > with scsi_status = SAM_STAT_TASK_ABORTED. It would seem to imply that > an FCP_RESPONSE with status=40h should be sent on the wire for the > associated FCP_CMND. However, since an ABTS was received for the > command, no response will be sent for the FCP_CMND itself. Am I > reading this correctly? > Yes. It's up to the fabric driver to determine if a ->queue_status being called with SAM_STAT_TASK_ABORTED is sent over the wire, or should be completed internally. > The SAM_STAT_TASK_ABORTED status makes more sense to me in the context > of LUN_RESET, where the TAS bit (Control mode page) would apply. > > LUN_RESET > ========= > > 1. target_submit_tmr() upcall from OCS fabric module to TCM > 2. target_tmr_work(): core_tmr_lun_reset > a. core_tmr_drain_tmr_list() > b. core_tmr_drain_state_list(): for each command in dev->state_list > i. cmd->transport_state |= ABORTED > ii. core_tmr_handle_tas_abort() > 1. transport_send_task_abort() > > core_tmr_handle_tas_abort() has the following 'if' statement before > calling transport_send_task_abort(): > > if ((tmr_nacl && > (tmr_nacl == cmd->se_sess->se_node_acl)) || tas) > transport_send_task_abort(cmd); > > It makes sense that if TAS=1, the .queue_status downcall would be made > with scsi_status=SAM_STAT_TASK_ABORTED. However, I don't understand > the "(tmr_nacl && tmr_nacl == cmd->se_sess->se_node_acl)" part of this > statement. IIRC, this is because TAS only effects nexuses other than the nexus that received the LUN_RESET. > When I configure TAS=0 and send a LUN Reset, the tmr_nacl matches the > se_node_acl so the call to transport_send_task_abort() is made > regardless of "tas". I would think that if TAS=0, the > transport_send_task_abort() call would be skipped. What am I missing? > >From SPC-4's description of TAS: "A task aborted status (TAS) bit set to zero specifies that aborted commands shall be terminated by the device server without any response to the application client. A TAS bit set to one specifies that commands aborted by the actions of an I_T nexus other than the I_T nexus on which the command was received shall be completed with TASK ABORTED status (see SAM-4)." My understanding wrt to TAS has been that it only effects nexuses other than the one that received the LUN_RESET. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
