iSCSI/luns/check-condition

> 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 :-(
	danny

> -----Original Message-----
> From: owner-freebsd-scsifreebsd.org
> [mailto:owner-freebsd-scsifreebsd.org] On Behalf Of
Kenneth D. Merry
> Sent: Thursday, August 24, 2006 11:15 AM
> To: Danny Braniss
> Cc: scsifreebsd.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?
> 
> Ken
> --
> Kenneth Merry
> kenFreeBSD.ORG
> _______________________________________________
> freebsd-scsifreebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to
"freebsd-scsi-unsubscribefreebsd.org"
> 
> 


_______________________________________________
freebsd-scsifreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to
"freebsd-scsi-unsubscribefreebsd.org"

-----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-scsifreebsd.org
>> [mailto:owner-freebsd-scsifreebsd.org] On Behalf Of
Kenneth D. Merry
>> Sent: Thursday, August 24, 2006 11:15 AM
>> To: Danny Braniss
>> Cc: scsifreebsd.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)

iD8DBQFE7yulDJT2Egh26K0RApKHAJ9H1IKB2zzBh9ZDF3QeIpTG4HrCeQCc
DdlL
WQa7cQqEAZkee7T0RYF/RqQ=
=XOxS
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-scsifreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to
"freebsd-scsi-unsubscribefreebsd.org"

> >> 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-scsifreebsd.org
> >> [mailto:owner-freebsd-scsifreebsd.org] On Behalf Of Kenneth D. Merry
> >> Sent: Thursday, August 24, 2006 11:15 AM
> >> To: Danny Braniss
> >> Cc: scsifreebsd.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?
> 
whatever the target sent , hopefully
i'm picking it up correctly.
the code is at the end.

> 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.
> 
this is the INQ:
iSCSI (SCSI Command)
    Opcode: SCSI Command (0x01)
    .0.. .... = I: Queued delivery
    Flags: 0xc1
        1... .... = F: Final PDU in sequence
        .1.. .... = R: Data will be read from target
        ..0. .... = W: No data will be written to target
        .... .001 = Attr: Simple (0x01)
    TotalAHSLength: 0x00
    DataSegmentLength: 0x00000000
    LUN: 0001000000000000
    InitiatorTaskTag: 0x0000000d
    ExpectedDataTransferLength: 0x00000024
    CmdSN: 0x0000000c
    ExpStatSN: 0x0000000d
    Response in: 48
SCSI CDB
    LUN: 0x0001
    Opcode: Inquiry (0x12)
    CMDT = 0, EVPD = 0
    Allocation Length: 36
    Vendor Unique = 0, NACA = 0, Link = 0

0000  00 04 38 a0 c6 07 00 30 1b b1 31 91 08 00 45 00  
..8....0..1...E.
0010  00 64 a5 ff 40 00 40 06 66 6d 84 41 50 d3 54 0c  
.d....fm.AP.T.
0020  05 07 db d6 0c bc 02 55 c5 d1 76 84 38 de 80 18  
.......U..v.8...
0030  82 18 51 2a 00 00 01 01 08 0a 03 cd d9 01 00 00  
..Q*............
0040  00 04 01 c1 00 00 00 00 00 00 00 01 00 00 00 00  
................
0050  00 00 00 00 00 0d 00 00 00 24 00 00 00 0c 00 00  
.........$......
0060  00 0d 12 20 00 00 24 00 00 00 00 00 00 00 00 00   ...
..$.........
0070  00 00                                             ..

and this is the response:
iSCSI (SCSI Response)
    Opcode: SCSI Response (0x21)
    Flags: 0x80
        ...0 .... = o: No overflow of read part of
bi-directional command
        .... 0... = u: No underflow of read part of
bi-directional command
        .... .0.. = O: No residual overflow occurred
        .... ..0. = U: No residual underflow occurred
    Response: Command completed at target (0x00)
    Status: Check Condition (0x02)
    TotalAHSLength: 0x00
    DataSegmentLength: 0x00000014
    InitiatorTaskTag: 0x0000000d
    StatSN: 0x0000000e
    ExpCmdSN: 0x0000000d
    MaxCmdSN: 0x00000014
    ExpDataSN: 0x00000000
    BidiReadResidualCount: 0x00000000
    ResidualCount: 0x00000000
    Request in: 45
    Time from request: 0.081560000 seconds
    SenseLength: 0x0012
SCSI: SNS Info
    LUN: 0x0001
    Valid: 1
    .111 0000 = SNS Error Type: Current Error (0x70)
    Filemark: 0, EOM: 0, ILI: 0
    .... 0101 = Sense Key: Illegal Request (0x05)
    Sense Info: 0x00000000
    Additional Sense Length: 10
    Command-Specific Information: 00000000
    Additional Sense Code+Qualifier: Invalid Field In Cdb
(0x2400)
    Field Replaceable Unit Code: 0x00
    .. = SKSV: True
    Sense Key Specific: C00001

