If there is a microsecond-resolution clock available on the x86, you can
use the trick I used for interrupt latency calculations:  modify the spl
routines to figure out when and from where they were called, and keep track
of who holds the interrupt mask.  (This is going to be much trickier on the
386 than on the machine where I did this last, which had only one interrupt
level.)  If you have time, you can put macro wrappers around the spl routines
to pass in identification strings (like __FILE__ and __LINE__, or even custom
strings if you have lots of time), but it shouldn't be a trememdous amount of
work (I hope) to have splxxx grovel up the stack to find a likely candidate
for blame.

This would give a very complete picture of the interrupt situation, though
it might involve more time than you're able to put into it.  (I might even
try tackling this myself sometime, since it's a favorite hobby-horse of
mine, but I'm not sure I have enough interesting hardware to really find
unusual cases.  I suppose that once I get it working, others could take
the same code and run it on different hardware.)

> Chris, I'm not actually too worried about _throughput_ as long as the
> interrupt gets serviced in time.  I can fix that problem by using a P90
> instead of a 486. What I can't tolerate is a missed interrupt causing a
>transmitter underrun and a frame abort throwing away the last segment of
>a 1500 byte frame too often.

Actually, a P90 ought to at least partially solve the latency issue, unless
there's an uninterruptable spinwait somewhere that's at fault.