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

pat.thaler at avagotech.com pat.thaler at avagotech.com
Wed Jan 4 14:32:08 PST 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* <pat.thaler at avagotech.com>
*
The normative text works fine for odd numbers of bytes. It is a mathematical definition of CRC based on the polynomial that the message represents. In theory, it would even work for a message (i.e. block) that wasn't a whole number of bytes. 

The change to make the C code work correctly for an odd number of bytes isn't terribly hard, but since block length is expected to be even and we have text in 4.1 that says the block length "should" be even, there is little value in modifying the code. 

Therefore, I suggest we use the remedy Rob suggests and add a statement to Annex C saying that the example C program applies only when the block size is even. 

If we wanted to change the code, one way to implement the change would be to replace:
  for (i = 0; i < length; i += 2)
with 
  for (i = 0; i < length + 1; i += 2) 
so that the test only passes when there are at least two byte remaining.
After that loop, insert a test for i < length (which would mean there is an odd byte to deal with). If the test passes execute:
x = (frame[i] << 8) | 0x00; 
/* serial shift register implementation */
for (j = 0; j < 8; j++) {
fb = ((x & 0x8000L) == 0x8000L) ^ ((crc_gen & 0x8000L) ==
0x8000L);
x <<= 1;
crc_gen <<= 1;
if (fb)
crc_gen ^= poly;
}

However, I don't think we should make this change.
Regards,
Pat

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Elliott, Robert (Server Storage)
Sent: Wednesday, January 04, 2006 8:04 AM
To: T10 Reflector
Subject: RE: (correction - error is in SBC-3) Code error in SBC-3 Annex-C

* 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 
https://ecardfile.com/id/RobElliott 

 
	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 4.16.4.2 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


*
* 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