Re: Panic _at_r207433: "System call fork returning with the following locks held"

Hi Andrew,

Does FBSDID get expanded when checking out with csup?

You should see:
__FBSDID("$FreeBSD: head/sys/vm/vm_pageout.c 207452 2010-04-30
22:31:37Z kmacy $");

line 451 is part of a KASSERT on this version.

Cheers,
Kip


On Fri, Apr 30, 2010 at 4:12 PM, Andrew Reilly <areilly_at_bigpond.net.au> wrote:
> Hi all,
>
> I'm not sure if it's related (I get my src via csup, so I don't
> have svn reveision numbers), but I upgraded about 16 hours ago
> again a few hours after that, and my two-core AMD64 system has
> been (seemingly) quite unstable.  I've had a few boot cycles
> that have failed and dumped me out into kdb, rebooting through
> single-user (to check file systems) seems to get me "up", but my
> logs are completely full of:
>
> Calling uiomove() with the following non-sleepable locks held:
> exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 0 (0xffffffff80e60a00) locked _at_ /nb/src/sys/vm/vm_pageout.c:452
> exclusive sleep mutex page lock (page lock) r = 0 (0xffffffff80e59e00) locked _at_ /nb/src/sys/vm/vm_pageout.c:451
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x2e
> witness_warn() at witness_warn+0x2c2
> uiomove() at uiomove+0x52
> ffs_write() at ffs_write+0x32d
> VOP_WRITE_APV() at VOP_WRITE_APV+0x103
> vnode_pager_generic_putpages() at vnode_pager_generic_putpages+0x1c5
> vnode_pager_putpages() at vnode_pager_putpages+0x97
> vm_pageout_flush() at vm_pageout_flush+0x1ad
> vm_object_page_collect_flush() at vm_object_page_collect_flush+0x470
> vm_object_page_clean() at vm_object_page_clean+0x408
> vfs_msync() at vfs_msync+0xef
> sync_fsync() at sync_fsync+0x12a
> sync_vnode() at sync_vnode+0x157
> sched_sync() at sched_sync+0x1d1
> fork_exit() at fork_exit+0x12a
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffff803ebbad30, rbp = 0 ---
>
> or this slightly different version:
>
> uma_zalloc_arg: zone "g_bio" with the following non-sleepable locks held:
> exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 0 (0xffffffff80e60a00) locked _at_ /nb/src/sys/kern/vfs_bio.c:3571
> exclusive sleep mutex page lock (page lock) r = 0 (0xffffffff80e5fb80) locked _at_ /nb/src/sys/vm/vm_pageout.c:451
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x2e
> witness_warn() at witness_warn+0x2c2
> uma_zalloc_arg() at uma_zalloc_arg+0x335
> g_vfs_strategy() at g_vfs_strategy+0x28
> ufs_strategy() at ufs_strategy+0x45
> bufstrategy() at bufstrategy+0x43
> bufwrite() at bufwrite+0x108
> cluster_wbuild() at cluster_wbuild+0x1cd
> cluster_write() at cluster_write+0x2f5
> ffs_write() at ffs_write+0x66b
> VOP_WRITE_APV() at VOP_WRITE_APV+0x103
> vnode_pager_generic_putpages() at vnode_pager_generic_putpages+0x1c5
> vnode_pager_putpages() at vnode_pager_putpages+0x97
> vm_pageout_flush() at vm_pageout_flush+0x1ad
> vm_object_page_collect_flush() at vm_object_page_collect_flush+0x470
> vm_object_page_clean() at vm_object_page_clean+0x19d
> vfs_msync() at vfs_msync+0xef
> sync_fsync() at sync_fsync+0x12a
> sync_vnode() at sync_vnode+0x157
> sched_sync() at sched_sync+0x1d1
> fork_exit() at fork_exit+0x12a
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffff803ebbad30, rbp = 0 ---
>
> I'll be doing another csup/rebuild ASAP, in the hope of picking
> up the fixes mentioned here.  Just thought I'd add another "me
> too" and a bit of data.
>
> Cheers,
>
> --
> Andrew
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>