Subject: [Ips] Handling Expected-data-transfer-legnth and CDB transfer-len mismatch

From: "Qi, Yanling" <[email-masked]>
Date: Mon, 14 May 2007 15:29:43 -0600

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-masked]

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

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 24 May 2007 00:31:08 -0400

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-masked] 
  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

  512-794-3713 (Office)

  512-794-3702 (Fax)

  [email-masked]

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