From owner-freebsd-hackers Tue Apr 29 18:08:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA21936 for hackers-outgoing; Tue, 29 Apr 1997 18:08:39 -0700 (PDT) Received: from sendero.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA21891 for ; Tue, 29 Apr 1997 18:08:29 -0700 (PDT) Received: (qmail 10789 invoked by uid 1000); 30 Apr 1997 00:46:53 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199704291010.UAA30468@godzilla.zeta.org.au> Date: Tue, 29 Apr 1997 17:09:24 -0700 (PDT) Organization: iConnect Corp. From: Simon Shapiro To: Bruce Evans Subject: Re: A Desparate Plea for Help... Cc: freebsd-hackers@freebsd.org, msmith@atrad.adelaide.edu.au Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Bruce Evans; On 29-Apr-97 you wrote: > >Please keep me up to date on the results of your LKM-related tests. If > >it turns out that there's a problem with unloading LKMs leaving occupied > >but invalid devsw entries around we'd better fix it 8) > > Er, AFAIK unloading LKM drivers is broken in all cases. It certainly > doesn't work for either of the officially supported LKM cdevs (joy > and qcam). Unloading either of these and then attempting to opening > the nonexistent device gives precisely the trap at _spec_open+0x6e that > Simon reported (the devsw entry is not affected by unloading and points > to garbage). Unloading followed by reloading obviously can't work, > because the driver only initializes the devsw once. So this is probably it. The OSS driver somehow unloads (or does somthing akin to that) and then fvwm2 tries to access the sound devices (the obligatory boing!), and poof! - here comes the fsck. Speaking of fsck, I am still getting a malloc failure in fsck -p, which runs at the top of /etc/rc. I kludged a ``ulimit -too_many_resources_for_everything'' into the script and now it runs fine. This problem rears its ugly head with file systems of 4GB or more, especially if you have many of them. Fsck probably mallocs table spave for all the entries it finds in /etc/fstab, upfront. either we fix fsck to specifically raise its limits, before starting (or if failing to malloc), or adopt the /etc/rc kludge. If there is an ``owner'' for this code, please contact me, or I can submit the patches myself. Simon