Date: Sun, 13 Sep 1998 12:49:40 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: mike@smith.net.au (Mike Smith) Cc: ken@plutotech.com, Jos.Backus@nl.origin-it.com, hardware@FreeBSD.ORG Subject: Re: Buslogic/Mylex HAs Message-ID: <199809131849.MAA05382@panzer.plutotech.com> In-Reply-To: <199809131809.LAA06566@word.smith.net.au> from Mike Smith at "Sep 13, 98 11:09:02 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809131849.MAA05382>