Date: Thu, 12 Mar 2015 23:21:54 +0800 From: fengyd <fengyd81@gmail.com> To: Ken Merry <ken@freebsd.org> Cc: freebsd-scsi@freebsd.org Subject: Re: What does the error code 82 mean? Message-ID: <CACnvu8ZfPOAizNE=qw-Cb%2BOGT88eJ_2tqM8%2Bh3yXv=uqwS2YBQ@mail.gmail.com> In-Reply-To: <8689E5CD-4E89-48D1-B0EE-3821E7174A0D@freebsd.org> References: <CACnvu8aooXfqV3sG_VbispuZQRVs=g3zVU=GUrqB1QN5g2x6Mg@mail.gmail.com> <CACnvu8YVapcG50oBFSjd1731N-8G7zdybjN2CN6mpgzdrXrifQ@mail.gmail.com> <CACnvu8aNsL5e1=Ygu2wXP=-t1Z-LSWp1GQFrPwruB9PHBkNVXw@mail.gmail.com> <20150303065052.GA98687@mithlond.kdm.org> <CACnvu8big5_XuMCgcEtLA=4b625os_86ROcsAhJPOQ24TfUUDw@mail.gmail.com> <BDD1C459-0FEB-4652-ADA6-1F4ED795D773@freebsd.org> <CACnvu8YZA2LVOQy-ujt-gLgyuGaS8Pusn0vQt9c2LsaefH-yjA@mail.gmail.com> <CACnvu8awZX3J77jinj9Nqqo9E=M88zfVquxBiLFMLYMTURVjjA@mail.gmail.com> <8689E5CD-4E89-48D1-B0EE-3821E7174A0D@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
-Is it always an INQUIRY that is sent from UNIT1 after you reset the target
from UNIT0?
Yes.
I did some tests:
First, UNIT0 reset one device, UNIT1 cannot access it.
Then, UNIT1 reset the same device, UNIT1 can access it, but UNIT0 cannot
access it.
I think device reset should restore some device parameters to the original
values.
Then after both of UNIT0 and UNIT1 reset the same device, they should be
able to access the device.
But it seems not.
Do you know what device reset actually do?
Thanks
Br.
Yafeng
On Thu, Mar 5, 2015 at 12:24 AM, Ken Merry <ken@freebsd.org> wrote:
> The challenge is that the data transfer rate is reset on the target for
> both the initiator doing the reset, and the other initiator.
>
> So re-negotiating from the initiator that did the reset will do no good.
> You need to re-negotiate from the other initiator.
>
> You can either detect the situation from a unit attention (that you will
> get in response from a test unit ready) returned from the target, or you
> can communicate between the nodes so that the other node knows that it
> needs to re-negotiate.
>
> Ken
> =E2=80=94
> Ken Merry
> ken@FreeBSD.ORG
>
>
>
> On Mar 4, 2015, at 2:44 AM, fengyd <fengyd81@gmail.com> wrote:
>
> Hi,
>
> The code to reset the target:
> static void sym_reset_dev(hcb_p np, union ccb *ccb)
> {
> tcb_p tp;
> struct ccb_hdr *ccb_h =3D &ccb->ccb_h;
>
> if (ccb_h->target_id =3D=3D np->myaddr ||
> ccb_h->target_id >=3D SYM_CONF_MAX_TARGET ||
> ccb_h->target_lun >=3D SYM_CONF_MAX_LUN) {
> sym_xpt_done2(np, ccb, CAM_DEV_NOT_THERE);
> return;
> }
>
> tp =3D &np->target[ccb_h->target_id];
>
> tp->to_reset =3D 1;
> sym_xpt_done2(np, ccb, CAM_REQ_CMP);
>
> np->istat_sem =3D SEM;
> OUTB (nc_istat, SIGP|SEM);
> return;
> }
>
> Can target reset set data transfer with the size provided by driver?
>
>
> Thanks for your help.
>
> Br.
> Yafeng
>
> On Wed, Mar 4, 2015 at 5:40 PM, fengyd <fengyd81@gmail.com> wrote:
>
>> Hi,
>>
>> It seems that during initialization, data transfer is set as 16-bit by
>> driver, it is set as 8-bit due to target reset.
>> So it means default data transfer for the drive is 8-bit?
>>
>> -You might try seeing what the ahc(4) and ahd(4) drivers do in this
>> situation.
>> I didn't find the code related with ahc or ahd.
>> Do you know in which release ahc and ahd are implemented?
>>
>> -If you have an idea that this may have happened, you can try doing a bu=
s
>> or target rescan.
>> I just begin to study FREEBSD driver.
>> Could you give some instructions how to do bus or target rescan?
>>
>> -Just out of curiosity, why are you doing multi-initiator with this
>> hardware?
>> Two units needs to access the device at the same time.
>>
>> Thanks for your help.
>>
>> Br.
>> Yafeng
>>
>> On Wed, Mar 4, 2015 at 12:28 AM, Ken Merry <ken@freebsd.org> wrote:
>>
>>> 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 z=
eros.
>>>
>>> The result is that you get 64 bytes of =E2=80=9Cextra=E2=80=9D data, an=
d every other
>>> byte is zero.
>>>
>>> So, you=E2=80=99ll need to figure out a way for the sym(4) driver to fi=
gure 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=E2=80=99t 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 bu=
s
>>> 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 mode=
rn
>>> SAS hardware and expanders.
>>>
>>> Ken
>>> =E2=80=94
>>> Ken Merry
>>> ken@FreeBSD.ORG
>>>
>>>
>>>
>>> On Mar 3, 2015, at 12:50 AM, fengyd <fengyd81@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 Queuein=
g
>>> 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 f=
ails
>>> 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@freebsd.org>
>>> wrote:
>>>
>>>>
>>>> An overrun is exactly what the comment below indicates. It is when th=
e
>>>> target sends back more data than you asked for. You will generally se=
e
>>>> 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 ma=
ny
>>>> 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 i=
s
>>>> 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 |=3D XE_EXTRA_DATA;*
>>>> > cp->extra_bytes +=3D 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@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 =3D 0x10,/* Autosense: request sense cm=
d
>>>> 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@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 =3D 18
>>>> > >> (pass0:sym0:0:0:0): status =3D 82
>>>> > >>
>>>> > >> Do you know what does the error code 82 mean?
>>>> > >>
>>>> > >> Thanks in advance.
>>>> > >>
>>>> > >> Br.
>>>> > >> Yafeng
>>>> > >>
>>>> > >
>>>> > >
>>>> > _______________________________________________
>>>> > freebsd-scsi@freebsd.org mailing list
>>>> > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
>>>> > To unsubscribe, send any mail to "
>>>> freebsd-scsi-unsubscribe@freebsd.org"
>>>>
>>>> --
>>>> Kenneth Merry
>>>> ken@FreeBSD.ORG
>>>>
>>>
>>>
>>>
>>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACnvu8ZfPOAizNE=qw-Cb%2BOGT88eJ_2tqM8%2Bh3yXv=uqwS2YBQ>