Re: Panic on todays current (panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/vfs_mount.c:1046)

On Mon, Aug 20, 2007 at 06:48:17PM +0300, Nikolay Pavlov wrote:
> Hello. I've got this while booting:
> 
> Starting file system checks:
> /dev/ad0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/ad0s4a: clean, 6113 free (241 frags, 734 blocks, 0.2% fragmentation)
> /dev/ad0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/ad0s4f: clean, 67511 free (2623 frags, 8111 blocks, 0.4% 
> fragmentation)
> /dev/ad0s4e.journal: FILE SYSTEM CLEAN; SKIPPING CHECKS
> Setting hostuuid: 44454C4C-4400-1039-8030-B6C04F4A324A.
> Setting hostid: 0x7817d87e.
> Mounting local file systems:
> panic: mtx_lock() of spin mutex (null) _at_ /usr/src/sys/kern/vfs_mount.c:1046
> cpuid = 0
> KDB: enter: panic
> exclusive sleep mutex Giant r = 0 (0xc0ba7350) locked 
> _at_ /usr/src/sys/kern/kern_module.c:117
> panic: from debugger
> cpuid = 0
> Uptime: 6s
> Physical memory: 1003 MB
> Dumping 47 MB: 32 16
> 
> #0  doadump () at pcpu.h:195
> 195             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) bt
> #0  doadump () at pcpu.h:195
> #1  0xc074c19e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
> #2  0xc074c45b in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:563
> #3  0xc048c6d7 in db_panic (addr=Could not find the frame base 
> for "db_panic".
> ) at /usr/src/sys/ddb/db_command.c:433
> #4  0xc048d0c5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401
> #5  0xc048e835 in db_trap (type=3, code=0) 
> at /usr/src/sys/ddb/db_main.c:222
> #6  0xc07730c6 in kdb_trap (type=3, code=0, tf=0xe46959f0) 
> at /usr/src/sys/kern/subr_kdb.c:502
> #7  0xc09fd25b in trap (frame=0xe46959f0) 
> at /usr/src/sys/i386/i386/trap.c:621
> #8  0xc09e2c8b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> #9  0xc0773242 in kdb_enter (msg=0xc0a93513 "panic") at cpufunc.h:60
> #10 0xc074c444 in panic (fmt=0xc0a92475 "mtx_lock() of spin mutex %s _at_ %s:
> %d") at /usr/src/sys/kern/kern_shutdown.c:547
> #11 0xc0740d3a in _mtx_lock_flags (m=0xc42b0000, opts=0, 
> file=0xc0a9e111 "/usr/src/sys/kern/vfs_mount.c", line=1046) 
> at /usr/src/sys/kern/kern_mutex.c:180
> #12 0xc07c154b in vfs_donmount (td=0xc429f800, fsflags=0, 
> fsoptions=0xc431ce00) at /usr/src/sys/kern/vfs_mount.c:1046
> #13 0xc07c25e3 in nmount (td=0xc429f800, uap=0xe4695cfc) 
> at /usr/src/sys/kern/vfs_mount.c:413
> #14 0xc09fca13 in syscall (frame=0xe4695d38) 
> at /usr/src/sys/i386/i386/trap.c:1008
> #15 0xc09e2cf0 in Xint0x80_syscall () 
> at /usr/src/sys/i386/i386/exception.s:196
> #16 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
The line where the reported panic happens is located at the point where
several successfull locks of the mount structure interlock alread happen
(see, for instance, line 983). In between, there is a call to VFS_MOUNT()
method of the fs.

It would be interesting to look at the type of the filesystem being mounted.

Just a guess:
Could it be that mounted filesystem comes from module, that uses incompatible
binary interface (for instance, built with different kernel options or for
different kernel version) ?