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)
From: swp@alumni.rice.edu
Reply-To: swp@alumni.rice.edu
To: gnats-bugs@gnats.netbsd.org
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
>Closed-Date:    
>Last-Modified:  Thu May 14 07:30:02 +0000 2009
>Originator:     Steve Peurifoy
>Release:        1.4V (20000320)
>Organization:
>Environment:
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


>Description:
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
system.
>How-To-Repeat:
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)
      {
      exit(1);
      }
    }

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

  exit(0);

  }

>Fix:
>Release-Note:
>Audit-Trail:
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 
Responsible-Changed-Why:  
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 <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: "Hauke Fath" <hauke@Espresso.Rhein-Neckar.DE>
Subject: Re: port-m68k/9725
Date: Mon, 26 May 2008 15:44:06 +0200

 On

 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
 db>

 Same result with the code in this PR.

 	hauke

 -- 
       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-By: hauke@NetBSD.org
State-Changed-When: Thu, 14 May 2009 07:09:44 +0000
State-Changed-Why:
I guess the problem is understood by now.


From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: gnats-bugs@NetBSD.org
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
 <http://mail-index.NetBSD.org/port-m68k/2001/07/oindex.html> has a concise
 analysis of the problem at

 <http://mail-index.NetBSD.org/port-m68k/2001/07/19/0002.html>
 "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)." (Steve Woodford)


 and a possible resolution at

 <http://mail-index.NetBSD.org/port-m68k/2001/07/21/0000.html>
 "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)


>Unformatted:

Home	PR Database Search