Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Aug 2006 09:56:00 -0700
From:      William Studenmund <>
To:        Danny Braniss <>
Cc:        "'Kenneth D. Merry'" <>,
Subject:   Re: iSCSI/luns/check-condition 
Message-ID:  <>
In-Reply-To: <>
References:  <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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  
>> 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:
>> [] On Behalf Of Kenneth D. Merry
>> Sent: Thursday, August 24, 2006 11:15 AM
>> To: Danny Braniss
>> Cc:
>> 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,

Version: GnuPG v1.4.1 (Darwin)


Want to link to this message? Use this URL: <>