(correction - error is in SBC-3) Code error in SBC-3 Annex-C

Elliott, Robert (Server Storage) Elliott at hp.com
Wed Jan 4 08:04:18 PST 2006

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
Agilent had an SBC-2 letter ballot comment on odd byte handling in the
CRC; we decided to remove insertion of a pad byte of 00h that was shown
in a figure (which results in a different answer).  Brocade also had a
comment that led to "The block length is greater than or equal to one
byte and should be even" in 4.1.  Code to handle an odd length needs to
use special logic for the last byte (if implemented as XOR gates, the
XOR gates are different).

The simplest remedy would be to label the C code example as only
supporting an even numbers of bytes:

"The following is an example C program that generates the value for the
LOGICAL BLOCK GUARD field in protection information (see 4.16) <<for an
even number of bytes of user data>>."

Otherwise, someone will have to propose code modifications and
additional test case results.
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 

	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Sheffield, Robert L
	Sent: Tuesday, January 03, 2006 5:39 PM
	To: T10 Reflector
	Cc: George Penokie; pat.thaler at avagotech.com
	Subject: Code error in SBC-3 Annex-C

	One of our engineers found a code error in the CRC example code
in SBC-3 (Annex-C): 
	1) Page 161, C code line 1: This comment should contain SBC-3
instead of SBC-2. 
	2) Page 161, C code line 17: The C code frame[i+1] will fetch
garbage data and generate an incorrect CRC when the data length is odd.

	I suspect the normative CRC definition in deals with
the odd-byte condition. But I haven't checked to be certain.

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

More information about the T10 mailing list