iSCSI/luns/check-condition

Fri Aug 25 20:15:23 UTC 2006

> -----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.. 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.
> 
> > 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