0000  00 30 1b b1 31 91 00 04 38 a0 c6 07 08 00 45 00  
.0..1...8.....E.
0010  00 78 91 60 40 00 2f 06 8b f8 54 0c 05 07 84 41  
.x.`./...T....A
0020  50 d3 0c bc db d6 76 84 3d 3e 02 55 c6 01 80 18  
P.....v.=>.U....
0030  ff ff cb 19 00 00 01 01 08 0a 00 00 00 05 03 cd  
................
0040  d9 01 21 80 00 02 00 00 00 14 00 00 00 00 00 00  
..!.............
0050  00 00 00 00 00 0d 00 00 00 00 00 00 00 0e 00 00  
................
0060  00 0d 00 00 00 14 00 00 00 00 00 00 00 00 00 00  
................
0070  00 00 00 12 f0 00 05 00 00 00 00 0a 00 00 00 00  
................
0080  24 00 00 c0 00 01                                
$.....

> 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.
> 
I don't deal with the ccb, it's the cam.


> Take care,
> 
> Bill

the code:
static void
getSenseData(u_int status, union ccb *ccb, pduq_t *pq)
{
     pdu_t		*pp = &pq->pdu;
     struct		ccb_scsiio *scsi = (struct ccb_scsiio *)ccb;
     struct		scsi_sense_data *sense =
&scsi->sense_data;
     struct		ccb_hdr	*ccb_h = &ccb->ccb_h;
     caddr_t		bp = mtod(pq->mp, caddr_t);
     struct mbuf	*m = pq->mp;
     scsi_rsp_t		*cmd = &pp->ipdu.scsi_rsp;
     int		sense_len, mustfree = 0;

     sense_len = scsi_2btoul(bp);
     /*
      | according to the specs, the sense data cannot
      | be larger than 252 ...
      */
     if(sense_len > m->m_len) {
	  bp = malloc(sense_len, M_ISCSI, M_WAITOK);
	  debug(3, "calling i_mbufcopy(len=%d)",
sense_len);
	  i_mbufcopy(pq->mp, bp, sense_len);
	  mustfree++;
     }
     scsi->scsi_status = status;

     bcopy(bp+2, sense, min(sense_len, scsi->sense_len));
     scsi->sense_resid = 0;
     if(cmd->flag & (BIT(1)|BIT(2)))
	  scsi->sense_resid = ntohl(pp->ipdu.scsi_rsp.rcnt);
     debug(3, "sense_len=%d rcnt=%d sense_resid=%d
dsl=%d error_code=%x 
flags=%x",
	   sense_len,
	   ntohl(pp->ipdu.scsi_rsp.rcnt), scsi->sense_resid,
	   pp->ds_len, sense->error_code, sense->flags);

     ccb_h->status |= CAM_AUTOSNS_VALID;

     if(mustfree)
	  free(bp, M_ISCSI);
}

thanks,
	danny


_______________________________________________
freebsd-scsifreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to
"freebsd-scsi-unsubscribefreebsd.org"

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

On Aug 25, 2006, at 11:22 AM, Danny Braniss wrote:

>>>> 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?
>>
> whatever the target sent , hopefully
i'm picking it up correctly.
> the code is at the end.
>
>> 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.
>>
> this is the INQ:
> iSCSI (SCSI Command)
>     Opcode: SCSI Command (0x01)
>     .0.. .... = I: Queued delivery
>     Flags: 0xc1
>         1... .... = F: Final PDU in sequence
>         .1.. .... = R: Data will be read from target
>         ..0. .... = W: No data will be written to
target
>         .... .001 = Attr: Simple (0x01)
>     TotalAHSLength: 0x00
>     DataSegmentLength: 0x00000000
>     LUN: 0001000000000000

Ok! You're setting the LUN right.

>     InitiatorTaskTag: 0x0000000d
>     ExpectedDataTransferLength: 0x00000024
>     CmdSN: 0x0000000c
>     ExpStatSN: 0x0000000d
>     Response in: 48
> SCSI CDB
>     LUN: 0x0001
>     Opcode: Inquiry (0x12)
>     CMDT = 0, EVPD = 0
>     Allocation Length: 36
>     Vendor Unique = 0, NACA = 0, Link = 0
>
> 0000  00 04 38 a0 c6 07 00 30 1b b1 31 91 08 00 45 00  
.. 
> 8....0..1...E.
> 0010  00 64 a5 ff 40 00 40 06 66 6d 84 41 50 d3 54  
> 0c   .d....fm.AP.T.
> 0020  05 07 db d6 0c bc 02 55 c5 d1 76 84 38 de 80 18  
.......U..v. 
> 8...
> 0030  82 18 51 2a 00 00 01 01 08 0a 03 cd d9 01 00  
> 00   ..Q*............
> 0040  00 04 01 c1 00 00 00 00 00 00 00 01 00 00 00  
> 00   ................
> 0050  00 00 00 00 00 0d 00 00 00 24 00 00 00 0c 00 00  
......... 
> $......
> 0060  00 0d 12 20 00 00 24 00 00 00 00 00 00 00 00 00  
... .. 
> $.........
                 ^^

[I hope that comes out right, my mailer is using a
variable-width font]

Note the cdb is 12 20 00 00 24 00. The 20 is where something
stored  
LUN 1, and it is what the target dislikes.

> 0070  00 00                                            
..
>
> and this is the response:
> iSCSI (SCSI Response)
>     Opcode: SCSI Response (0x21)
>     Flags: 0x80
>         ...0 .... = o: No overflow of read part of
bi-directional  
> command
>         .... 0... = u: No underflow of read part of
bi-directional  
> command
>         .... .0.. = O: No residual overflow occurred
>         .... ..0. = U: No residual underflow occurred
>     Response: Command completed at target (0x00)
>     Status: Check Condition (0x02)
>     TotalAHSLength: 0x00
>     DataSegmentLength: 0x00000014
>     InitiatorTaskTag: 0x0000000d
>     StatSN: 0x0000000e
>     ExpCmdSN: 0x0000000d
>     MaxCmdSN: 0x00000014
>     ExpDataSN: 0x00000000
>     BidiReadResidualCount: 0x00000000
>     ResidualCount: 0x00000000
>     Request in: 45
>     Time from request: 0.081560000 seconds
>     SenseLength: 0x0012
> SCSI: SNS Info
>     LUN: 0x0001
>     Valid: 1
>     .111 0000 = SNS Error Type: Current Error (0x70)
>     Filemark: 0, EOM: 0, ILI: 0
>     .... 0101 = Sense Key: Illegal Request (0x05)
>     Sense Info: 0x00000000
>     Additional Sense Length: 10
>     Command-Specific Information: 00000000
>     Additional Sense Code+Qualifier: Invalid Field In
Cdb (0x2400)
>     Field Replaceable Unit Code: 0x00
>     .. = SKSV: True
>     Sense Key Specific: C00001

Ok. This indicates that the SKSV is valid, the error is in
the CDB,  
BPV is clear, and the error is in field 1 (byte 1).

> 0000  00 30 1b b1 31 91 00 04 38 a0 c6 07 08 00 45 00  
. 
> 0..1...8.....E.
> 0010  00 78 91 60 40 00 2f 06 8b f8 54 0c 05 07 84  
> 41   .x.`./...T....A
> 0020  50 d3 0c bc db d6 76 84 3d 3e 02 55 c6 01 80 18  
 
> P.....v.=>.U....
> 0030  ff ff cb 19 00 00 01 01 08 0a 00 00 00 05 03  
> cd   ................
> 0040  d9 01 21 80 00 02 00 00 00 14 00 00 00 00 00  
> 00   ..!.............
> 0050  00 00 00 00 00 0d 00 00 00 00 00 00 00 0e 00  
> 00   ................
> 0060  00 0d 00 00 00 14 00 00 00 00 00 00 00 00 00  
> 00   ................
> 0070  00 00 00 12 f0 00 05 00 00 00 00 0a 00 00 00  
> 00   ................
> 0080  24 00 00 c0 00 01                                
$.....
>
>> 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.
>>
> I don't deal with the ccb, it's the cam.

Hmm... I'm not sure how to fix this then. The problem is
that the  
specs indicate that this is no longer valid. They do not
indicate  
obsolete (the "obsolete" term exists for that),
they are invalid  
("reserved in SPC2). There are test suites (which have
been run  
against us) that make sure the use of any
"reserved" bit causes an  
error.

Take care,

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

