NetBSD Problem Report #9725

Received: (qmail 13607 invoked from network); 31 Mar 2000 08:11:46 -0000
Message-Id: <200003310710.AAA01781@loop.home>
Date: Fri, 31 Mar 2000 00:10:48 -0700 (MST)
Subject: hp300 pmap panic
X-Send-Pr-Version: 3.95

>Number:         9725
>Category:       port-m68k
>Synopsis:       GNU autoconf mmap() test causes panic in hp300-based m68k pmap code
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    port-m68k-maintainer
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 31 08:16:22 +0000 2000
>Last-Modified:  Thu May 14 07:30:02 +0000 2009
>Originator:     Steve Peurifoy
>Release:        1.4V (20000320)
System: NetBSD loop 1.4V NetBSD 1.4V (loop) #1: Fri Mar 24 18:33:34 MST 2000 root@loop:/usr/src/sys/arch/hp300/compile/loop hp300

Running the "configure" script included with a number of packages will
crash a 68040 based hp300 with "panic: enter: out of address space".
This is a result of an mmap() test run by configure which attempts to
map pieces of memory scattered throughout the address space.  Doing
this exposes a limitation in the hp300 pmap regarding how second level
descriptor blocks are managed.
Other types of tasks can cause the same crash.  For example running
cmp(1) with very large (>200MB) files has induced this panic in my
The following program performs the relevant parts of the mmap() test
executed by the configure script included in "ffcall".  Running this
program will crash a 68040 based hp300 running NetBSD.

#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/mman.h>

int main()

  int        i;
  caddr_t    addr;
  size_t     size = 4096;

  for (i = 1; i <= 64; i++)
    addr = (caddr_t)(i << 24);
    if (mmap(addr, size, PROT_READ | PROT_WRITE,
             MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0) < 0)

  for (i = 1; i <= 64; i++)
    addr = (caddr_t)(i << 24);
    *addr = 0;



Responsible-Changed-From-To: port-hp300-maintainer->port-m68k-maintainer 
Responsible-Changed-By: fredb 
Responsible-Changed-When: Fri Jun 20 19:25:06 CDT 2003 
For what it's worth, the test program panics a 1.6U/mac68k host 
as described, so I guess it's not an hp300 problem, after all. 
From: Hauke Fath <>
Cc: "Hauke Fath" <hauke@Espresso.Rhein-Neckar.DE>
Subject: Re: port-m68k/9725
Date: Mon, 26 May 2008 15:44:06 +0200


 NetBSD 4.0_STABLE (FATTIE) #0: Mon May 26 14:17:53 CEST 2008
 Apple Macintosh Quadra 650  (68040)
 cpu: delay factor 1280
 total memory = 136 MB
 avail memory = 129 MB

 the bug is well and alive. A package bulk-build of pkgsrc-2008Q1 fails 
 reproducibly while running the lang/python23 configure script:

 [hauke@Hochschwab] ~ > panic: enter: out of address space
 Stopped in pid 18822.1 (conftest) at netbsd:cpu_Debugger+0x6: unlk    a6
 db> t
 cpu_Debugger(0,24,a10024,c2bdd48,c2bdd64) + 6
 panic(1ba8a5,4b6a000,0,d2372,12000000) + 118
 pmap_enter_ptpage(a909ad4,12000000) + 62e
 pmap_enter(a909ad4,12000000,4b6a000,3,22) + 1ac
 uvm_fault_internal(ce91968,12000000,2,0) + 7f4
 trap(c2bdf80,8,481,12000060) + 5b2
 faultstkadj() + 4

 Same result with the code in this PR.


       The ASCII Ribbon Campaign                    Hauke Fath
 ()     No HTML/RTF in email	        Institut für Nachrichtentechnik
 /\     No Word docs in email                     TU Darmstadt
       Respect for open standards              Ruf +49-6151-16-3281

State-Changed-From-To: open->analyzed
State-Changed-When: Thu, 14 May 2009 07:09:44 +0000
I guess the problem is understood by now.

From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
Cc: "Hauke Fath" <hauke@Espresso.Rhein-Neckar.DE>
Subject: Re: port-m68k/9725
Date: Thu, 14 May 2009 08:58:19 +0200

 Collecting further evidence... the thread at
 <> has a concise
 analysis of the problem at

 "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

 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)." (Steve Woodford)

 and a possible resolution at

 "On Fri, 20 Jul 2001, Jeremy Cooper wrote:
 > At this point I will stand up on a tiny sopbox and humbly offer that you
 > examine the sun3x pmap.  It is based on a design that Gordon Ross
 > suggested, and I implemented, for the 68030.  It might overcome some of
 > these limitations.

 Oh, nice one. :)

 I had no idea that was in the source tree. It's exactly what's needed to
 solve the 040/060 problem. It actually does so in a similar way to how I'd
 envisioned doing it... ;-)" (Steve Woodford).

 "It's never straight up and down"     (DEVO)


NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.