Bug 17905

Summary: 4.0-SNAP keep on crashing every 3 days
Product: Base System Reporter: jdli <jdli>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.0-STABLE   
Hardware: Any   
OS: Any   

Description jdli 2000-04-10 17:00:01 UTC
	This machine was stable for years, but is experiencing constantly
	crash every 3 days after upgrading to 4.0-STABLE.
	This is a heavy-loaded server for all kinds of FreeBSD service.
	
	The panic message is "vrele: negative ref cnt", but previous 2
	panic messages were both "vdrop: holdcnt".
	
	gdb output is followed :

GNU gdb 4.18
IdlePTD 3010560
initial pcb at 26eb40
panicstr: vrele: negative ref cnt
panic messages:
---
panic: vrele: negative ref cnt

syncing disks... 43 1
done
Uptime: 2d21h6m5s
amrd0: still open, can't shutdown

dumping to dev #da/0x20001, offset 262168
dump 383 382 381 380 379 ... ... ... ... 5 4 3 2 1 0
---
#0  boot (howto=256) at ../../kern/kern_shutdown.c:304
304			dumppcb.pcb_cr3 = rcr3();

(kgdb) where
#0  boot (howto=256) at ../../kern/kern_shutdown.c:304
#1  0xc01504c0 in poweroff_wait (junk=0xc023a7a2, howto=-756391072)
    at ../../kern/kern_shutdown.c:554
#2  0xc0179966 in vrele (vp=0xd2d46b60) at ../../kern/vfs_subr.c:1445
#3  0xc01f47bc in vm_object_vndeallocate (object=0xd2ea6360)
    at ../../vm/vm_object.c:278
#4  0xc01f47e0 in vm_object_deallocate (object=0xd2ea6360)
    at ../../vm/vm_object.c:301
#5  0xc01f2003 in vm_map_entry_delete (map=0xd3b6f700, entry=0xd3bc1ba0)
    at ../../vm/vm_map.c:1727
#6  0xc01f2185 in vm_map_delete (map=0xd3b6f700, start=672231424,
    end=672317440) at ../../vm/vm_map.c:1830
#7  0xc01f2212 in vm_map_remove (map=0xd3b6f700, start=672231424,
    end=672317440) at ../../vm/vm_map.c:1855
#8  0xc01f3d44 in munmap (p=0xd32d5f20, uap=0xd3918f80)
    at ../../vm/vm_mmap.c:555
#9  0xc021f11a in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 136314927,
      tf_edi = 136367164, tf_esi = 136366632, tf_ebp = 136366596,
      tf_isp = -745435180, tf_ebx = 134740992, tf_edx = 672231424,
      tf_ecx = 135438220, tf_eax = 73, tf_trapno = 22, tf_err = 2,
      tf_eip = 135194692, tf_cs = 31, tf_eflags = 518, tf_esp = 136366576,
      tf_ss = 47}) at ../../i386/i386/trap.c:1073
#10 0xc0214006 in Xint0x80_syscall ()
#11 0x8093979 in ?? ()
#12 0x80a5598 in ?? ()
#13 0x805abfe in ?? ()
#14 0x80529ab in ?? ()
#15 0x8050516 in ?? ()
#16 0x804fc85 in ?? ()
#17 0x80d8398 in ?? ()
#18 0x80d81aa in ?? ()
#19 0xbfbff968 in ?? ()
Cannot access memory at address 0x13150274.
(kgdb) quit

Fix: 

No idea.
How-To-Repeat: 
	Keep the machine up for days....and wait.  :)
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 2000-04-11 14:36:57 UTC
Responsible Changed
From-To: freebsd-bugs->dillon

Matt, could you put your Mr. VM hat on and take a look? 
Comment 2 iedowse freebsd_committer freebsd_triage 2001-08-12 18:13:38 UTC
State Changed
From-To: open->feedback


I presume that whatever caused this has been fixed long ago?
Comment 3 Giorgos Keramidas freebsd_committer freebsd_triage 2003-02-23 02:14:37 UTC
Responsible Changed
From-To: dillon->freebsd-bugs

Back to the free pool.
Comment 4 Kris Kennaway freebsd_committer freebsd_triage 2003-07-12 14:03:01 UTC
State Changed
From-To: feedback->closed

Feedback timeout