On Thu, 19 Jul 2001, John wrote:

> Most of the m68k ports have problems while allocating / deallocating lots
> of memory. I wrote a letter about this:
>
> http://mail-index.netbsd.org/port-m68k/2001/06/04/0000.html

This is actually a slightly different problem which happens to invoke the
same panic message. The panic in the email you refer to is addressed by
raising the limits as you suggest.

The problem in the PR is due to a limitation in the pmap code for
68040/68060 cpus. I believe all the m68k ports have this limitation
whereby a maximum of 7 level 2 segment tables can be allocated on behalf
of a process. The problem described in the PR does not affect systems with
68020/68030 cpus.

A well behaved process will not notice any problem as long as it doesn't
try to allocate more than 224MB of contiguous virtual address space (each
level 2 segment table can map 32MB of address space). In practice, the
per-process hard limits on VM will kick in before this on most/all m68k
ports.

The problem arises when a process uses mmap(2) to allocate virtual address
space sparsely. It need only allocate one page at a time, but if each page
is > 32MB away from the last the kernel will need to use a new level 2
segment table to map it. Do this 5 times and all 7 will be used up. (Note
that 1 is used for the process' text/data/bss and another for the initial
stack).

The `7 segment table' limit is a hack which needs to die. Since I've had
my head buried in mvme68k's pmap code recently (sorting 060 support) I
might be in a position to look into fixing things.

> I thought nobody took action because there was lots of work to do to
> finalise 1.5.1. Now that it's out, it's time this gets fixed for good.

So no-one forgets it, please send-pr(1), category port-m68k. :)

Cheers, Steve