From owner-freebsd-bugs  Thu Nov 20 12:00:09 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA02004
          for bugs-outgoing; Thu, 20 Nov 1997 12:00:09 -0800 (PST)
          (envelope-from owner-freebsd-bugs)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA01979;
          Thu, 20 Nov 1997 12:00:02 -0800 (PST)
          (envelope-from gnats)
Resent-Date: Thu, 20 Nov 1997 12:00:02 -0800 (PST)
Resent-Message-Id: <199711202000.MAA01979@hub.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, dillon@best.net
Received: from flea.best.net (root@flea.best.net [206.184.139.131])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA01512
          for <FreeBSD-gnats-submit@freebsd.org>; Thu, 20 Nov 1997 11:54:14 -0800 (PST)
          (envelope-from dillon@flea.best.net)
Received: (from dillon@localhost) by flea.best.net (8.8.7/8.7.3) id LAA04207; Thu, 20 Nov 1997 11:53:34 -0800 (PST)
Message-Id: <199711201953.LAA04207@flea.best.net>
Date: Thu, 20 Nov 1997 11:53:34 -0800 (PST)
From: Matt Dillon <dillon@best.net>
Reply-To: dillon@best.net
To: FreeBSD-gnats-submit@FreeBSD.ORG
X-Send-Pr-Version: 3.2
Subject: kern/5108: Kernel panic in pmap_release during wait4
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         5108
>Category:       kern
>Synopsis:       pmap_release panics with 'freeing held page table page'
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov 20 12:00:01 PST 1997
>Last-Modified:
>Originator:     Matt Dillon
>Organization:
Best Internet Communications
>Release:        FreeBSD 2.2.5-STABLE i386
>Environment:

	FreeBSD 2.2.5 on PPro 200, medium to heavily loaded systems

>Description:

	We got a kernel panic 'pmap_release: freeing held page table page'.
	We got a core.  The backtrace showed:

...
#7  0xf01be634 in trap (frame={tf_es = 0x10, tf_ds = 0x10, 
      tf_edi = 0xf97cc000, tf_esi = 0xf01bb38a, tf_ebp = 0xefbffe94, 
      tf_isp = 0xefbffe78, tf_ebx = 0x100, tf_edx = 0xf01b5051, 
      tf_ecx = 0x3f9, tf_eax = 0x12, tf_trapno = 0x3, tf_err = 0x0, 
      tf_eip = 0xf01b5089, tf_cs = 0x8, tf_eflags = 0x256, 
      tf_esp = 0xf01b5041, tf_ss = 0xf01131f8}) at ../../i386/i386/trap.c:403
#8  0xf01b5089 in Debugger (msg=0xf01131f8 "panic")
    at ../../i386/i386/db_interface.c:254
#9  0xf011325a in panic (
    fmt=0xf01bb38a "pmap_release: freeing held page table page")
    at ../../kern/kern_shutdown.c:388
#10 0xf01bb455 in pmap_release_free_page (pmap=0xf2d3d864, p=0xf0aead08)
    at ../../i386/i386/pmap.c:1072
#11 0xf01bb69f in pmap_release (pmap=0xf2d3d864) at ../../i386/i386/pmap.c:1260
#12 0xf01a6708 in vmspace_free (vm=0xf2d3d800) at ../../vm/vm_map.c:262
#13 0xf01bf33d in cpu_wait (p=0xf288b800) at ../../i386/i386/vm_machdep.c:650
#14 0xf010cef5 in wait1 (q=0xf2392000, uap=0xefbfff94, retval=0xefbfff84, 
    compat=0x0) at ../../kern/kern_exit.c:460
#15 0xf010cd23 in wait4 (p=0xf2392000, uap=0xefbfff94, retval=0xefbfff84)
    at ../../kern/kern_exit.c:357
#16 0xf01bf077 in syscall (frame={tf_es = 0x27, tf_ds = 0x27, 
      tf_edi = 0xefbfdd8c, tf_esi = 0xa168, tf_ebp = 0xefbfdca8, 
      tf_isp = 0xefbfffe4, tf_ebx = 0x20084060, tf_edx = 0x13, tf_ecx = 0x0, 
      tf_eax = 0x7, tf_trapno = 0x7, tf_err = 0x7, tf_eip = 0x2004e0a1, 
      tf_cs = 0x1f, tf_eflags = 0x216, tf_esp = 0xefbfdc90, tf_ss = 0x27})
    at ../../i386/i386/trap.c:890

    It appears that inetd was trying to do a wait4 on a telnetd sub process
    when the crash occured.  There were around 40 telnetd processes running
    at the time.

    At a guess I would say vmspace_free has a race with other telnetd's
    that might be exiting orforking at the same time.  I dunno.

>How-To-Repeat:

    no idea.

>Fix:
	
    no idea.

>Audit-Trail:
>Unformatted: