NetBSD Problem Report #16624

Received: (qmail 28860 invoked from network); 3 May 2002 08:31:19 -0000
Message-Id: <200205030829.g438TUv09863@mod80.mrynet.com>
Date: Fri, 3 May 2002 03:29:31 -0500 (CDT)
From: sgimips@mrynet.com
Reply-To: sgimips@mrynet.com
To: gnats-bugs@gnats.netbsd.org
Subject: panic: kernel diagnostic assertion
X-Send-Pr-Version: 3.95

>Number:         16624
>Category:       port-sgimips
>Synopsis:       kernel panics: kernel diagnostic assertion
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    rafal
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 03 08:32:00 +0000 2002
>Closed-Date:    Wed May 21 01:16:10 +0000 2003
>Last-Modified:  Thu Nov 27 11:12:43 +0000 2003
>Originator:     Scott G. Taylor
>Release:        NetBSD 1.5ZC
>Organization:
	MRYNet
>Environment:
System: NetBSD mod80 1.5ZC NetBSD 1.5ZC (GENERIC) #2: Thu May 2 22:36:46 CDT 2002 root@mod80:/sgimips/src/sys/arch/sgimips/compile/GENERIC sgimips
Architecture: mipseb
Machine: sgimips
>Description:
panic: kernel diagnostic assertion "umap->refcount != 0" failed: file "/sys/arch/sgimips/compile/GENERIC_L2/../../../../uvm/uvm_bio.c", line 253

Stopped in pid 4816 (netstat) at        cpu_Debugger+0x4:       jr      ra
                bdslot: nop
db> trace
cpu_Debugger+4 (8ffff000,d,0,0) ra 88105a00 sz 0
panic+124 (881bd42c,d,0,5) ra 881b0b3c sz 40
__assert+2c (881bd42c,d,fd,5) ra 88163838 sz 32
ubc_fault+f8 (881bd42c,d,fd,5) ra 0 sz 112
User-level: pid 4816
db> cont
syncing disks... 
  Machine hangs here.
>How-To-Repeat:
	Unknown.  Has occured twice in 5 days.  Has happened after 03h00
	both times--Once while machine was loaded, once while idle.
	cron shows that at 03h15 each night, /etc/daily is run.  /etc/daily
	runs manually without error.
>Fix:
	Unknown.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: rafal 
State-Changed-When: Tue Apr 8 13:22:29 PDT 2003 
State-Changed-Why:  
It's been a year+ since this report and I've not seen any related lossage 
reported.  Have you had this happen since then?  Having poked through the 
PR database there are a few reports of similar panics in different envir- 
onments and ~ all have been non-reproducible (with one case of "it went 
away on it's own") but all seem to be caused by some form of kernel memory 
corruption (my best guess). 

Please report if you see this again, if not I'm going to mark the PR as 
"dead" (meaning non-closed, but not active) in a little while. 
Responsible-Changed-From-To: port-sgimips-maintainer->rafal 
Responsible-Changed-By: rafal 
Responsible-Changed-When: Tue Apr 8 13:28:04 PDT 2003 
Responsible-Changed-Why:  
Set me to owner so I get any feedback from Scott (if there is any) and so I 
get nagged about it to mark it dead if nothing related to this happens in 
the near future. 
State-Changed-From-To: feedback->dead 
State-Changed-By: rafal 
State-Changed-When: Wed May 21 01:15:02 UTC 2003 
State-Changed-Why:  
Per Scott, the problem has not re-appeared since and lots of things have 
changed. 
State-Changed-From-To: dead->closed 
State-Changed-By: jdolecek 
State-Changed-When: Thu Nov 27 11:12:10 UTC 2003 
State-Changed-Why:  
Apparently fixed (problem no longer happens), so the proper state 
is 'closed', not 'dead'. 
>Unformatted:
 	CVS date 20020419

Home	PR Database Search