iSCSI/luns/check-condition

[William Studenmund]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 25, 2006, at 2:28 AM, Danny Braniss wrote:

>> Danny,
>>
>> LUN 1 should not be returning a chk condition in response to an  
>> INQUIRY
>> command with the page code and EVPD both 0 in the cdb.  The device
>> server should return the inquiry response data with the peripheral
>> device qualifier set to 001b or 011b (1 or 3) per the scsi specs.
>>
>> Bill
>>
> hi Bill,
>   that's 'wishfull thinking' :-), I can only fix the initiator, the  
> target
>   I have to live with :-(

Actually, I believe the target is behaving correctly. See below.

>> -----Original Message-----
>> From: owner-freebsd-scsi at freebsd.org
>> [mailto:owner-freebsd-scsi at freebsd.org] On Behalf Of Kenneth D. Merry
>> Sent: Thursday, August 24, 2006 11:15 AM
>> To: Danny Braniss
>> Cc: scsi at freebsd.org
>> Subject: Re: iSCSI/luns/check-condition
>>
>> On Thu, Aug 24, 2006 at 18:05:41 +0300, Danny Braniss wrote:
>>> hi,
>>> 	this target (Wasabi) is returning Check Condition for
>>> a INQ. LUN 1, (which probably is ok,  since it does not exist), I
>> return
>>> 	ccb_h->status = CAM_SCSI_STATUS_ERROR;
>>> but it seems that the CAM is ignoring it, since it will try  
>>> again, and
>>> again, etc. [or i'm doing something wrong :-]
>>
>> If this is a result of the inquiry on initial probe (most likely),  
>> you
>> shouldn't get any more than 4 retries.
>>
>> What SCSI status byte, sense key, ASC and ASCQ are you returning?

You really need to answer this question. It's always the first thing  
to do when trying to figure out a SCSI issue.

The only non-good status the target will give out of this command is  
Check Condition, Illegal request, Invalid Field in CDB (ASC/Q  
0x24/0x00). It will also give you a sense-key-specific field  
indicating which byte upset the target.

So fire up wireshark and see what's going on.

Nothing happens to be trying to put the LUN in bits 5 through 7 of  
byte 1 perchance? They have been reserved since SPC2 or earlier.  
Trying to put the LUN there will cause the issue you're seeing.

Take care,

Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFE7yulDJT2Egh26K0RApKHAJ9H1IKB2zzBh9ZDF3QeIpTG4HrCeQCcDdlL
WQa7cQqEAZkee7T0RYF/RqQ=
=XOxS
-----END PGP SIGNATURE-----