NetBSD Problem Report #40552

From njoly@lanfeust.sis.pasteur.fr  Wed Feb  4 12:29:40 2009
Return-Path: <njoly@lanfeust.sis.pasteur.fr>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id E402763B879
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  4 Feb 2009 12:29:39 +0000 (UTC)
Message-Id: <20090204122936.8B94A6B489@lanfeust.sis.pasteur.fr>
Date: Wed,  4 Feb 2009 13:29:36 +0100 (CET)
From: njoly@pasteur.fr
Reply-To: njoly@pasteur.fr
To: gnats-bugs@gnats.NetBSD.org
Subject: Early kernel panic with POOL_DIAGNOSTIC option
X-Send-Pr-Version: 3.95

>Number:         40552
>Category:       kern
>Synopsis:       Early kernel panic with POOL_DIAGNOSTIC option
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 04 12:30:00 +0000 2009
>Closed-Date:    
>Last-Modified:  Sun Nov 15 01:43:02 +0000 2009
>Originator:     Nicolas Joly
>Release:        NetBSD 5.99.7
>Organization:
Biological Software and Databanks.
Institut Pasteur, Paris.
>Environment:
System: NetBSD lanfeust.sis.pasteur.fr 5.99.7 NetBSD 5.99.7 (LANFEUST) #28: Mon Feb 2 12:05:52 CET 2009 njoly@lanfeust.sis.pasteur.fr:/local/src/NetBSD/obj.amd64/sys/arch/amd64/compile/LANFEUST amd64
Architecture: x86_64
Machine: amd64
>Description:
A kernel with option POOL_DIAGNOSTIC don't work and panics early at boot,
when trying to allocate the pool log buffer.

>> NetBSD/x86 BIOS Boot, Revision 5.3 (from NetBSD 5.99.5)
>> Memory: 639/2096064 k
Press return to boot now, any other key for boot menu
booting hd0a:netbsd - starting in 0 
type "?" or "help" for help.
> boot netbsd.ko
booting hd0a:netbsd.ko
9987696+487264+711200 [682416+453630]=0xcc1530
Loading ffs  
fatal protection fault in supervisor mode
trap type 4 code 0 rip ffffffff80441b80 cs 8 rflags 10287 cr2  0 cpl 8 rsp fffff
fff8102ed50
kernel: protection fault trap, code=0
Stopped in pid 0.1 (system) at  netbsd:kern_malloc+0x310:       movw    %cx,0(%r
ax)
db{0}> bt
kern_malloc() at netbsd:kern_malloc+0x310
pool_init() at netbsd:pool_init+0x396
uvm_km_vacache_init() at netbsd:uvm_km_vacache_init+0xae
kmeminit() at netbsd:kmeminit+0x99
uvm_init() at netbsd:uvm_init+0x62
main() at netbsd:main+0x35

njoly@lanfeust [amd64/conf]> cat GENERIC_DEBUG 
include "arch/amd64/conf/GENERIC"
options         DDB_ONPANIC=1
makeoptions     DEBUG="-g"
options         POOL_DIAGNOSTIC

>How-To-Repeat:
Try to boot a kernel with POOL_DIAGNOSTIC option enabled.
>Fix:
n/a

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->analyzed
State-Changed-By: rmind@NetBSD.org
State-Changed-When: Sun, 15 Nov 2009 01:43:02 +0000
State-Changed-Why:
While initialising in kmeminit(), subsystem calls itself, that is, malloc()s
via uvm_km_vacache_init().  Moving uvm_km_vacache_init() further or setting
kmem_map later (which is checked in pool_init(), before allocating) might fix
the problem.  However, looking at how long it was unnoticed, I wonder if
POOL_DIAGNOSTIC helps a lot these days?


>Unformatted:

Home	PR Database Search