Hi All, I guess I should start with a more fundamental question: When Abort Task or LUN Reset is received (Clear Task Set, Abort Task Set unsupported by LIO), what is the "official" notification from LIO to the fabric module to notify the fabric module that the given command has been aborted and needs to be cleaned up (on the chip)? Is it simply tfo->queue_status() with the CMD_T_ABORTED transport_state bit set in the se_cmd? Thanks and regards, Alex > -----Original Message----- > From: target-devel-owner@xxxxxxxxxxxxxxx [mailto:target-devel- > owner@xxxxxxxxxxxxxxx] On Behalf Of Alex Leung > Sent: Thursday, March 06, 2014 6:04 PM > To: target-devel@xxxxxxxxxxxxxxx > Subject: Task Management handling and TAS > > 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? > > 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. 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? > > Any help would be greatly appreciated. > > Regards, > Alex > > P.S. I'm using the memcopy ramdisk backstore on the 3.13.3 kernel. > > -- > 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 -- 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
