Panic @r207433: "System call fork returning with the following
locks held"
Andrew Reilly
areilly at bigpond.net.au
Sat May 1 12:49:39 UTC 2010
Hi Kip,
Sorry for the delay: it's been a tussle...
On Fri, Apr 30, 2010 at 04:42:12PM -0700, K. Macy wrote:
> Does FBSDID get expanded when checking out with csup?
Looks like it:
> __FBSDID("$FreeBSD: head/sys/vm/vm_pageout.c 207452 2010-04-30
> 22:31:37Z kmacy $");
My version says:
__FBSDID("$FreeBSD: src/sys/vm/vm_pageout.c,v 1.316 2010/04/30
22:31:37 kmacy Exp $");
> line 451 is part of a KASSERT on this version.
Yep.
About half an hour after sending the previous message my system
siezed up again, and I've been coaxing it back to health since.
Must make a note to myself to be more careful... I managed
to find a boot configuration that was stable enough to grab
the latest updates off the local cvs server. Then back to
single-user mode to build the kernel, and all was sweetness and
puppies after that. Thanks for the fixes!
All? Not quite: about simultaneous with the vm_pageout
weirdness (which means something (else?) committed in the last
week), my courier-authdaemond has been dying on startup thusly:
May 1 22:29:06 duncan authdaemond: /var/run/authdaemond/socket:
Cross-device link
It never used to die like that before, and I haven't changed
anything in its configuration. The socket in question is
presumably the one listed: instead there's a socket in that
directory called socket.tmp, but the process itself is long
gone.
I don't suppose that that rings a bell? Anything change with
respect to unix-domain sockets or in the last week?
Cheers,
--
Andrew
More information about the freebsd-current
mailing list