iD8DBQFE70NhDJT2Egh26K0RAryAAJ9gJfAXrrjgDQiPZGndteYW2enBlwCg
oELv
ZPF6+D6mcbS2UY7AZSxjvBM=
=DvCU
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-scsifreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to
"freebsd-scsi-unsubscribefreebsd.org"

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Aug 25, 2006, at 11:22 AM, Danny Braniss wrote:
> 
> >>>> 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?
> >>
> > whatever the target sent , hopefully
i'm picking it up correctly.
> > the code is at the end.
> >
> >> 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.
> >>
> > this is the INQ:
> > iSCSI (SCSI Command)
> >     Opcode: SCSI Command (0x01)
> >     .0.. .... = I: Queued delivery
> >     Flags: 0xc1
> >         1... .... = F: Final PDU in sequence
> >         .1.. .... = R: Data will be read from
target
> >         ..0. .... = W: No data will be written to
target
> >         .... .001 = Attr: Simple (0x01)
> >     TotalAHSLength: 0x00
> >     DataSegmentLength: 0x00000000
> >     LUN: 0001000000000000
> 
> Ok! You're setting the LUN right.
> 
> >     InitiatorTaskTag: 0x0000000d
> >     ExpectedDataTransferLength: 0x00000024
> >     CmdSN: 0x0000000c
> >     ExpStatSN: 0x0000000d
> >     Response in: 48
> > SCSI CDB
> >     LUN: 0x0001
> >     Opcode: Inquiry (0x12)
> >     CMDT = 0, EVPD = 0
> >     Allocation Length: 36
> >     Vendor Unique = 0, NACA = 0, Link = 0
> >
> > 0000  00 04 38 a0 c6 07 00 30 1b b1 31 91 08 00 45
00   .. 
> > 8....0..1...E.
> > 0010  00 64 a5 ff 40 00 40 06 66 6d 84 41 50 d3 54
 
> > 0c   .d....fm.AP.T.
> > 0020  05 07 db d6 0c bc 02 55 c5 d1 76 84 38 de 80
18   .......U..v. 
> > 8...
> > 0030  82 18 51 2a 00 00 01 01 08 0a 03 cd d9 01 00
 
> > 00   ..Q*............
> > 0040  00 04 01 c1 00 00 00 00 00 00 00 01 00 00 00
 
> > 00   ................
> > 0050  00 00 00 00 00 0d 00 00 00 24 00 00 00 0c 00
00   ......... 
> > $......
> > 0060  00 0d 12 20 00 00 24 00 00 00 00 00 00 00 00
00   ... .. 
> > $.........
>                  ^^
> 
> [I hope that comes out right, my mailer is using a
variable-width font]
> 
> Note the cdb is 12 20 00 00 24 00. The 20 is where
something stored  
> LUN 1, and it is what the target dislikes.
> 
> > 0070  00 00                                       
     ..
> >
> > and this is the response:
> > iSCSI (SCSI Response)
> >     Opcode: SCSI Response (0x21)
> >     Flags: 0x80
> >         ...0 .... = o: No overflow of read part of
bi-directional  
> > command
> >         .... 0... = u: No underflow of read part
of bi-directional  
> > command
> >         .... .0.. = O: No residual overflow
occurred
> >         .... ..0. = U: No residual underflow
occurred
> >     Response: Command completed at target (0x00)
> >     Status: Check Condition (0x02)
> >     TotalAHSLength: 0x00
> >     DataSegmentLength: 0x00000014
> >     InitiatorTaskTag: 0x0000000d
> >     StatSN: 0x0000000e
> >     ExpCmdSN: 0x0000000d
> >     MaxCmdSN: 0x00000014
> >     ExpDataSN: 0x00000000
> >     BidiReadResidualCount: 0x00000000
> >     ResidualCount: 0x00000000
> >     Request in: 45
> >     Time from request: 0.081560000 seconds
> >     SenseLength: 0x0012
> > SCSI: SNS Info
> >     LUN: 0x0001
> >     Valid: 1
> >     .111 0000 = SNS Error Type: Current Error
(0x70)
> >     Filemark: 0, EOM: 0, ILI: 0
> >     .... 0101 = Sense Key: Illegal Request (0x05)
> >     Sense Info: 0x00000000
> >     Additional Sense Length: 10
> >     Command-Specific Information: 00000000
> >     Additional Sense Code+Qualifier: Invalid Field
In Cdb (0x2400)
> >     Field Replaceable Unit Code: 0x00
> >     .. = SKSV: True
> >     Sense Key Specific: C00001
> 
> Ok. This indicates that the SKSV is valid, the error is
in the CDB,  
> BPV is clear, and the error is in field 1 (byte 1).
> 
> > 0000  00 30 1b b1 31 91 00 04 38 a0 c6 07 08 00 45
00   . 
> > 0..1...8.....E.
> > 0010  00 78 91 60 40 00 2f 06 8b f8 54 0c 05 07 84
 
