What does the error code 82 mean?
fengyd
fengyd81 at gmail.com
Thu Mar 12 15:22:07 UTC 2015
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 at 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
> —
> Ken Merry
> ken at FreeBSD.ORG
>
>
>
> On Mar 4, 2015, at 2:44 AM, fengyd <fengyd81 at 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 = &ccb->ccb_h;
>
> if (ccb_h->target_id == np->myaddr ||
> ccb_h->target_id >= SYM_CONF_MAX_TARGET ||
> ccb_h->target_lun >= SYM_CONF_MAX_LUN) {
> sym_xpt_done2(np, ccb, CAM_DEV_NOT_THERE);
> return;
> }
>
> tp = &np->target[ccb_h->target_id];
>
> tp->to_reset = 1;
> sym_xpt_done2(np, ccb, CAM_REQ_CMP);
>
> np->istat_sem = 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 at 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 bus
>> 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 at 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 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>
>>> 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> 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> 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 mailing list
>>>> > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
>>>> > To unsubscribe, send any mail to "
>>>> freebsd-scsi-unsubscribe at freebsd.org"
>>>>
>>>> --
>>>> Kenneth Merry
>>>> ken at FreeBSD.ORG
>>>>
>>>
>>>
>>>
>>
>
>
More information about the freebsd-scsi
mailing list