[245] in NetBSD-Development
Re: [yonah@MIT.EDU: lola-granola]
daemon@ATHENA.MIT.EDU (John Hawkinson)
Sun Dec 4 21:36:48 1994
To: John Kohl <jtk@atria.com>
Cc: netbsd-dev@MIT.EDU, yonah@MIT.EDU
In-Reply-To: Your message of "Sun, 04 Dec 1994 12:23:04 EST."
<9412041723.AA24784@banana>
Date: Sun, 04 Dec 1994 21:36:21 -0500
From: John Hawkinson <jhawk@MIT.EDU>
> From: John Kohl <jtk@atria.com>
> To: netbsd-dev@MIT.EDU, yonah@MIT.EDU
> Looks like someone is chewing up kernel memory... this panic means that
> the memory management code couldn't find allocate a structure it needed,
> and it gave up.
>
> Were folks doing audio stuff at the time? Was there a lot of
> paging/swapping? Where else might a leak be hiding?
Sigh; it doesn't seem improbably that it was the audio stuff, though
I don't think anyone was using it at the time.
At this point, I should come clean -- I should've mentioned a few things
that I'd done here, but hadn't had a chance:
LOLA-DDB was compiled with the sb (soundblaster) driver and
the audio (bsd_audio) pseudodevice.
I changed conf.c slightly wrt the sb driver to avoid it's returning
continual
I built a GENERICAHA kernel using the 1.0A wd.c driver w/ mycroft's
help; this change is in the local source tree (w/ RCS), so new kernels
(including lola's) will contain it; it's unlikely that this will
present problems (the current LOLA-DDB does not have it), but
I oughta mention it.
The following kernels exist in lola-granola:/netbsd*:
359 -rwxr-xr-x 2 root wheel 729102 Nov 28 23:08 /netbsd
359 -rwxr-xr-x 2 root wheel 729102 Nov 28 23:08 /netbsd.lola
NetBSD 1.0 (LOLA-DDB) #37: Mon Nov 28 23:05:14 EST 1994
15 -rwxr-xr-x 1 root wheel 659600 Nov 9 23:52 /netbsd.generic
NetBSD 1.0 (GENERICAHA) #3: Sun Oct 23 20:58:04 PDT 1994
346 -rwxr-xr-x 1 root wheel 734434 Dec 4 02:23 /netbsd.lola.sb
NetBSD 1.0 (LOLA-DDB) #47: Sun Dec 4 02:22:40 EST 1994
Per Greg's request, we're back to netbsd.lola (#37).
Incidently, the initial reason for the sb kernel was to run an mbone
audio client during IETF this week -- it seems that there's an incompatibility
due to the audio client (binary distribution), which I'll try and hack on
some time post-IETF.
--jhawk
