Re: Handling Expected-data-transfer-legnth and CDB transfer-lenmismatch

"Eddy Quicksall" <[email protected]> Thu, 24 May 2007 00:31:08 -0400
Newsgroups gmane.ietf.ips
Message-ID <[email protected]>
Looking at the trace, the initiator sent 0x2000 bytes of immediate data. The target did not request anymore data because the count was 0. So U with a residual of 0x4000 is correct. The target would just discard the immediate data. It is legal to write 0 bytes with a WRITE (10) and WRITE AND VERITY (10) refers back to that. 

The iSCSI layer is not required to check the Expected Data Transfer Length against the CDB (to do so would require that the iSCSI layer understand all of the CDB's). I don't recall seeing any requirement for the Device Server to check the CDB against the Expected Data Transfer Length either.

Eddy
  ----- Original Message ----- 
  From: Qi, Yanling 
  To: [email protected] 
  Cc: Qi, Yanling 
  Sent: Monday, May 14, 2007 5:29 PM
  Subject: [Ips] Handling Expected-data-transfer-legnth and CDB transfer-lenmismatch


  Hi All,

   

  We saw an initiator problem where the expected-data-transfer-length and transfer-len inside CDB got mismatched for a write-and-verify (10). The expected-data-transfer-length is 0x4000 but the transfer-len in the CDB is 0. The target completed the request with good status, turned Residual-underflow bit on and set residual-count=0x4000. See frames 16 and 38 in the attached ethereal trace file for details. Did the target handle this error condition correctly?

   

  Thanks,

   

  --yanling

   

  Yanling Qi

  Engenio Storage Group - LSI Logic

  512-794-3713 (Office)

  512-794-3702 (Fax)

  [email protected]

   



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


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

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