From owner-freebsd-scsi Sun Jul 11 16:24:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 9803F14C32 for ; Sun, 11 Jul 1999 16:24:29 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id RAA07295; Sun, 11 Jul 1999 17:13:36 -0600 (MDT) Date: Sun, 11 Jul 1999 17:13:36 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199907112313.RAA07295@narnia.plutotech.com> To: mjacob@feral.com Cc: scsi@FreeBSD.org Subject: Re: CAM scan order perplexities X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > > Sometimes things seem to hang for me irretrievably when I'm booting- > somewhere usually in the scanning goop that CAM does when you're > booting... Mostly this happens for me with Qlogic FC, but it happens > rarely for me also with the Qlogic SCSI- and it happens a lot for Andrew > Gallatin @ Duke with SCSI on alpha...(I've made things marginally better > for him at the moment by having his isp not scan other than lun 0 and > ignore nvram settings..).... This is likely the problem with not having a thread or process context for doing the parallel probes. > But this is not what this mail is about... I've been playing around with > watching what goes on to try and sort this out, and here's something very > strange.... I've set up a case where I can turn on/off throwing commands > at a device, so I try multiple SCANS... here's a trace of this: This is a known bug. I just haven't gotten around to fixing it yet. The problem is that when devices are scanned, they are announced immediately instead of in a deferred action that ensures correct ordering. During boot, this isn't a problem because there aren't any peripheral drivers 'listening' for AC_FOUND_DEVICE events until after the initial probe is complete. In this case, the XPT will broadcast the AC_FOUND_DEVICE for all devices in the system at the time a driver enables that event. Since that code announces in order, everything works as expected. The good thing is that this is easy to fix. Add an extra flag to cam_ed.flags, CAM_DEV_ANOUNCE_PENDING. In all the places where the xpt currently performs an explicit xpt_async(AC_FOUND_DEVICE, ...), replace that with a function call that checks to see if announcements are blocked and if so, sets the flag. Otherwise, announce as normal. In the xpt_scan_bus code, call a function that locks out anouncements, scan the bus, then call a function that releases announcements, traverses the EDT, and fires an xpt_async(AC_FOUND_DEVICE, ...) for anyone tagged. Much of this code can be stolen from the event enable logic for AC_FOUND_DEVICE. You may want hierarchical blocking so you can set a block for all buses or just a single one, but I don't think that is critical right now. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message