test at Target mode

[Kayoko Isshi]

M.Gibbs:

Thanks for some advices.

"Justin T. Gibbs" wrote:

> >> As noted above, the interface is for FreeBSD only.  FreeBSD's SCSI
> >> layer (CAM) has explicit support for target mode operations.  Linux
> >> has yet to gain such features.
> >
> >Is that difficult to realize under Linux?
> >For example,new upper driver will support new target driver interface.
>
> Adding an "integrated" target mode system to Linux would be difficult.
> Adding some add-hoc system bypassing all of the mid-level queues, etc.
> might work, but would require more work at the low-level driver layer.
> If you look at the semantics guaranteed by CAM for target mode (see
> the ANSI spec from www.t10.org and peruse the FreeBSD code in sys/cam),
> I think you'll agree that target mode is often more complicated than
> initiator mode to implement.

We would realize it with Adaptec target driver under Linux without CAM.

> > >2)Once a BusReset occurred,following BusReset is ignored.
> > >    ->I forced to set ENSCSIRST bit in SIMODE1(ahc_restart).
> > >    I set ENRSTI bit in SCSISEQ_TEMPLATE,but that's no effect.
> >
> > This is by design.  Bus resets are only of interest when:
> >
> > 1) This is the first bus reset since power on.
> >
> > 2) We have outstanding commands as either a target or an initiator.
> >
> > So, once we see a bus reset, we disable them until the next outgoing
> > (as initiator) or incoming (as target) command.  This prevents the
> > driver from being held hostage to a third party holding the reset
> > line for extrememly long periods of time which would result in an
> > interrupt storm.  Semantically, there is no difference if we ignore
> > any of these "extra" bus resets.
>
> Sorry.
> Your design is right:target driver should reset only once.
> After that,I read the comment about BusReset in sequencer code,and I got
> it.

This question has revived.
Your design is logically right ,but it's not right in my condition.
When the 2nd BusReset continues to occur, ENSELI bit in SCSISEQ is reset by
anyone.
Do you know who reset it?

> >> >6)Sequencer code)When set DISCENB in SCB_CONTROL and reconnected,
> >> >MegOut=8x sent.
> >> >    ->setting MSG_IDENTIFY_DISCFLAG added.
> >>
> >> The format of target SCBs is different than for normal SCBs.  See
> >> the FreeBSD driver for details:
> >>
> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/aic7xxx
> >
> >I found no MSG_IDENTIFY_DISCFLAG in aic7xxx_freebsd.c.
> >I guess that MSG_IDENTIFY_DISCFLAG bit should be included in SCB_LUN.
> >Is that right?
>
> No.  On a reselection, the target must always respond without the
> disconnect flag set.  See the SCSI spec for details.  The key here
> is honoring the DISCENB flag in the SCB so that the driver does not
> attempt to disconnect at any time during the transaction (e.g. multiple
> "continue target I/Os" processed in a single physical connection).

I thank you to correct Identify message spec.
I misunderstood the spec because target HBA on QLA1xxx always responds
Identify message with DISCPRIV flag.
Now I have reconfirmed to complete "insmod QLA1xxx" when target HBA on
AIC7899
responded the message without DISCPRIV flag.


Thanks.

----------
Kayoko Isshi



To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message