From owner-freebsd-bugs Thu Jun 18 07:31:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA12043 for freebsd-bugs-outgoing; Thu, 18 Jun 1998 07:31:11 -0700 (PDT) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA12036 for ; Thu, 18 Jun 1998 07:31:10 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id HAA09898; Thu, 18 Jun 1998 07:30:01 -0700 (PDT) Date: Thu, 18 Jun 1998 07:30:01 -0700 (PDT) Message-Id: <199806181430.HAA09898@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Stefan Eggers Subject: Re: bin/5134: cdcontrol will eject a mounted CDROM Reply-To: Stefan Eggers Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/5134; it has been noted by GNATS. From: Stefan Eggers To: freebsd-gnats-submit@freebsd.org, obrien@NUXI.com Cc: seggers@semyam.dinoco.de Subject: Re: bin/5134: cdcontrol will eject a mounted CDROM Date: Thu, 18 Jun 1998 11:53:25 +0200 As it is kern and not bin and the subject is too misleading I think a separate problem report is a good idea. I file one after finishing this reply. The problem of ejecting a mounted CD-ROM with cdcontrol is still one I think. Even w/o a panic it can cause enough trouble. So this PR still has a reason to live on. > I did something similar. I had a CD mounted and at the same time xmcd > was running waiting for an audio CD. > > The interesting part is that I have xmcd configured to unlock the tray > and it did this though the CD was mounted. I opened it by accident, > saw what I did and closed it again. > > Before the drive recognized that I inserted a CD (my 12x SCSI CD drive > takes some time for this) I did an unmount on it and got a panic. I did some investigation and an experiment. The panic only shows up when I do not access the CD's directory. If I do an "ls" before eject with unmount everything is fine. So I took a look at the locking operations the cd9660 file system does on inodes and vnodes as my thought was that the accesses to some directory or file will probably lock the node and thus then the VREF() is legal. W/o the lookup the node is as unlocked as when it was created. Trying a VREF() on it will cause the panic. I didn't understand it, yet (only looked at it for a few minutes) but it seems as if the name lookup in cd9660_lookup.c locks them on its way down but does not unlock them. That would explain why a simple "ls" on the CD-ROM prevented the panic. It was locked by the lookup already. Stefan. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message