> > 41   .x.`./...T....A
> > 0020  50 d3 0c bc db d6 76 84 3d 3e 02 55 c6 01 80
18    
> > P.....v.=>.U....
> > 0030  ff ff cb 19 00 00 01 01 08 0a 00 00 00 05 03
 
> > cd   ................
> > 0040  d9 01 21 80 00 02 00 00 00 14 00 00 00 00 00
 
> > 00   ..!.............
> > 0050  00 00 00 00 00 0d 00 00 00 00 00 00 00 0e 00
 
> > 00   ................
> > 0060  00 0d 00 00 00 14 00 00 00 00 00 00 00 00 00
 
> > 00   ................
> > 0070  00 00 00 12 f0 00 05 00 00 00 00 0a 00 00 00
 
> > 00   ................
> > 0080  24 00 00 c0 00 01                           
     $.....
> >
> >> 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.
> >>
> > I don't deal with the ccb, it's the cam.
> 
> Hmm... I'm not sure how to fix this then. The problem
is that the  
> specs indicate that this is no longer valid. They do
not indicate  
> obsolete (the "obsolete" term exists for
that), they are invalid  
> ("reserved in SPC2). There are test suites (which
have been run  
> against us) that make sure the use of any
"reserved" bit causes an  
> error.
> 
> Take care,
> 
> Bill
ok,
	setting max_luns to 'the highest lun', 0, stopped the
INQs for
LUN1, and so it's working!
	this is a kludge, IMHO, but i guess Jonathan will be happy.

Aug 25 23:07:55 shuttle-3 kernel: da2 at iscsi0 bus 0 target
0 lun 0
Aug 25 23:07:55 shuttle-3 kernel: da2: <Wasabi WSB 1500
0150> Fixed Direct Access SCSI-5 device 
Aug 25 23:07:55 shuttle-3 kernel: da2: 210000MB (430080000
512 byte sectors: 255H 63S/T 26771C)

danny


_______________________________________________
freebsd-scsifreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to
"freebsd-scsi-unsubscribefreebsd.org"

On Fri, Aug 25, 2006 at 11:37:15 -0700, William Studenmund
wrote:
> On Aug 25, 2006, at 11:22 AM, Danny Braniss wrote:
> 
> >>>> 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?
> >>
> > whatever the target sent , hopefully
i'm picking it up correctly.
> > the code is at the end.
> >
> >> 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.
> >>
> > this is the INQ:
> > iSCSI (SCSI Command)
> >     Opcode: SCSI Command (0x01)
> >     .0.. .... = I: Queued delivery
> >     Flags: 0xc1
> >         1... .... = F: Final PDU in sequence
> >         .1.. .... = R: Data will be read from
target
> >         ..0. .... = W: No data will be written to
target
> >         .... .001 = Attr: Simple (0x01)
> >     TotalAHSLength: 0x00
> >     DataSegmentLength: 0x00000000
> >     LUN: 0001000000000000
> 
> Ok! You're setting the LUN right.
> 
> >     InitiatorTaskTag: 0x0000000d
> >     ExpectedDataTransferLength: 0x00000024
> >     CmdSN: 0x0000000c
> >     ExpStatSN: 0x0000000d
> >     Response in: 48
> > SCSI CDB
> >     LUN: 0x0001
> >     Opcode: Inquiry (0x12)
> >     CMDT = 0, EVPD = 0
> >     Allocation Length: 36
> >     Vendor Unique = 0, NACA = 0, Link = 0
> >
> > 0000  00 04 38 a0 c6 07 00 30 1b b1 31 91 08 00 45
00   .. 
> > 8....0..1...E.
> > 0010  00 64 a5 ff 40 00 40 06 66 6d 84 41 50 d3 54
 
> > 0c   .d....fm.AP.T.
> > 0020  05 07 db d6 0c bc 02 55 c5 d1 76 84 38 de 80
18   .......U..v. 
> > 8...
> > 0030  82 18 51 2a 00 00 01 01 08 0a 03 cd d9 01 00
 
> > 00   ..Q*............
> > 0040  00 04 01 c1 00 00 00 00 00 00 00 01 00 00 00
 
> > 00   ................
> > 0050  00 00 00 00 00 0d 00 00 00 24 00 00 00 0c 00
00   ......... 
> > $......
> > 0060  00 0d 12 20 00 00 24 00 00 00 00 00 00 00 00
00   ... .. 
> > $.........
>                  ^^
> 
> [I hope that comes out right, my mailer is using a
variable-width font]
> 
> Note the cdb is 12 20 00 00 24 00. The 20 is where
something stored  
> LUN 1, and it is what the target dislikes.

CAM will set the LUN number when talking to a device that is
SCSI-2 or
older.  It also has to set the LUN number on the initial
inquiry when
talking to a device that is newer than SCSI-2, because it
doesn't know what
SCSI-rev it claims to be.  (Until it gets the initial
inquiry back.)

> > 0070  00 00                                       
     ..
> >
> > and this is the response:
> > iSCSI (SCSI Response)
> >     Opcode: SCSI Response (0x21)
> >     Flags: 0x80
> >         ...0 .... = o: No overflow of read part of
bi-directional  
> > command
> >         .... 0... = u: No underflow of read part
of bi-directional  
> > command
> >         .... .0.. = O: No residual overflow
occurred
> >         .... ..0. = U: No residual underflow
occurred
> >     Response: Command completed at target (0x00)
> >     Status: Check Condition (0x02)
> >     TotalAHSLength: 0x00
> >     DataSegmentLength: 0x00000014
> >     InitiatorTaskTag: 0x0000000d
> >     StatSN: 0x0000000e
> >     ExpCmdSN: 0x0000000d
> >     MaxCmdSN: 0x00000014
> >     ExpDataSN: 0x00000000
> >     BidiReadResidualCount: 0x00000000
> >     ResidualCount: 0x00000000
> >     Request in: 45
> >     Time from request: 0.081560000 seconds
> >     SenseLength: 0x0012
> > SCSI: SNS Info
> >     LUN: 0x0001
> >     Valid: 1
> >     .111 0000 = SNS Error Type: Current Error
(0x70)
> >     Filemark: 0, EOM: 0, ILI: 0
> >     .... 0101 = Sense Key: Illegal Request (0x05)
> >     Sense Info: 0x00000000
> >     Additional Sense Length: 10
> >     Command-Specific Information: 00000000
> >     Additional Sense Code+Qualifier: Invalid Field
In Cdb (0x2400)
> >     Field Replaceable Unit Code: 0x00
> >     .. = SKSV: True
> >     Sense Key Specific: C00001
> 
> Ok. This indicates that the SKSV is valid, the error is
in the CDB,  
> BPV is clear, and the error is in field 1 (byte 1).
> 
> > 0000  00 30 1b b1 31 91 00 04 38 a0 c6 07 08 00 45
00   . 
> > 0..1...8.....E.
> > 0010  00 78 91 60 40 00 2f 06 8b f8 54 0c 05 07 84
 
> > 41   .x.`./...T....A
> > 0020  50 d3 0c bc db d6 76 84 3d 3e 02 55 c6 01 80
18    
> > P.....v.=>.U....
> > 0030  ff ff cb 19 00 00 01 01 08 0a 00 00 00 05 03
 
> > cd   ................
> > 0040  d9 01 21 80 00 02 00 00 00 14 00 00 00 00 00
 
> > 00   ..!.............
> > 0050  00 00 00 00 00 0d 00 00 00 00 00 00 00 0e 00
 
> > 00   ................
> > 0060  00 0d 00 00 00 14 00 00 00 00 00 00 00 00 00
 
> > 00   ................
> > 0070  00 00 00 12 f0 00 05 00 00 00 00 0a 00 00 00
 
> > 00   ................
> > 0080  24 00 00 c0 00 01                           
     $.....
> >
> >> 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.
> >>
> > I don't deal with the ccb, it's the cam.
> 
> Hmm... I'm not sure how to fix this then. The problem
is that the  
> specs indicate that this is no longer valid. They do
not indicate  
> obsolete (the "obsolete" term exists for
that), they are invalid  
> ("reserved in SPC2). There are test suites (which
have been run  
> against us) that make sure the use of any
"reserved" bit causes an  
> error.

See above...CAM sets the LUN number when it does the initial
probe of a
LUN, and when the LUN reports it is SCSI-2 or below.

The problem with rejecting the LUN number on the inquiry is
that the
initiator is issuing the inquiry to find out what SCSI rev
the target is in
the first place.  It has to do so in a way that will work on
old and new
targets.

Things work okay on LUN 0, because the LUN field is set to
0.

My suggestion would be to allow setting of the LUN number on
the inquiry
command only.  That way the initiator can figure out what
SCSI rev you are
and do things accordingly.

Ken
-- 
Kenneth Merry
kenFreeBSD.ORG
_______________________________________________
freebsd-scsifreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to
"freebsd-scsi-unsubscribefreebsd.org"

