Subject: Re: 1.4 pmax buglets?
To: Andy Doran <>
From: Simon Burge <>
List: port-pmax
Date: 04/20/1999 14:01:58
Andy Doran wrote:

> On Tue, 20 Apr 1999, Simon Burge wrote:
> > People are still getting the problem - Tracy J. Di Marco White got a
> > "panic: uvm_km_suballoc: unable to allocate space in parent map" on a 3
> > day old 1.4_ALPHA kernel.  I've not seen the problem at all on machines
> > with 24MB, 32MB, 96MB and 128MB of RAM...
> I think it's related to image size. It happens every now and again to me.
> If I add/remove a bit of code I'm working on, it magically disappears.
> We're loosing at least 128kB VA range worth of PTEs, otherwise the first
> uvm_km_suballoc would suceed.

Gee, that's gonna be easy to reproduce :-)  I've got a /133 with 32MB,
I'll give that a go and see what happens...

> > >     * bswap{16,32} and .abicalls  for libsa/libkern?
> > >       (the .abicalls are supposed to be protected by an ifdef
> > >       which  standalone/kernel code is supposed to turn on)
> > 
> > Stand-alone stuff (bootblocks) builds ok.  On the 1.4 branch, the kernel
> > compiles cleanly, but I've just noticed that -current breaks because
> > -DABICALLS to passed to ${CC} for all the .S files and thus generates
> > PIC code and the kernel link fails.  It looks like the simplest fix is
> > to remove the ABICALL dance from libkern/byte_swap_?.S.  In fact I've
> I think I already suggested this, but was waiting for a reply.

Must have missed it.  Anyways, I've removed all the .abicall gunk
from the libkern byte_swap_?.S files so now they're out of sync with
libc/arch.  This will be reverted when/if <> is fixed.