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