Date: Mon, 5 Jul 1999 21:15:40 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: "Justin T. Gibbs" <gibbs@caspian.plutotech.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: <Pine.BSF.4.05.9907052112300.10459-100000@semuta.feral.com> In-Reply-To: <199907060112.TAA00431@caspian.plutotech.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 In my spare time.... sigh.. glub... > 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. That's what is happening now (finally)- I believe this is the right thing to have happen. It makes system management somewhat easier. > 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. No, that can't be the right thing to do, can it? There is absolutely no guarantee about the order of completion, so that which had been da0 is now da1... I'd actually like to have change the the flags so that you *don't* scan- let the HBA announce devices asynchronously, no? > 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. Let's talk... 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.4.05.9907052112300.10459-100000>