Date: Mon, 05 Jul 1999 19:12:05 -0600 From: "Justin T. Gibbs" <gibbs@caspian.plutotech.com> To: mjacob@feral.com Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, "Kenneth D. Merry" <ken@plutotech.com>, scsi@freebsd.org Subject: Re: just so you all know how really whacky it can get... Message-ID: <199907060112.TAA00431@caspian.plutotech.com> In-Reply-To: Your message of "Fri, 02 Jul 1999 18:39:18 PDT." <Pine.BSF.4.05.9907021829450.356-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >I've added Fabric support and also added/tested for SCCLUN.... > >While doing a rescan on a SCCLUN enabled (16 bit luns) through a switch... >this sort of leads me to believe that we need some more flags so that an >HBA can inform CAM that an exhaustive search isn't needed- or at least I >need to try and implement the REPORT LUNS command... at some point it >rebooted (I didn't yet catch why).... really pretty amusing: Take a look at the CAM3 spec's 'bind' interface and how it defines the path inquiry data. I'd like to move in this direction (CAM paths become bind handles or some-such), but it looks like, based on the recent working group meeting, that the bind stuff will be simplified a bit. There was a proposal for forcing SIMs to present a 'static' address to the XPT across LIP events even if the device's loop id changed. Unfortunately I don't know enough about fiber channel to critique the spec or the proposal. The other problem that you are running into is that we currently don't have a kernel thread dedicated to performing rescan operations and we attempt to scan all possible targets in parallel. I thought that I had the necessary tests in there to error out cleanly, but I guess that isn't the case. As soon as I catch a breath here, I'd like to move forward on CAM2->CAM3 transition issues as well as give the XPT it's own thread so that we can keep the parallel probe framework, and gracefully run even with limited memory resources. REPORT LUNS and how to deal with SCSI3 devices in general certainly needs to be addressed before 4.0 as well. If you have ideas in this area, please pass them on. I should be back working on CAM heavily in about two weeks time. -- 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?199907060112.TAA00431>