Kenneth D. Merry wrote:
> On Fri, Aug 25, 2006 at 11:37:15 -0700, William
Studenmund wrote:
> 
>>On Aug 25, 2006, at 11:22 AM, Danny Braniss wrote:
>>
>>
>>>>>>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?
>>>>
>>>whatever the target sent , hopefully
i'm picking it up correctly.
>>>the code is at the end.
>>>
>>>
>>>>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.
>>>>
>>>
>>>this is the INQ:
>>>iSCSI (SCSI Command)
>>>    Opcode: SCSI Command (0x01)
>>>    .0.. .... = I: Queued delivery
>>>    Flags: 0xc1
>>>        1... .... = F: Final PDU in sequence
>>>        .1.. .... = R: Data will be read from
target
>>>        ..0. .... = W: No data will be written
to target
>>>        .... .001 = Attr: Simple (0x01)
>>>    TotalAHSLength: 0x00
>>>    DataSegmentLength: 0x00000000
>>>    LUN: 0001000000000000
>>
>>Ok! You're setting the LUN right.
>>
>>
>>>    InitiatorTaskTag: 0x0000000d
>>>    ExpectedDataTransferLength: 0x00000024
>>>    CmdSN: 0x0000000c
>>>    ExpStatSN: 0x0000000d
>>>    Response in: 48
>>>SCSI CDB
>>>    LUN: 0x0001
>>>    Opcode: Inquiry (0x12)
>>>    CMDT = 0, EVPD = 0
>>>    Allocation Length: 36
>>>    Vendor Unique = 0, NACA = 0, Link = 0
>>>
>>>0000  00 04 38 a0 c6 07 00 30 1b b1 31 91 08 00
45 00   .. 
>>>8....0..1...E.
>>>0010  00 64 a5 ff 40 00 40 06 66 6d 84 41 50 d3
54  
>>>0c   .d....fm.AP.T.
>>>0020  05 07 db d6 0c bc 02 55 c5 d1 76 84 38 de
80 18   .......U..v. 
>>>8...
>>>0030  82 18 51 2a 00 00 01 01 08 0a 03 cd d9 01
00  
>>>00   ..Q*............
>>>0040  00 04 01 c1 00 00 00 00 00 00 00 01 00 00
00  
>>>00   ................
>>>0050  00 00 00 00 00 0d 00 00 00 24 00 00 00 0c
00 00   ......... 
>>>$......
>>>0060  00 0d 12 20 00 00 24 00 00 00 00 00 00 00
00 00   ... .. 
>>>$.........
>>
>>                 ^^
>>
>>[I hope that comes out right, my mailer is using a
variable-width font]
>>
>>Note the cdb is 12 20 00 00 24 00. The 20 is where
something stored  
>>LUN 1, and it is what the target dislikes.
> 
> 
> CAM will set the LUN number when talking to a device
that is SCSI-2 or
> older.  It also has to set the LUN number on the
initial inquiry when
> talking to a device that is newer than SCSI-2, because
it doesn't know what
> SCSI-rev it claims to be.  (Until it gets the initial
inquiry back.)
> 
> 
>>>0070  00 00                                     
       ..
