panic, seems related to r234386

[Doug Barton]

On 05/06/2012 15:19, Sergey Kandaurov wrote:
> On 7 May 2012 01:54, Doug Barton <dougb at freebsd.org> wrote:
>> I got this with today's current, previous (working) kernel is r232719.
>>
>> panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx
>> @ /frontier/svn/head/sys/kern/vfs_subr.c:4595

...

> Please try this patch.
> 
> Index: fs/ext2fs/ext2_vfsops.c
> ===================================================================
> --- fs/ext2fs/ext2_vfsops.c     (revision 235108)
> +++ fs/ext2fs/ext2_vfsops.c     (working copy)
> @@ -830,7 +830,6 @@
>         /*
>          * Write back each (modified) inode.
>          */
> -       MNT_ILOCK(mp);
>  loop:
>         MNT_VNODE_FOREACH_ALL(vp, mp, mvp) {
>                 if (vp->v_type == VNON) {
> 

Didn't help, sorry. I put 234385 through some pretty heavy load
yesterday, and everything was fine. As soon as I move up to 234386, the
panic triggered again. So I cleaned everything up, applied your patch,
built a kernel from scratch, and rebooted. It was Ok for a few seconds
after boot, then panic'ed again, I think in a different place, but I'm
not sure because subsequent attempts to fsck the file systems caused new
panics which overwrote the old ones before they could be saved.

I'd like to see this changed backed out until the proponents can
thoroughly regression test all of the file systems that it affects.

FWIW, the thing that seems to be triggering the panic is that I have the
following setup:

/dev/ad0s2a on / (ufs, local)
/dev/ad3s2 on /home (ext2fs, local)

/etc/namedb is a symlink to /home/named/etc/namedb. When I booted 234386
named failed to start because the symlink was corrupted. When I
recreated the symlink and then started named, it panic'ed.

hth,

Doug

-- 

    This .signature sanitized for your protection