Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Mar 2004 10:39:53 GMT
From:      Nik Clayton <nik@crf-consulting.co.uk>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:    kern/64206: panic: lockmgr: locking against myself (kern_lock.c:370)
Message-ID:  <200403131039.i2DAdrOE093079@clan.nothing-going-on.org>
Resent-Message-ID: <200403131040.i2DAeBMk084607@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         64206
>Category:       kern
>Synopsis:       panic: lockmgr: locking against myself (kern_lock.c:370)
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 13 02:40:11 PST 2004
>Closed-Date:
>Last-Modified:
>Originator:     Nik Clayton
>Release:        FreeBSD 5.2-CURRENT i386
>Organization:
>Environment:

System: FreeBSD clan.nothing-going-on.org 5.2-CURRENT FreeBSD 5.2-CURRENT #8: Thu Mar 11 23:26:36 GMT 2004 nik@clan.nothing-going-on.org:/local/1/usr/src/sys/i386/compile/CLAN i386

-current built from a source tree pulled down on 2004-03-09

>Description:

After a clean boot, with background_fsck="NO" in /etc/rc.conf (so the disks 
had been fsck'd at startup), on a filesystem with softupdates enabled, I 
could reliably reproduce a panic by doing something disk intensive, like

    cd /usr/ports/multimedia/kdemultimedia3
    make clean extract

The panic would happen within a few seconds of the extraction starting.

This was completely reproducible:

    reboot
    disks get fscked
    login
    'make clean extract'
    panic

and I did so several times for testing.

A Google groups search for "kern_lock.c panic 370" shows numerous reports
of this over the past year or so.  Most of them have linked this to 
background fsck.

Since I had had background fsck enabled previously, I'll theorise wildly,
and suggest that the problem is an interaction between the softupdates code
and snapshot code (since the previous, incomplete, background fscks will
have left snapshots behind when the system panic'd before they completed).

>How-To-Repeat:

As above.

>Fix:

For the time being, I've turned off softupdates.  Obviously, that's not a 
realistic long term fix.

I have crash dumps, and the kernel.debug that was running when the panics
happened.  Contact me for copies.

Here's a typescript of the backtrace from one of the panics.

Script started on Thu Mar 11 09:32:26 2004
clan# gdb -k kernel.debug /var/crash/vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: lockmgr: locking against myself
panic messages:
---
panic: lockmgr: locking against myself
at line 370 in file ../../../kern/kern_lock.c
cpuid = 0; 
Debugger("panic")
panic: from debugger
at line 453 in file ../../../ddb/db_command.ccpuid = 0; 
boot() called on cpu#0
Uptime: 16h22m45s
Dumping 511 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496
---
Reading symbols from /boot/kernel/snd_mss.ko...done.
Loaded symbols for /boot/kernel/snd_mss.ko
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /local/1/usr/src/sys/i386/compile/CLAN/modules/local/1/usr/src/sys/modules/acpi/acpi.ko...done.
Loaded symbols for /local/1/usr/src/sys/i386/compile/CLAN/modules/local/1/usr/src/sys/modules/acpi/acpi.ko
Reading symbols from /local/1/usr/src/sys/i386/compile/CLAN/modules/local/1/usr/src/sys/modules/nfsserver/nfsserver.ko.debug...done.
Loaded symbols for /local/1/usr/src/sys/i386/compile/CLAN/modules/local/1/usr/src/sys/modules/nfsserver/nfsserver.ko.debug
Reading symbols from /local/1/usr/src/sys/i386/compile/CLAN/modules/local/1/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for /local/1/usr/src/sys/i386/compile/CLAN/modules/local/1/usr/src/sys/modules/linux/linux.ko.debug
#0  doadump () at ../../../kern/kern_shutdown.c:240
240		dumping++;
(kgdb) backtrace
#0  doadump () at ../../../kern/kern_shutdown.c:240
#1  0xc051ab0f in boot (howto=260) at ../../../kern/kern_shutdown.c:374
#2  0xc051af7b in __panic () at ../../../kern/kern_shutdown.c:552
#3  0xc0445b42 in db_panic () at ../../../ddb/db_command.c:453
#4  0xc0445a92 in db_command (last_cmdp=0xc06f96e0, cmd_table=0x0, 
    aux_cmd_tablep=0xc06c6cc4, aux_cmd_tablep_end=0xc06c6cc8)
    at ../../../ddb/db_command.c:348
#5  0xc0445be5 in db_command_loop () at ../../../ddb/db_command.c:475
#6  0xc0448da5 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:73
#7  0xc06582ec in kdb_trap (type=3, code=0, regs=0xdda752d0)
    at ../../../i386/i386/db_interface.c:171
#8  0xc066db5c in trap (frame=
      {tf_fs = 24, tf_es = -1047003120, tf_ds = 16, tf_edi = -1066738309, tf_esi = 1, tf_ebp = -576236772, tf_isp = -576236804, tf_ebx = 0, tf_edx = 0, tf_ecx = -1056882688, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067088379, tf_cs = 8, tf_eflags = 658, tf_esp = -1066666039, tf_ss = -1066733316})
    at ../../../i386/i386/trap.c:579