>>>
>>>and this is the response:
>>>iSCSI (SCSI Response)
>>>    Opcode: SCSI Response (0x21)
>>>    Flags: 0x80
>>>        ...0 .... = o: No overflow of read part
of bi-directional  
>>>command
>>>        .... 0... = u: No underflow of read part
of bi-directional  
>>>command
>>>        .... .0.. = O: No residual overflow
occurred
>>>        .... ..0. = U: No residual underflow
occurred
>>>    Response: Command completed at target (0x00)
>>>    Status: Check Condition (0x02)
>>>    TotalAHSLength: 0x00
>>>    DataSegmentLength: 0x00000014
>>>    InitiatorTaskTag: 0x0000000d
>>>    StatSN: 0x0000000e
>>>    ExpCmdSN: 0x0000000d
>>>    MaxCmdSN: 0x00000014
>>>    ExpDataSN: 0x00000000
>>>    BidiReadResidualCount: 0x00000000
>>>    ResidualCount: 0x00000000
>>>    Request in: 45
>>>    Time from request: 0.081560000 seconds
>>>    SenseLength: 0x0012
>>>SCSI: SNS Info
>>>    LUN: 0x0001
>>>    Valid: 1
>>>    .111 0000 = SNS Error Type: Current Error
(0x70)
>>>    Filemark: 0, EOM: 0, ILI: 0
>>>    .... 0101 = Sense Key: Illegal Request
(0x05)
>>>    Sense Info: 0x00000000
>>>    Additional Sense Length: 10
>>>    Command-Specific Information: 00000000
>>>    Additional Sense Code+Qualifier: Invalid
Field In Cdb (0x2400)
>>>    Field Replaceable Unit Code: 0x00
>>>    .. = SKSV: True
>>>    Sense Key Specific: C00001
>>
>>Ok. This indicates that the SKSV is valid, the error
is in the CDB,  
>>BPV is clear, and the error is in field 1 (byte 1).
>>
>>
>>>0000  00 30 1b b1 31 91 00 04 38 a0 c6 07 08 00
45 00   . 
>>>0..1...8.....E.
>>>0010  00 78 91 60 40 00 2f 06 8b f8 54 0c 05 07
84  
>>>41   .x.`./...T....A
>>>0020  50 d3 0c bc db d6 76 84 3d 3e 02 55 c6 01
80 18    
>>>P.....v.=>.U....
>>>0030  ff ff cb 19 00 00 01 01 08 0a 00 00 00 05
03  
>>>cd   ................
>>>0040  d9 01 21 80 00 02 00 00 00 14 00 00 00 00
00  
>>>00   ..!.............
>>>0050  00 00 00 00 00 0d 00 00 00 00 00 00 00 0e
00  
>>>00   ................
>>>0060  00 0d 00 00 00 14 00 00 00 00 00 00 00 00
00  
>>>00   ................
>>>0070  00 00 00 12 f0 00 05 00 00 00 00 0a 00 00
00  
>>>00   ................
>>>0080  24 00 00 c0 00 01                         
       $.....
>>>
>>>
>>>>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.
>>>>
>>>
>>>I don't deal with the ccb, it's the cam.
>>
>>Hmm... I'm not sure how to fix this then. The
problem is that the  
>>specs indicate that this is no longer valid. They do
not indicate  
>>obsolete (the "obsolete" term exists for
that), they are invalid  
>>("reserved in SPC2). There are test suites
(which have been run  
>>against us) that make sure the use of any
"reserved" bit causes an  
>>error.
> 
> 
> See above...CAM sets the LUN number when it does the
initial probe of a
> LUN, and when the LUN reports it is SCSI-2 or below.
> 
> The problem with rejecting the LUN number on the
inquiry is that the
> initiator is issuing the inquiry to find out what SCSI
rev the target is in
> the first place.  It has to do so in a way that will
work on old and new
> targets.
> 
> Things work okay on LUN 0, because the LUN field is set
to 0.
> 
> My suggestion would be to allow setting of the LUN
number on the inquiry
> command only.  That way the initiator can figure out
what SCSI rev you are
> and do things accordingly.
> 
> Ken

Are there cases where a target has multiple LUNs that will
each report a 
different SCSI rev?  If not, then CAM should look at the rev
of LUN 0 of 
the target when deciding how to form an INQ of LUNs >0.

Scott

_______________________________________________
freebsd-scsifreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to
"freebsd-scsi-unsubscribefreebsd.org"

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

On Aug 25, 2006, at 1:59 PM, Scott Long wrote:

> Kenneth D. Merry wrote:
>> On Fri, Aug 25, 2006 at 11:37:15 -0700, William
Studenmund wrote:
>> See above...CAM sets the LUN number when it does
the initial probe  
>> of a
>> LUN, and when the LUN reports it is SCSI-2 or
below.
>> The problem with rejecting the LUN number on the
inquiry is that the
>> initiator is issuing the inquiry to find out what
SCSI rev the  
>> target is in
>> the first place.  It has to do so in a way that
will work on old  
>> and new
>> targets.
>> Things work okay on LUN 0, because the LUN field is
set to 0.
>> My suggestion would be to allow setting of the LUN
number on the  
>> inquiry
>> command only.  That way the initiator can figure
out what SCSI rev  
>> you are
>> and do things accordingly.
>> Ken
>
> Are there cases where a target has multiple LUNs that
will each  
> report a different SCSI rev?  If not, then CAM should
look at the  
> rev of LUN 0 of the target when deciding how to form an
INQ of LUNs  
> >0.

While I think there could be a difference between reported
levels, if  
LUN 0 reports > SCSI-1, then I think it's appropriate to
not put the  
LUN in the CDB. SCSI-2 mentions that the LUN field should be
set to  
zero as SCSI-3 may reclaim the bits (which it did).

I believe that by the time LUN 0 has been probed, the system
should  
have enough information to figure out if the device is
SCSI-1,  
SCSI-2. or SCSI-3 (i.e. sam-X, spc-Y, etc.). I think that
Scott's  
suggestion is good; if LUN 0 is SCSI-1, fill in the LUN in
the CBD.  
If LUN 0 is > SCSI-1, don't.

Also, while probing LUN 0, it's probably best to perform a
REPORT  
LUNS command. If it succeeds, you 1) don't need to blindly
probe, and  
2) you know that you shouldn't put the LUN in the CDB
(REPORT LUNS  
appeared  in SPC, which is SCSI-3).

Take care,

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

iD8DBQFE73CHDJT2Egh26K0RAm+qAJ4+HXmkWGjDlQ9N+NBRKLVXRmk7AgCf
QHZI
RLHACxamcGkzSzAIqiRaw8g=
=JcoY
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-scsifreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to
"freebsd-scsi-unsubscribefreebsd.org"

> Kenneth D. Merry wrote:
> > On Fri, Aug 25, 2006 at 11:37:15 -0700, William
Studenmund wrote:
> > 
> >>On Aug 25, 2006, at 11:22 AM, Danny Braniss
wrote:
> >>
> >>
> >>>>>>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?
> >>>>
> >>>whatever the target sent , hopefully
i'm picking it up correctly.
> >>>the code is at the end.
> >>>
> >>>
> >>>>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.
> >>>>
> >>>
> >>>this is the INQ:
> >>>iSCSI (SCSI Command)
> >>>    Opcode: SCSI Command (0x01)
> >>>    .0.. .... = I: Queued delivery
> >>>    Flags: 0xc1
> >>>        1... .... = F: Final PDU in
sequence
> >>>        .1.. .... = R: Data will be read
from target
> >>>        ..0. .... = W: No data will be
written to target
> >>>        .... .001 = Attr: Simple (0x01)
> >>>    TotalAHSLength: 0x00
> >>>    DataSegmentLength: 0x00000000
> >>>    LUN: 0001000000000000
> >>
> >>Ok! You're setting the LUN right.
> >>
> >>
> >>>    InitiatorTaskTag: 0x0000000d
> >>>    ExpectedDataTransferLength: 0x00000024
> >>>    CmdSN: 0x0000000c
> >>>    ExpStatSN: 0x0000000d
> >>>    Response in: 48
> >>>SCSI CDB
> >>>    LUN: 0x0001
> >>>    Opcode: Inquiry (0x12)
> >>>    CMDT = 0, EVPD = 0
> >>>    Allocation Length: 36
> >>>    Vendor Unique = 0, NACA = 0, Link = 0
> >>>
> >>>0000  00 04 38 a0 c6 07 00 30 1b b1 31 91
08 00 45 00   .. 
> >>>8....0..1...E.
> >>>0010  00 64 a5 ff 40 00 40 06 66 6d 84 41
50 d3 54  
> >>>0c   .d....fm.AP.T.
> >>>0020  05 07 db d6 0c bc 02 55 c5 d1 76 84
38 de 80 18   .......U..v. 
> >>>8...
> >>>0030  82 18 51 2a 00 00 01 01 08 0a 03 cd
d9 01 00  
> >>>00   ..Q*............
> >>>0040  00 04 01 c1 00 00 00 00 00 00 00 01
00 00 00  
> >>>00   ................
> >>>0050  00 00 00 00 00 0d 00 00 00 24 00 00
00 0c 00 00   ......... 
> >>>$......
> >>>0060  00 0d 12 20 00 00 24 00 00 00 00 00
00 00 00 00   ... .. 
> >>>$.........
> >>
> >>                 ^^
> >>
> >>[I hope that comes out right, my mailer is
using a variable-width font]
> >>
> >>Note the cdb is 12 20 00 00 24 00. The 20 is
where something stored  
> >>LUN 1, and it is what the target dislikes.
> > 
> > 
> > CAM will set the LUN number when talking to a
device that is SCSI-2 or
> > older.  It also has to set the LUN number on the
initial inquiry when
> > talking to a device that is newer than SCSI-2,
because it doesn't know what
> > SCSI-rev it claims to be.  (Until it gets the
initial inquiry back.)
> > 
> > 
> >>>0070  00 00                                
            ..
> >>>
> >>>and this is the response:
> >>>iSCSI (SCSI Response)
> >>>    Opcode: SCSI Response (0x21)
> >>>    Flags: 0x80
> >>>        ...0 .... = o: No overflow of read
part of bi-directional  
> >>>command
> >>>        .... 0... = u: No underflow of read
part of bi-directional  
> >>>command
> >>>        .... .0.. = O: No residual overflow
occurred
> >>>        .... ..0. = U: No residual
underflow occurred
> >>>    Response: Command completed at target
(0x00)
> >>>    Status: Check Condition (0x02)
> >>>    TotalAHSLength: 0x00
> >>>    DataSegmentLength: 0x00000014
> >>>    InitiatorTaskTag: 0x0000000d
> >>>    StatSN: 0x0000000e
> >>>    ExpCmdSN: 0x0000000d
> >>>    MaxCmdSN: 0x00000014
> >>>    ExpDataSN: 0x00000000
> >>>    BidiReadResidualCount: 0x00000000
> >>>    ResidualCount: 0x00000000
> >>>    Request in: 45
> >>>    Time from request: 0.081560000 seconds
> >>>    SenseLength: 0x0012
> >>>SCSI: SNS Info
> >>>    LUN: 0x0001
> >>>    Valid: 1
> >>>    .111 0000 = SNS Error Type: Current
Error (0x70)
> >>>    Filemark: 0, EOM: 0, ILI: 0
> >>>    .... 0101 = Sense Key: Illegal Request
(0x05)
> >>>    Sense Info: 0x00000000
> >>>    Additional Sense Length: 10
> >>>    Command-Specific Information: 00000000
> >>>    Additional Sense Code+Qualifier:
Invalid Field In Cdb (0x2400)
> >>>    Field Replaceable Unit Code: 0x00
> >>>    .. = SKSV: True
> >>>    Sense Key Specific: C00001
> >>
> >>Ok. This indicates that the SKSV is valid, the
error is in the CDB,  
> >>BPV is clear, and the error is in field 1 (byte
1).
> >>
> >>
> >>>0000  00 30 1b b1 31 91 00 04 38 a0 c6 07
08 00 45 00   . 
> >>>0..1...8.....E.
> >>>0010  00 78 91 60 40 00 2f 06 8b f8 54 0c
05 07 84  
> >>>41   .x.`./...T....A
> >>>0020  50 d3 0c bc db d6 76 84 3d 3e 02 55
c6 01 80 18    
> >>>P.....v.=>.U....
> >>>0030  ff ff cb 19 00 00 01 01 08 0a 00 00
00 05 03  
> >>>cd   ................
> >>>0040  d9 01 21 80 00 02 00 00 00 14 00 00
00 00 00  
> >>>00   ..!.............
> >>>0050  00 00 00 00 00 0d 00 00 00 00 00 00
00 0e 00  
> >>>00   ................
> >>>0060  00 0d 00 00 00 14 00 00 00 00 00 00
00 00 00  
> >>>00   ................
> >>>0070  00 00 00 12 f0 00 05 00 00 00 00 0a
00 00 00  
> >>>00   ................
> >>>0080  24 00 00 c0 00 01                    
            $.....
