Date: Fri, 19 Mar 1999 12:31:27 -0700 (MST) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: mjacob@feral.com Cc: scsi@FreeBSD.org Subject: Re: SCSI resets in CAM during startup.... Message-ID: <199903191931.MAA15479@narnia.plutotech.com> In-Reply-To: <Pine.LNX.4.04.9903181122560.23804-100000@feral-gw>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <Pine.LNX.4.04.9903181122560.23804-100000@feral-gw> you wrote: > > (yes, I know I'm supposed to be working on tape stuff, but I had to put on > another hat today...gawd, my head aches....) > > > 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. > 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. > 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. > If I implement this in the Qlogic as the BUS_RESET command, it basically > then has to traverse the entire loop and send a FCP CMND_IU to all logged > in targets with the RESET_TARGET task management function. This can be > really problematic for a lot of loop configurations, as well as being > completely unnecessary from a state point of view. > > If I implement this as a Loop Reset or a LIP, that's even more drastic. > > What I've been doing up until now is ignoring the XPT_RESET_BUS for Fibre > Channel, but that's not right either. > > This also plays all into #b, where you really don't want to issue bus > resets at all if you can help it. The current Qlogic parallel SCSI code > actually forces async/narrow as it's first state so state management is a > bit easier. > > 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. -- 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?199903191931.MAA15479>