Date: Tue, 6 Jul 1999 00:07:36 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: "Justin T. Gibbs" <gibbs@caspian.plutotech.com> Cc: mjacob@feral.com, "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: <Pine.BSF.3.95.990706000426.21562A-100000@current1.whistle.com> In-Reply-To: <199907060112.TAA00431@caspian.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 Jul 1999, Justin T. Gibbs wrote: > > > >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. The last version of the SLICE code I had working here used a general purpose rescan daemon, I called it 'deviced' but that was basically what it did. It accepted probe requests which it would queue and then perform at a later time. I was about half way through getting it working properly on X-day. > > 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 > 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.BSF.3.95.990706000426.21562A-100000>