> >>>
> >>>
> >>>>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.
> >>>>
> >>>
> >>>I don't deal with the ccb, it's the cam.
> >>
> >>Hmm... I'm not sure how to fix this then. The
problem is that the  
> >>specs indicate that this is no longer valid.
They do not indicate  
> >>obsolete (the "obsolete" term
exists for that), they are invalid  
> >>("reserved in SPC2). There are test
suites (which have been run  
> >>against us) that make sure the use of any
"reserved" bit causes an  
> >>error.
> > 
> > 
> > See above...CAM sets the LUN number when it does
the initial probe of a
> > LUN, and when the LUN reports it is SCSI-2 or
below.
> > 
> > The problem with rejecting the LUN number on the
inquiry is that the
> > initiator is issuing the inquiry to find out what
SCSI rev the target is in
> > the first place.  It has to do so in a way that
will work on old and new
> > targets.
> > 
> > Things work okay on LUN 0, because the LUN field
is set to 0.
> > 
> > My suggestion would be to allow setting of the LUN
number on the inquiry
> > command only.  That way the initiator can figure
out what SCSI rev you are
> > and do things accordingly.
> > 
> > Ken
> 
> Are there cases where a target has multiple LUNs that
will each report a 
> different SCSI rev?  If not, then CAM should look at
the rev of LUN 0 of 
> the target when deciding how to form an INQ of LUNs
>0.
> 
> Scott
>
sorry to barge in 
but my initial problem was that the driver went into a loop.
	0- cam starts lun discovery
	1- cam sends inq
	2- target replies 'condition check'
	3- cam ignores,
	4- back to 1

and i want to stop this.

also, I understand the lun discovery problematic, but what
if:
	when the CAM does a XPT_PATH_INQ,
	setting cpi->max_lun to CAM_DO_LUN_DISCOVERY value
triggers a different discovery algorithm?

danny
PS: getting close to a new release of iscsi_initiator


_______________________________________________
freebsd-scsifreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to
"freebsd-scsi-unsubscribefreebsd.org"

Danny Braniss wrote:

>>Kenneth D. Merry wrote:
>>
>>>On Fri, Aug 25, 2006 at 11:37:15 -0700, William
Studenmund wrote:
>>>
>>>
>>>>On Aug 25, 2006, at 11:22 AM, Danny Braniss
wrote:
>>>>
>>>>
>>>>
>>>>>>>>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?
>>>>>>
>>>>>whatever the target sent , hopefully
i'm picking it up correctly.
>>>>>the code is at the end.
>>>>>
>>>>>
>>>>>
>>>>>>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.
>>>>>>
>>>>>
>>>>>this is the INQ:
>>>>>iSCSI (SCSI Command)
>>>>>   Opcode: SCSI Command (0x01)
>>>>>   .0.. .... = I: Queued delivery
>>>>>   Flags: 0xc1
>>>>>       1... .... = F: Final PDU in
sequence
>>>>>       .1.. .... = R: Data will be read
from target
>>>>>       ..0. .... = W: No data will be
written to target
>>>>>       .... .001 = Attr: Simple (0x01)
>>>>>   TotalAHSLength: 0x00
>>>>>   DataSegmentLength: 0x00000000
>>>>>   LUN: 0001000000000000
>>>>
>>>>Ok! You're setting the LUN right.
>>>>
>>>>
>>>>
>>>>>   InitiatorTaskTag: 0x0000000d
>>>>>   ExpectedDataTransferLength:
0x00000024
>>>>>   CmdSN: 0x0000000c
>>>>>   ExpStatSN: 0x0000000d
>>>>>   Response in: 48
>>>>>SCSI CDB
>>>>>   LUN: 0x0001
>>>>>   Opcode: Inquiry (0x12)
>>>>>   CMDT = 0, EVPD = 0
>>>>>   Allocation Length: 36
>>>>>   Vendor Unique = 0, NACA = 0, Link = 0
>>>>>
>>>>>0000  00 04 38 a0 c6 07 00 30 1b b1 31
91 08 00 45 00   .. 
>>>>>8....0..1...E.
>>>>>0010  00 64 a5 ff 40 00 40 06 66 6d 84
41 50 d3 54  
>>>>>0c   .d....fm.AP.T.
>>>>>0020  05 07 db d6 0c bc 02 55 c5 d1 76
84 38 de 80 18   .......U..v. 
>>>>>8...
>>>>>0030  82 18 51 2a 00 00 01 01 08 0a 03
cd d9 01 00  
>>>>>00   ..Q*............
>>>>>0040  00 04 01 c1 00 00 00 00 00 00 00
01 00 00 00  
>>>>>00   ................
>>>>>0050  00 00 00 00 00 0d 00 00 00 24 00
00 00 0c 00 00   ......... 
>>>>>$......
>>>>>0060  00 0d 12 20 00 00 24 00 00 00 00
00 00 00 00 00   ... .. 
>>>>>$.........
>>>>
>>>>                ^^
>>>>
>>>>[I hope that comes out right, my mailer is
using a variable-width font]
>>>>
>>>>Note the cdb is 12 20 00 00 24 00. The 20 is
where something stored  
>>>>LUN 1, and it is what the target dislikes.
>>>
>>>
>>>CAM will set the LUN number when talking to a
device that is SCSI-2 or
>>>older.  It also has to set the LUN number on the
initial inquiry when
>>>talking to a device that is newer than SCSI-2,
because it doesn't know what
>>>SCSI-rev it claims to be.  (Until it gets the
initial inquiry back.)
>>>
>>>
>>>
>>>>>0070  00 00                             
               ..
>>>>>
>>>>>and this is the response:
>>>>>iSCSI (SCSI Response)
>>>>>   Opcode: SCSI Response (0x21)
>>>>>   Flags: 0x80
>>>>>       ...0 .... = o: No overflow of
read part of bi-directional  
>>>>>command
>>>>>       .... 0... = u: No underflow of
read part of bi-directional  
>>>>>command
>>>>>       .... .0.. = O: No residual
overflow occurred
>>>>>       .... ..0. = U: No residual
underflow occurred
>>>>>   Response: Command completed at target
(0x00)
>>>>>   Status: Check Condition (0x02)
>>>>>   TotalAHSLength: 0x00
>>>>>   DataSegmentLength: 0x00000014
>>>>>   InitiatorTaskTag: 0x0000000d
>>>>>   StatSN: 0x0000000e
>>>>>   ExpCmdSN: 0x0000000d
>>>>>   MaxCmdSN: 0x00000014
>>>>>   ExpDataSN: 0x00000000
>>>>>   BidiReadResidualCount: 0x00000000
>>>>>   ResidualCount: 0x00000000
>>>>>   Request in: 45
>>>>>   Time from request: 0.081560000
seconds
>>>>>   SenseLength: 0x0012
>>>>>SCSI: SNS Info
>>>>>   LUN: 0x0001
>>>>>   Valid: 1
>>>>>   .111 0000 = SNS Error Type: Current
Error (0x70)
>>>>>   Filemark: 0, EOM: 0, ILI: 0
>>>>>   .... 0101 = Sense Key: Illegal
Request (0x05)
>>>>>   Sense Info: 0x00000000
>>>>>   Additional Sense Length: 10
>>>>>   Command-Specific Information:
00000000
>>>>>   Additional Sense Code+Qualifier:
Invalid Field In Cdb (0x2400)
>>>>>   Field Replaceable Unit Code: 0x00
>>>>>   .. = SKSV: True
>>>>>   Sense Key Specific: C00001
>>>>
>>>>Ok. This indicates that the SKSV is valid,
the error is in the CDB,  
>>>>BPV is clear, and the error is in field 1
(byte 1).
>>>>
>>>>
>>>>
>>>>>0000  00 30 1b b1 31 91 00 04 38 a0 c6
07 08 00 45 00   . 
>>>>>0..1...8.....E.
>>>>>0010  00 78 91 60 40 00 2f 06 8b f8 54
0c 05 07 84  
>>>>>41   .x.`./...T....A
>>>>>0020  50 d3 0c bc db d6 76 84 3d 3e 02
55 c6 01 80 18    
>>>>>P.....v.=>.U....
>>>>>0030  ff ff cb 19 00 00 01 01 08 0a 00
00 00 05 03  
>>>>>cd   ................
>>>>>0040  d9 01 21 80 00 02 00 00 00 14 00
00 00 00 00  
>>>>>00   ..!.............
>>>>>0050  00 00 00 00 00 0d 00 00 00 00 00
00 00 0e 00  
>>>>>00   ................
>>>>>0060  00 0d 00 00 00 14 00 00 00 00 00
00 00 00 00  
>>>>>00   ................
>>>>>0070  00 00 00 12 f0 00 05 00 00 00 00
0a 00 00 00  
>>>>>00   ................
>>>>>0080  24 00 00 c0 00 01                 
               $.....
>>>>>
>>>>>
>>>>>
>>>>>>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.
>>>>>>
>>>>>
>>>>>I don't deal with the ccb, it's the
cam.
>>>>
>>>>Hmm... I'm not sure how to fix this then.
The problem is that the  
>>>>specs indicate that this is no longer valid.
They do not indicate  
>>>>obsolete (the "obsolete" term
exists for that), they are invalid  
>>>>("reserved in SPC2). There are test
suites (which have been run  
>>>>against us) that make sure the use of any
"reserved" bit causes an  
>>>>error.
>>>
>>>
>>>See above...CAM sets the LUN number when it does
the initial probe of a
>>>LUN, and when the LUN reports it is SCSI-2 or
below.
>>>
>>>The problem with rejecting the LUN number on the
inquiry is that the
>>>initiator is issuing the inquiry to find out
what SCSI rev the target is in
>>>the first place.  It has to do so in a way that
will work on old and new
>>>targets.
>>>
>>>Things work okay on LUN 0, because the LUN field
is set to 0.
>>>
>>>My suggestion would be to allow setting of the
LUN number on the inquiry
>>>command only.  That way the initiator can figure
out what SCSI rev you are
>>>and do things accordingly.
>>>
>>>Ken
>>
>>Are there cases where a target has multiple LUNs
that will each report a 
>>different SCSI rev?  If not, then CAM should look at
the rev of LUN 0 of 
>>the target when deciding how to form an INQ of LUNs
>0.
>>
>>Scott
>>
> 
> sorry to barge in 
> but my initial problem was that the driver went into a
loop.
> 	0- cam starts lun discovery
> 	1- cam sends inq
> 	2- target replies 'condition check'
> 	3- cam ignores,
> 	4- back to 1

This is only going to happen if the SIM is returning
CAM_REQ_CMP.
You should be returning CAM_REQ_CMP_ERROR.  An ASC of 0x24
will set
SS_FATAL, which will cause probedone() to break out of the
probe
sequence.

> 
> and i want to stop this.
> 
> also, I understand the lun discovery problematic, but
what if:
> 	when the CAM does a XPT_PATH_INQ,
> 	setting cpi->max_lun to CAM_DO_LUN_DISCOVERY value
> triggers a different discovery algorithm?

This would in effect allow the SIM to provide hints on how
to scan
the devices that it owns, which is a good idea.

> 
> danny
> PS: getting close to a new release of iscsi_initiator
> 
> 

Keep up the good work!

Scott

_______________________________________________
freebsd-scsifreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to
"freebsd-scsi-unsubscribefreebsd.org"