Bug 20234

Summary: panic(): lockmgr: pid 259, not exclusive lock holder 0 unlocking
Product: Base System Reporter: geniusj <geniusj>
Component: kernAssignee: Andre Oppermann <andre>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 5.0-CURRENT   
Hardware: Any   
OS: Any   

Description geniusj 2000-07-28 06:40:01 UTC
when rebooting the system, machine panics with the following message:
lockmgr: pid 259, not exclusive lock holder 0 unlocking

here is my kernel config file (if you need hints file, lemme know):

machine		i386
cpu		I686_CPU
ident		FREEBSD
maxusers	32

hints		"FREEBSD.hints"		#Default places to look for devices.

makeoptions	DEBUG=-g		#Build kernel with gdb(1) debug symbols

options 	INET			#InterNETworking
options 	INET6			#IPv6 communications protocols
options 	FFS			#Berkeley Fast Filesystem
options 	FFS_ROOT		#FFS usable as root device [keep this!]
options 	SOFTUPDATES		#Enable FFS soft updates support
options 	MFS			#Memory Filesystem
options 	NFS			#Network Filesystem
options 	MSDOSFS			#MSDOS Filesystem
options 	CD9660			#ISO 9660 Filesystem
options 	PROCFS			#Process filesystem
options 	COMPAT_43		#Compatible with BSD 4.3 [KEEP THIS!]
options 	UCONSOLE		#Allow users to grab the console
options 	USERCONFIG		#boot -c editor
options 	VISUAL_USERCONFIG	#visual boot -c editor
options 	KTRACE			#ktrace(1) support
options 	SYSVSHM			#SYSV-style shared memory
options 	SYSVMSG			#SYSV-style message queues
options 	SYSVSEM			#SYSV-style semaphores
options 	P1003_1B		#Posix P1003_1B real-time extensions
options 	_KPOSIX_PRIORITY_SCHEDULING
options 	KBD_INSTALL_CDEV	# install a CDEV entry in /dev
options 	RANDOMDEV		#entropy device
options         IPFIREWALL              #firewall
options		IPFIREWALL_VERBOSE	#print information about
					# dropped packets
options		IPFIREWALL_FORWARD	#enable transparent proxy support
options		IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity
options		IPDIVERT		#divert sockets
options		IPFILTER		#kernel ipfilter support
options		IPFILTER_LOG		#ipfilter logging

device		isa
device		eisa
device		pci
device		pcm

# Floppy drives
device		fdc

# ATA and ATAPI devices
device		ata
device		atadisk			# ATA disk drives
device		atapicd			# ATAPI CDROM drives
device		atapifd			# ATAPI floppy drives
options 	ATA_STATIC_ID		#Static device numbering
options 	ATA_ENABLE_ATAPI_DMA	#Enable DMA on ATAPI devices

# atkbdc0 controls both the keyboard and the PS/2 mouse
device		atkbdc	1
device		atkbd
device		psm

device		vga

# splash screen/screen saver
device		splash

# syscons is the default console driver, resembling an SCO console
device		sc	1

# Floating point support - do not disable.
device		npx

# Serial (COM) ports
device		sio

# ISA Ethernet NICs.
device		ed

# Pseudo devices - the number indicates how many units to allocated.
device		loop		# Network loopback
device		ether		# Ethernet support
device		pty		# Pseudo-ttys (telnet etc)
device		vn		# VNode
device		snp	3	# Snoop

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
device		bpf		# Berkeley packet filter

-- Here is gdb -k output from vmcore.0 on kernel.debug:
#0  boot (howto=256) at ../../kern/kern_shutdown.c:303
#1  0xc014be14 in poweroff_wait (junk=0xc026ffc0, howto=259)
    at ../../kern/kern_shutdown.c:553
#2  0xc0146bdc in lockmgr (lkp=0xc0bc3800, flags=6, interlkp=0xc89feaac,
    p=0xc8012d40) at ../../kern/kern_lock.c:382
#3  0xc0179dc7 in vop_stdunlock (ap=0xc8a42e48) at ../../kern/vfs_default.c:255
#4  0xc0220371 in ufs_vnoperate (ap=0xc8a42e48)
    at ../../ufs/ufs/ufs_vnops.c:2291
#5  0xc021b2d3 in ufs_inactive (ap=0xc8a42e78) at vnode_if.h:865
#6  0xc0220371 in ufs_vnoperate (ap=0xc8a42e78)
    at ../../ufs/ufs/ufs_vnops.c:2291
#7  0xc017cb42 in vput (vp=0xc89fea40) at vnode_if.h:794
#8  0xc0217c5b in ffs_sync (mp=0xc0add200, waitfor=2, cred=0xc0721080,
    p=0xc02f9200) at ../../ufs/ffs/ffs_vfsops.c:955
#9  0xc017ea21 in sync (p=0xc02f9200, uap=0x0) at ../../kern/vfs_syscalls.c:551
#10 0xc014b863 in boot (howto=0) at ../../kern/kern_shutdown.c:225
#11 0xc014b664 in reboot (p=0xc8012d40, uap=0xc8a42f80)
    at ../../kern/kern_shutdown.c:146
#12 0xc025a14d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
      tf_edi = 0, tf_esi = 0, tf_ebp = -1077937628, tf_isp = -928763948,
      tf_ebx = 2, tf_edx = -1, tf_ecx = 3, tf_eax = 55, tf_trapno = 7,
      tf_err = 2, tf_eip = 134515340, tf_cs = 31, tf_eflags = 663,
      tf_esp = -1077937672, tf_ss = 47}) at ../../i386/i386/trap.c:1128
#13 0xc024f875 in Xint0x80_syscall ()
---Type <return> to continue, or q <return> to quit---Jul 27 23:28:03 phreebsd s
avecore: reboot after panic: lockmgr: pid 259, not exclusive lock holder 0 unloc
king
#14 0x8048139 in ?? ()

Fix: 

Wish I knew.. that should be enough information though.. Thanks!
How-To-Repeat: 
do a shutdown -r now on 5.0-CURRENT build on July 27th
Comment 1 Chris D.Faulhaber freebsd_committer freebsd_triage 2000-07-29 17:58:33 UTC
Responsible Changed
From-To: gnats-admin->freebsd-bugs

Misfiled PR
Comment 2 Sheldon Hearn freebsd_committer freebsd_triage 2000-07-31 09:48:16 UTC
Responsible Changed
From-To: freebsd-bugs->green

Brian's investigating this one.
Comment 3 Andre Oppermann freebsd_committer freebsd_triage 2003-12-27 15:01:00 UTC
State Changed
From-To: open->closed

Close this PR.  It has been idle for far too long and the 
ffs/ufs implementation has changed in significant ways (UFS2, 
softupdates, locking).  Also there have been fixes for 
shutdown race conditions some time ago.  I don't thing it 
makes sense to try to reproduce this kind of transitory 
problem conditions which emerge during the pre-beta phase 
of a new code branch (this is before 5.0R after all). 


Comment 4 Andre Oppermann freebsd_committer freebsd_triage 2003-12-27 15:01:00 UTC
Responsible Changed
From-To: green->andre

Close this PR.  It has been idle for far too long and the 
ffs/ufs implementation has changed in significant ways (UFS2, 
softupdates, locking).  Also there have been fixes for 
shutdown race conditions some time ago.  I don't thing it 
makes sense to try to reproduce this kind of transitory 
problem conditions which emerge during the pre-beta phase 
of a new code branch (this is before 5.0R after all).