From owner-freebsd-scsi Tue Jul 6 0: 7:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 79BF614C0C for ; Tue, 6 Jul 1999 00:07:47 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id AAA45221; Tue, 6 Jul 1999 00:07:38 -0700 (PDT) Date: Tue, 6 Jul 1999 00:07:36 -0700 (PDT) From: Julian Elischer To: "Justin T. Gibbs" Cc: mjacob@feral.com, "Justin T. Gibbs" , "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: just so you all know how really whacky it can get... In-Reply-To: <199907060112.TAA00431@caspian.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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