Re: panic on shutdown anyone (insmntque())?

On Sat, Sep 06, 2008 at 12:35:45PM +0930, Kris Kennaway wrote:
> Richard Todd wrote:
> >Guy Brand <gb_at_isis.u-strasbg.fr> writes:
> >
> >>Kris Kennaway (kris_at_freebsd.org) on 05/09/2008 at 18:21 wrote:
> >>
> >>>>>pjd has a fix in his p4 branch.
> >>>>Same problem here with ZFS on root.  Where can I find this patch?
> >>>>	Would be happy to test it.
> >>>It was committed earlier today.
> >>It fixed my shutdown panic. Thanks pjd
> >
> >But appears not to fix the panic I've seen trying to boot any kernel since
> >the insmntque patches went in, just at the point where it tries to mount
> >the root FS:
> >
> >Trying to mount root from zfs:rootpool/tolot-root
> >KDB: stack backtrace:
> >db_trace_self_wrapper(80bbd824,86ce5784,8086a0c3,874b4dc8,86ce5784,...) at 
> >db_trace_self_wrapper+0x26
> >kdb_backtrace(874b4dc8,86ce5784,80b1a6b5,86ce5794,874b4d70,...) at 
> >kdb_backtrace+0x29
> >vfs_badlock(8107eda0,86ce5794,80cd8c20,874b4d70) at vfs_badlock+0x23
> >assert_vop_elocked(874b4d70,80bc7ddf,87ae406c,87ae406c,157,...) at 
> >assert_vop_elocked+0x55
> >insmntque1(874b4d70,87b06670,80871200,0,86ce5808,...) at insmntque1+0x1c7
> >insmntque(874b4d70,87b06670,157,155,3,...) at insmntque+0x28
> >zfs_znode_alloc(3,0,e00,0,86ce585c,...) at zfs_znode_alloc+0x10d
> >zfs_zget(87ae4000,3,0,86ce5950,8,...) at zfs_zget+0x1ce
> >zfs_init_fs(87ae4000,86ce5950,8708fd00,87ae4008,2,...) at zfs_init_fs+0x2a0
> >zfs_mount(87b06670,870c4d20,80bc68f2,3f4,0,...) at zfs_mount+0x35a
> >vfs_donmount(20,87af34e0,87af44c0,6,86ce5b78,...) at vfs_donmount+0x13ca
> >kernel_mount(87af34e0,4001,87b03b80,ffffffff,86ce5bc0) at kernel_mount+0x78
> >kernel_vmount(4001,80bc6bdf,87af34c0,80bc6bee,80bb3d40,...) at 
> >kernel_vmount+0x63
> >vfs_mountroot_try(80bc6ef1,80bb3d40,80bab4a8,1,80864c00,...) at 
> >vfs_mountroot_try+0x132
> >vfs_mountroot(80d0ceb0,4,80bb5090,264,870c2d94,...) at vfs_mountroot+0x423
> >start_init(0,86ce5d38,80bb6ae4,322,870c2d0c,...) at start_init+0x65
> >fork_exit(807aca80,0,86ce5d38) at fork_exit+0xb8
> >fork_trampoline() at fork_trampoline+0x8
> >--- trap 0, eip = 0, esp = 0x86ce5d70, ebp = 0 ---
> >insmntque: mp-safe fs and non-locked vp: 0x874b4d70 is not exclusive 
> >locked but should be
> >KDB: enter: lock violation
> >[thread pid 1 tid 100002 ]
> >Stopped at      kdb_enter+0x3a: movl    $0,kdb_why
> >db> 
> 
> Yep, looks different.

Yes, but I had an impression that pjd_at_ patch taken care of the issue too.
The assert was added to the insmntque() function, verifying that
filesystem marked mpsafe insterts exclusively locked vnode.