From owner-freebsd-hardware Sun Sep 13 11:50:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA13952 for freebsd-hardware-outgoing; Sun, 13 Sep 1998 11:50:16 -0700 (PDT) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA13935 for ; Sun, 13 Sep 1998 11:50:11 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id MAA05382; Sun, 13 Sep 1998 12:49:40 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199809131849.MAA05382@panzer.plutotech.com> Subject: Re: Buslogic/Mylex HAs In-Reply-To: <199809131809.LAA06566@word.smith.net.au> from Mike Smith at "Sep 13, 98 11:09:02 am" To: mike@smith.net.au (Mike Smith) Date: Sun, 13 Sep 1998 12:49:40 -0600 (MDT) Cc: ken@plutotech.com, Jos.Backus@nl.origin-it.com, hardware@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Smith wrote... > > I've seen panics on -stable and -current with cdda2wav; they seem to be > > related to shared memory usage. It'll probably take someone more familiar > > with the VM system to sort them out, though. The problem doesn't seem to > > be directly attributable to CAM, but it my be exacerbated by CAM. > > > > It looks like cdrecord uses shared memory as well, so the panic may be > > similar. Can you send me a stack trace? > > Just out of curiosity, does the CAM stack use a lazy mechanism for > cleaning up after transfers? It sounds very much like what's happening > here is that the process has been doing I/O to the shared memory > segment, finishes and attempts to delete the segment, but parts of it > are still marked busy. Yeah, that's what it sounds like. The thing is, though, the passthrough driver waits until I/O completion to return to the user. i.e. the ioctl will block until everything is done. If for some reason cdrecord tries to delete the shared memory segment before the last transaction is complete, I can see how there would be a problem. It's also possible that there's a problem with my usage of vmapbuf() and vunmapbuf(), although you'd think I would have seen it by now. (I've been using it for over a year.) It might take a VM expert to figure this one out... Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message