Date: Thu, 12 Jul 2001 07:28:52 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Kayoko Isshi <isshi@cs.fujitsu.co.jp> Cc: "'aic7xxx@FreeBSD.ORG'" <aic7xxx@FreeBSD.ORG> Subject: Re: test at Target mode Message-ID: <200107121328.f6CDSqU52801@aslan.scsiguy.com> In-Reply-To: Your message of "Thu, 12 Jul 2001 19:29:46 %2B0900." <3B4D7C1A.80CCBFA3@cs.fujitsu.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
>Dear ML-members: > >I have tested (new) AIC7xxx driver(6.1.13) at target mode. > >In this ML, target driver has few disccusion. >The followings will be unuseful for almost people. >But I will mail because we need the best target driver for AIC7xxx. The target mode support for the AIC7XXX driver was designed and only tested under FreeBSD. Most if not all of the issues you list in this mail are due to expectations of how the OSM layer of the driver will setup SCBs and or handle certain types of events. >Changed: >1)At first,I get compiled errors when I forced targe mode enable. > #define AHC_TARGET_MODE 1 > ->Maybe some definitions for upper driver interface incompletely >provided. > Therefore I left TARGET_MODE disable. 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. >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. >3)Sequencer code)p_data has some routes to go to ITloop at target mode. I'll have to see if I've introduced any bugs in that area with newer sequencer drops. if the TARGET bit is set, we should always return to the target event loop. >4)Sequencer code)ENSELO bit has never be set, > even if the bit in SCSISEQ_TEMPLATE set. > ->when ENSELO bit forced to set with TEMODE,target is selected. > Is there another method? ENSELO will only be set if both initiator and target mode operation are enabled at the same time. ENSELO is not used for target mode operation. >5)Sequencer code)At no disconnect mode(MsgOut=80),data phase stopped in >DT mode. > ->calling set_trasfer_settings before changing data phase will be >needed. Actually, this is handled by the kernel driver rather than consume code in the sequencer. The sequencer is already paused and we have to write to card registers anyway, so setting two more is cheaper than adding more sequencer instructions. >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/ -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107121328.f6CDSqU52801>