panic: kassert("(code != TRAP_CHLD) || (entity > 1)"

[Robert Elz <kre%munnari.OZ.AU@localhost>]

This panic has been plauging the b5 ATF tests for a while now, it
is from the "tracer_sysctl_lookup_without_duplicates" ATF test.

The backtrace isn't all that helpful, child_return() calls eventswitch()
calls KASSERT() - boom.

(After that there's typically more problems from the core dump attempt).

I have a system (real hardware - well, an amd64 DomU) running a kernel
from about a day (or a bit less) ago currently in ddb after such a
panic.   If anyone wants to give me instructions on what to do, what to
look at (and how to do that) I'm happy to heave that system in its
current state for a day or so.

Bear in mind that I know nothing about the x86 architecture, nor ddb
(I generally compile it out of kernels, or turn it off if no compiled out).
But this time, not.   It isn't a generic kernel, it is one tailored to
my normal DomU needs.   There's 0 chance of a crash dump being saved if
I let it continue.

kre