Date: Fri, 20 Jul 2001 06:49:43 -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: <200107201249.f6KCnhU33564@aslan.scsiguy.com> In-Reply-To: Your message of "Mon, 16 Jul 2001 15:27:20 %2B0900." <3B528948.FF1D5A9@cs.fujitsu.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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? After checking with a hardware engineer, it appears that the chip ( at least the 7899, but perhaps some of the older ones too) automatically resets this bit on either an outgoing or incoming bus reset. In 6.2.0, I've chnaged the target mode reset behavior to re-enable the interrupt immediately after we see a reset. This leaves us open to the "interrupt storm" problems I listed before, but at least ensures that we will always respond to selection. Targets are supposed to respond to selection "as soon as possible" after a reset, so reducing the interrupt rate by setting a timer to re-enable select-ins every few milliseconds probably wouldn't cut it. I'll have to go review the SPI-4 and SAM-2 specs again. -- 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?200107201249.f6KCnhU33564>