Date: Sun, 21 Mar 1999 11:46:48 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Cc: scsi@FreeBSD.org Subject: Re: SCSI resets in CAM during startup.... Message-ID: <Pine.LNX.4.04.9903211139030.2952-100000@feral-gw> In-Reply-To: <199903191931.MAA15479@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I'd like to make a request- I'd like the initial SCSI reset done currently > > by the CAM probe framework to be: > > > > a) The responsibility/discretion of the hba driver to perform. > > Hmm. I've added the ability for the HBA to request that the initial > bus reset not occur a little while ago. Take a look at the PIM_NOBUSRESET > flag for the path inquiry ccb. This flag only effects bus reset requests > during initial probe situations. I added it for target mode. Missed that. > > > b) Config option'ed off (for a CAM_MULTI_INITIATOR) option. > > I agree that you should be able to indicate that a particular bus > is connected to multiple initiators, but I don't know that a single > option switch affecting all busses is the right solution. Before > anything can happen here, the probe code in cam_xpt needs to be > modified so that, in the case of no bus reset, the controller is > told to perform negotiation with the first command on the bus. Otherwise > outstanding transfer negotiations left over by the BIOS will screw things > up. This is on my white board. Okay. > > > One reason for #a is that the Fibre Channel equivalent of this is > > pretty heavy weight. > > For Fiber Channel, the initial bus reset is not necessary as no > transfer negotiation ever occurs. The proper solution here is for > the code in cam_xpt.c to query the controller to see if negotiation > is possible on that controller and to only perform the bus reset > if there is the posiblity of a stale negotiation. This should be > an easy thing to fix. Or the PIM_NOBUSRESET will work. It's probably okay for later resets since that's done only as a last extreme. >,.. > > > > Opinions? > > Perhaps we need to have a larger 'reset' vocabulary? For Fibre-Channel, > these are only going to occur in the event of error recovery or an explicit > user request, but even so, you should be able to better express what you > are attempting to achieve with the reset. Well, we have 'reset device' and 'reset bus'. I'm not sure others are needed until the semantics are worked out. 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?Pine.LNX.4.04.9903211139030.2952-100000>