Paul Kranenberg recently found and fixed a bug in the sparc port:
kernel thread main functions were invoked running at
splhigh()/splclock() because cpu_fork() did not (re)set the saved IPL
of the newly created process.

This appears to cause sporadic high interrupt latency since interrupts
are masked while a kernel process is running, leading to (among other
things) poor clock stability as measured by NTP.

It appears that several other ports have this same bug.  (I'm testing
a fix for the alpha at the moment). i386 appears to not have the
problem.

Portmasters should investigate and verify that newly-forked kernel
threads run with low IPL.

As a reminder, cpu_fork() looks like this:

void
cpu_fork(p1, p2, stack, stacksize, func, arg)
	struct proc *p1, *p2;
	void *stack;
	size_t stacksize;
	void (*func) __P((void *));
	void *arg;
{}

    do machine-dependant work necessary to fork `p2' from `p1', with a
    kernel stack of `stacksize' bytes starting at `stack'; on first
    context switch to p2, invoke `func(arg)', and when it returns, go to
    userspace.

When func() is called, IPL must be reduced to the equivalent of
IPL_NONE/spl0()/.  The lowering of spl can either be imposed on the
new process by cpu_fork(), or can be done in the trampoline code
entered by the newly-spawned thread.

					- Bill