What does the error code 82 mean?
fengyd
fengyd81 at gmail.com
Mon Mar 16 08:26:29 UTC 2015
Hi,
case SIR_DATA_OVERRUN:
if (cp) {
OUTONB (HF_PRT, HF_EXT_ERR);
cp->xerr_status |= XE_EXTRA_DATA;
cp->extra_bytes += INL (nc_scratcha);
tp->tinfo.current.width = BUS_8_BIT; // Added here to trigger
re-negotiation
}
goto out;
Before SIR_DATA_OVERRUN,
tp->tinfo.current.width = tp->tinfo.goal.width = BUS_16_BIT;
I added the code to set tp->tinfo.current.width as BUS_8_BIT, which
will trigger re-negotiation next IO request, then everything is OK.
And I found the value width is got from tp->tinfo.goal.width in the
function sym_prepare_nego for the next negotiation message.
So,
the transfer width is still 16-bit after device reset?
What we need to do is to re-negotiate with the target?
And, do you know what re-negotiation actually does?
Thanks
Br.
Yafeng
On Thu, Mar 12, 2015 at 11:21 PM, fengyd <fengyd81 at gmail.com> wrote:
> 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