What does the error code 82 mean?
Ken Merry
ken at freebsd.org
Tue Mar 3 16:28:10 UTC 2015
It sounds like the target reset is causing the drive to reset its negotiation parameters, and go back to narrow SCSI.
UNIT1 still thinks it is talking wide SCSI, but the drive is actually talking 8 bit. So the drive sends back the 64 bytes of inquiry data in 64 bus clocks. The drive is only changing the bottom 8 bits, but the controller thinks it is driving all 16, and records the top 8 bits as zeros.
The result is that you get 64 bytes of “extra” data, and every other byte is zero.
So, you’ll need to figure out a way for the sym(4) driver to figure out that the target has been reset, and re-negotiate with the drive.
You might try seeing what the ahc(4) and ahd(4) drivers do in this situation. I don’t know whether or not they actually handle it, but it might be instructive to look.
If you have an idea that this may have happened, you can try doing a bus or target rescan. That may go through the domain validation path and trigger re-negotiation with the target.
Just out of curiosity, why are you doing multi-initiator with this hardware? It would probably be easier to do all of this with more modern SAS hardware and expanders.
Ken
—
Ken Merry
ken at FreeBSD.ORG
> On Mar 3, 2015, at 12:50 AM, fengyd <fengyd81 at gmail.com> wrote:
>
> Hi,
>
> Thanks very much for your reply.
>
> -How are you sending the INQUIRY command?
> Yes.
> -Are you sending it via the pass(4) driver?
> Yes
> -How many bytes are you asking for in the CDB?
> 64
> -How many bytes are you setting in the dxfer_len field in the CCB?
> 64, but it seems the device wants to transfer 128 bytes.
>
> -What kind of device are you talking to?
> Some kernel log:
> da3 at sym1 bus 0 target 0 lun 0
> da3: <FUJITSU MBA3073NP 4702> Fixed Direct Access SCSI-3 device
> da3: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled
> da3: 70136MB (143638992 512 byte sectors: 255H 63S/T 8941C)
>
>
> <image.png>
>
> The brief connections as above:
> UNIT0 can access DISK0 and DISK1 by IOC0.
> UNIT1 can access DISK0 and DISK1 by IOC1.
>
> The problem happens when UNIT0 sends XPT_RESET_DEV to reset one disk, UNIT1 sends INQUIRY to get the basic information from the target, but fails to get the correct information.
>
> And I added some log.
>
> The right information got from device:
>
> 00 00 03 12 5B 00 01 3A 46 55 4A 49 54 53 55 20
>
> 4D 42 41 33 30 37 33 4E 50 20 20 20 20 20 20 20
>
> 34 37 30 32 42 42 53 32 50 41 41 30 31 31 46 34
>
> 00 00 00 00 00 00 00 00 0F 00 00 40 0B 54 01 3C
>
>
> The wrong information got from device:
>
> 00 00 00 00 03 00 12 00 5B 00 00 00 01 00 3A 00
>
>
> 46 00 55 00 4A 00 49 00 54 00 53 00 55 00 20 00
>
> 4D 00 42 00 41 00 33 00 30 00 37 00 33 00 4E 00
>
> 50 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00
>
>
> Compared to the right log, it seems one extra byte 00 is added after every byte.
>
>
>
>
> Thanks for your help.
>
> Br.
> Yafeng
>
>
> On Tue, Mar 3, 2015 at 2:50 PM, Kenneth D. Merry <ken at freebsd.org <mailto:ken at freebsd.org>> wrote:
>
> An overrun is exactly what the comment below indicates. It is when the
> target sends back more data than you asked for. You will generally see it
> on commands that receive data from a target.
>
> How are you sending the INQUIRY command? Are you sending it via the
> pass(4) driver? How many bytes are you asking for in the CDB? How many
> bytes are you setting in the dxfer_len field in the CCB?
>
> What kind of device are you talking to? Obviously, you're using the sym(4)
> driver, so I'm guessing this is a parallel SCSI device (unless there is a
> virtualization stack that emulates the sym(4) hardware).
>
> Ken
>
> On Mon, Mar 02, 2015 at 15:49:57 +0800, fengyd wrote:
> > Hi,
> >
> > I found the related code in the function sym_int_sir:
> > /*
> > * The device wants us to tranfer more data than
> > * expected or in the wrong direction.
> > * The number of extra bytes is in scratcha.
> > * It is a data overrun condition.
> > */
> > case *SIR_DATA_OVERRUN*:
> > if (cp) {
> > OUTONB (HF_PRT, HF_EXT_ERR);
> > * cp->xerr_status |= XE_EXTRA_DATA;*
> > cp->extra_bytes += INL (nc_scratcha);
> > }
> > goto out;
> >
> > I'm not familiar with SCSI.
> > What does DATA_OVERRUN actually mean?
> > How can it be triggered?
> > Could you give more details about it?
> >
> > Thanks for your help.
> >
> > Br.
> > Yafeng
> >
> >
> >
> > On Sat, Feb 28, 2015 at 4:50 PM, fengyd <fengyd81 at gmail.com <mailto:fengyd81 at gmail.com>> wrote:
> >
> > > Hi,
> > >
> > > It seems the error code 82 & 3F is 0x12.
> > > And the definition of the error code in the file cam.h:
> > > CAM_AUTOSENSE_FAIL = 0x10,/* Autosense: request sense cmd fail */
> > > CAM_NO_HBA, /* No HBA Detected error */
> > > CAM_DATA_RUN_ERR, /* Data Overrun error */
> > >
> > > So, it means data overrun error?
> > >
> > > Thanks.
> > >
> > > Br.
> > > Yafeng
> > >
> > > On Sat, Feb 28, 2015 at 4:32 PM, fengyd <fengyd81 at gmail.com <mailto:fengyd81 at gmail.com>> wrote:
> > >
> > >> Hi,
> > >>
> > >> INQUIRY command is sent to the target, but error code 82 is returned.
> > >> I added some log in the driver:
> > >> SIR_COMPLETE_ERROR
> > >> (pass0:sym0:0:0:0): sym_complete_error status = 18
> > >> (pass0:sym0:0:0:0): status = 82
> > >>
> > >> Do you know what does the error code 82 mean?
> > >>
> > >> Thanks in advance.
> > >>
> > >> Br.
> > >> Yafeng
> > >>
> > >
> > >
> > _______________________________________________
> > freebsd-scsi at freebsd.org <mailto:freebsd-scsi at freebsd.org> mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi <http://lists.freebsd.org/mailman/listinfo/freebsd-scsi>
> > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org <mailto:freebsd-scsi-unsubscribe at freebsd.org>"
>
> --
> Kenneth Merry
> ken at FreeBSD.ORG
>
More information about the freebsd-scsi
mailing list