> I hacked up the interrupt level usage stuff to not use level 14
> for the statclock (doubling up on level 10 instead), and changed
> a number of splhigh()s to splstatclock() in various places
> (6 in kern_synch.c and 2 in sys_generic.c) and the problem went away.
> pk didn't like my fix tho, and I upgraded to an IPX and didn't
> see the problem with an unpatched kernel anymore, so I let it drop.

1. Since the splhigh()s in kern_synch.c protect the sleep queues, you
   cannot change those unless all ports agree on a level beyond which
   no interrupt handler is allowed to call wakeup() et.al.

2. Not using the level 14 clock would be a lose. You're giving up
   independent profiling ticks and collection of process statistics
   and scheduling.

   We could consider turning it off optionally on machines where it
   interferes intolarably with the serial ports. However, I would
   like to make sure that it is indeed `statclock()' that is holding
   things up.  tsleep() cannot be in code path taken by the level 14
   interrupt handler, yet your data indicates tht fifo overflows
   mostly happen when someone is about to return from tsleep().


-pk