What does the error code 82 mean?
fengyd
fengyd81 at gmail.com
Wed Mar 4 09:44:43 UTC 2015
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