Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Aug 2006 21:22:38 +0300
From:      Danny Braniss <danny@cs.huji.ac.il>
To:        William Studenmund <wrstuden@wasabisystems.com>
Cc:        "'Kenneth D. Merry'" <ken@freebsd.org>, scsi@freebsd.org
Subject:   Re: iSCSI/luns/check-condition 
Message-ID:  <E1GGgKF-00069y-7G@cs1.cs.huji.ac.il>
In-Reply-To: <F6E2AEDC-1C45-41A1-9B3A-A05E93F44456@wasabisystems.com> 
References:  <000201c6c7df$cb0e8a40$0200a8c0@mrbill5>  <E1GGXyv-0007JJ-RG@cs1.cs.huji.ac.il> <F6E2AEDC-1C45-41A1-9B3A-A05E93F44456@wasabisystems.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1GGgKF-00069y-7G>