Date: Fri, 30 Apr 2010 16:42:12 -0700 From: "K. Macy" <kmacy@freebsd.org> To: Andrew Reilly <areilly@bigpond.net.au> Cc: current@freebsd.org Subject: Re: Panic @r207433: "System call fork returning with the following locks held" Message-ID: <g2m82c4140e1004301642z7cb880eeo8d2d24ade87d2f7a@mail.gmail.com> In-Reply-To: <20100430231240.GA28805@duncan.reilly.home> References: <20100430161953.GW96847@bunrab.catwhisker.org> <20100430231240.GA28805@duncan.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
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@bigpond.net.au> wro=
te:
> 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. =A0I'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 =3D 0 (=
0xffffffff80e60a00) locked @ /nb/src/sys/vm/vm_pageout.c:452
> exclusive sleep mutex page lock (page lock) r =3D 0 (0xffffffff80e59e00) =
locked @ /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 =3D 0, rsp =3D 0xffffff803ebbad30, rbp =3D 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 =3D 0 (=
0xffffffff80e60a00) locked @ /nb/src/sys/kern/vfs_bio.c:3571
> exclusive sleep mutex page lock (page lock) r =3D 0 (0xffffffff80e5fb80) =
locked @ /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 =3D 0, rsp =3D 0xffffff803ebbad30, rbp =3D 0 ---
>
> I'll be doing another csup/rebuild ASAP, in the hope of picking
> up the fixes mentioned here. =A0Just thought I'd add another "me
> too" and a bit of data.
>
> Cheers,
>
> --
> Andrew
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org=
"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?g2m82c4140e1004301642z7cb880eeo8d2d24ade87d2f7a>