iSCSI/luns/check-condition
Kenneth D. Merry
ken at freebsd.org
Fri Aug 25 20:45:50 UTC 2006
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.. at .@.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
ken at FreeBSD.ORG
More information about the freebsd-scsi
mailing list