#9  0xc0658605 in Debugger (msg=0x0) at machine/cpufunc.h:60
#10 0xc051aed2 in __panic (file=0xc06addd9 "../../../kern/kern_lock.c", 
    line=370, fmt=0xc06add7b "lockmgr: locking against myself")
    at ../../../kern/kern_shutdown.c:536
#11 0xc050cc95 in lockmgr (lkp=0xce8f1f14, flags=34144290, interlkp=0x2000020, 
    td=0xc4a13540) at ../../../kern/kern_lock.c:439
#12 0xc056d9d9 in getblk (vp=0xc467db2c, blkno=7150880, size=16384, slpflag=0, 
    slptimeo=0, flags=0) at machine/pcpu.h:156
#13 0xc0569102 in breadn (vp=0xc467db2c, blkno=0, size=0, rablkno=0x0, 
    rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at ../../../kern/vfs_bio.c:700
#14 0xc05690ac in bread (vp=0x0, blkno=0, size=0, cred=0x0, bpp=0x0)
    at ../../../kern/vfs_bio.c:682
#15 0xc05e99ff in ffs_alloccg (ip=0xc4699000, cg=19, bpref=1787680, size=16384)
    at ../../../ufs/ffs/ffs_alloc.c:1287
#16 0xc05e9447 in ffs_hashalloc (ip=0xc4699000, cg=19, pref=0, size=16384, 
    allocator=0xc05e9910 <ffs_alloccg>) at ../../../ufs/ffs/ffs_alloc.c:1155
#17 0xc05e72c2 in ffs_alloc (ip=0xc4699000, lbn=223468, bpref=1787680, 
    size=16384, cred=0xc1976200, bnp=0xdda75610)
    at ../../../ufs/ffs/ffs_alloc.c:157
#18 0xc05eeaf3 in ffs_balloc_ufs2 (vp=0xc4698b2c, startoffset=0, size=16384, 
    cred=0xc1976200, flags=0, bpp=0xdda75720)
    at ../../../ufs/ffs/ffs_balloc.c:774
#19 0xc05f7aa0 in ffs_copyonwrite (devvp=0xc467db2c, bp=0xce848618)
    at ../../../ufs/ffs/ffs_snapshot.c:2035
#20 0xc04deab2 in spec_xstrategy (vp=0xc467db2c, bp=0xce848618)
    at ../../../fs/specfs/spec_vnops.c:493
#21 0xc04debab in spec_specstrategy (ap=0x0)
    at ../../../fs/specfs/spec_vnops.c:553
#22 0xc04ddc18 in spec_vnoperate (ap=0x0)
    at ../../../fs/specfs/spec_vnops.c:122
#23 0xc0569934 in bwrite (bp=0xce848618) at vnode_if.h:1141
#24 0xc056a42c in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1150
#25 0xc05ea8fa in ffs_nodealloccg (ip=0xc5aadc94, cg=19, ipref=65, mode=33188)
    at ../../../ufs/ffs/ffs_alloc.c:1637
#26 0xc05e9447 in ffs_hashalloc (ip=0xc5aadc94, cg=19, pref=0, size=33188, 
    allocator=0xc05ea380 <ffs_nodealloccg>)
    at ../../../ufs/ffs/ffs_alloc.c:1155
#27 0xc05e8b69 in ffs_valloc (pvp=0xc66a0410, mode=33188, cred=0xc48d2600, 
    vpp=0xdda75908) at ../../../ufs/ffs/ffs_alloc.c:857
#28 0xc0613bbf in ufs_makeinode (mode=33188, dvp=0xc66a0410, vpp=0xdda75bf0, 
    cnp=0xdda75c04) at ../../../ufs/ufs/ufs_vnops.c:2386
#29 0xc0610639 in ufs_create (ap=0xdda75a70)
    at ../../../ufs/ufs/ufs_vnops.c:200
#30 0xc0614168 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2822
#31 0xc058b0ee in vn_open_cred (ndp=0xdda75bdc, flagp=0xdda75cdc, cmode=420, 
    cred=0xc48d2600, fdidx=0) at vnode_if.h:118
#32 0xc058af43 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0)
    at ../../../kern/vfs_vnops.c:93
#33 0xc0584098 in kern_open (td=0xc4a13540, path=0x0, pathseg=UIO_USERSPACE, 
    flags=2562, mode=420) at ../../../kern/vfs_syscalls.c:971
#34 0xc0583fc0 in open (td=0x0, uap=0x0) at ../../../kern/vfs_syscalls.c:941
#35 0xc066e600 in syscall (frame=
      {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134672579, tf_esi = 2561, tf_ebp = -1077942136, tf_isp = -576234124, tf_ebx = 420, tf_edx = -19, tf_ecx = 67, tf_eax = 5, tf_trapno = 0, tf_err = 2, tf_eip = 672040575, tf_cs = 31, tf_eflags = 514, tf_esp = -1077942628, tf_ss = 47}) at ../../../i386/i386/trap.c:1008
#36 0x280e867f in ?? ()
---Can't read userspace from dump, or kernel process---

(kgdb) q

Script done on Thu Mar 11 09:32:46 2004
>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403131039.i2DAdrOE093079>