Re: Re-sending a command

Thanks. I have pasted an example from Ken Sanders that is exactly the case I have seen when using the Microsoft initiator. The initiator then goes into a loop because every time it tries to reset, it sends the command again with the old CmdSN which itself causes a timeout and another reset.

Eddy


----- Original Message ----- 
From: Sandars, Ken 
To: Eddy Quicksall ; [email protected] 
Sent: Wednesday, August 09, 2006 7:42 PM
Subject: RE: [Ips] Re-sending a command


Hi Eddy,

There's some reading between the lines needed, but if this is scenario you are describing:

I->T: CmdSN=25 ITT=1 SCSI1
<time out period>
I->T: CmdSN=26 (immediate) ITT=2 TMF - LU Reset
T->I: ITT=2 ExpCmdSN=26 TMF Response - Function Complete
I->T: CmdSN=25 ITT=1 SCSI1

In this case, the target actions for the TMF - LU Reset will ensure that no responses will be sent for the affected commands (including CmdSN=25) after the TMF response is sent.

The initiator is in effect (re)sending a command outside the CmdSN window, and a working target will discard it.

HTH
Ken
  ----- Original Message ----- 
  From: Julian Satran 
  To: Eddy Quicksall 
  Cc: [email protected] ; Amit Kumar 
  Sent: Thursday, August 10, 2006 2:22 AM
  Subject: Re: [Ips] Re-sending a command



  Eddy, 

  The LU reset "plugs the holes" in command sequence and the old CmdSN should not be used (it is definitely an initiator bug). If you have seen it Mallikarjun may want to mention that dropping the command is the expected behavior of the target after all the task management commands that "plug the holes" in the implementation guide. 

  Julo 


        "Eddy Quicksall" <[email protected]> 
        10/08/06 01:34 
       To <[email protected]>  
              cc Amit Kumar <[email protected]>  
              Subject [Ips] Re-sending a command 

              

       



  It was brought to my attention that one initiator being tested will re-issue a "timed out" command using the same CmdSN after it has issued a LU Reset. When this happens the command is dropped. Note that this is on a single connection session. 
    
  I'm wondering if this could be an initiator bug or if there is a case where it is actually valid (in the report I have I don't know if the initiator also reissued the command with a valid CmdSN or not). 
    
  Does anyone know? 
    
  Eddy_______________________________________________
  Ips mailing list
  [email protected]
  https://www1.ietf.org/mailman/listinfo/ips




------------------------------------------------------------------------------


  _______________________________________________
  Ips mailing list
  [email protected]
  https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips