Date: Wed, 24 Jan 2001 19:43:10 -0700 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: "Derren L." <derrenl@synology.com> Cc: "Iain Templeton" <iain@research.canon.com.au>, "cheen" <cheen@synology.com>, freebsd-scsi@FreeBSD.ORG Subject: Re: More target mode observations Message-ID: <200101250243.f0P2hAs05296@aslan.scsiguy.com> In-Reply-To: Your message of "Sun, 21 Jan 2001 14:45:41 %2B0800." <GEEFJMCKIIIJMAFBHIPNCEHFCAAA.derrenl@synology.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>Following up to myself with a bit more info, I've been tied up with things, but I'll try to look into this tomorrow. Target mode has worked, but I must have broken something recently. I'm sure it won't take me long to figure out what. >>The other thing is that I only get bus reset intermittantly, which >>worries me. By this I mean that I can do a camcontrol reset <bus> on one >>machine, and the other machine doesn't always pick it up (I don't get >>he "Somebody reset bus %d" message). This is actually a feature. The bus reset interrupt is disabled when a reset is first detected. It is only re-enabled once a reset will again effect state. That is, the interrupt will be re-enabled just before the first "select-out" as an initiator, and just after a "select-in" as a target. This prevents poorly implemented devices (usually initiators) from causing interrupt storms should they hold the reset line for long periods of time (several ms usually). If your system is doing real-time processing, having your interrupt handler called all the time to service no-op bus resets makes it difficult to meet your real-time constraints. 8-) -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101250243.f0P2hAs05296>