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