View Single Post
Old 08 September 2016, 13:36   #5
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
Quote:
Originally Posted by Toni Wilen View Post
I am sure yet sure if I bother, SASI "support" was not really "designed" for any corner cases or unexpected errors and there is also no guarantee drivers even handle it correctly (this is really unexpected case!) which can make testing impossible.
It should be quite simple to "fix" the REQUEST SENSE behaviour though.

After reading the Xebec manual and SASI draft specs, I think I know what the problem was. The Xebec controller always returns 4 bytes in response to REQUEST SENSE.

In the SCSI spec, byte 4 of the REQUEST SENSE CDB is the allocation length. The drive returns up to that number of bytes in response. SASI-revC_Jan82.pdf (p.39) says:
The "No. of blocks byte" in the
command will determine the length, in
bytes, to be returned to the host.
0 = 4 bytes
1-255 = as indicated


So there's a special case where the allocation length byte is 0; the drive should return 4 bytes then.

The description of REQUEST SENSE STATUS in the Xebec manual (104478B_S1410A_Feb84.pdf document p.42, PDF p.49) says CDB bytes 2-5 are "don't care" (and byte 1 bits [4:0] too). The controller always returns 4 bytes.

That Xebec controller behaviour is probably the reason for the "0 means 4 bytes" special case in the SASI spec. X3T9.3_185_RevE_SASI_Apr82.pdf has similar wording (document p.35, PDF p.40):
0 = 4 bytes. To be compatible with existing initiators. Future initiators will specify in byte 04 the number of bytes allocated for sense data (e.g., 1 to 255 bytes).

When emulating a SASI drive (or more specifically Xebec S1410A controller), it could be sufficient to:
- If CDB byte 4 is 0, return 4 bytes. [Probably better to just ignore CDB byte 4 and always return 4 bytes to better match Xebec behaviour, in case some driver sends commands with byte 4 non-zero.]
- The error code in the first byte returned seems to match the ASC in SCSI sense data; e.g. $21 means illegal disk address.
mark_k is online now  
 
Page generated in 0.05020 seconds with 9 queries