> I think a very effective tool would actually be a kernel profiler that
> ran at a hardware priority above even splclock() and splmalloc() (aka
> splimp()), instead of at or below splclock(), as spl(9) suggests.
> 
> But you would at least see where the time is going -- except for code
> at splhigh().  In fact, it looks like you'd get exactly this on a
> sparc already, if statclock() really runs at intrlevel 14.

If you could add code in various places of the interrupt routines to
write numbers to the parallel port (for example, on architectures
that have one) and then monitor the port using external hardware, you
could see just about anything you wanted.  I measure execution times
of interrupt routines using a multimeter or oscilloscope this way. ;)

It's strange that a pentium class machine loses data on serial ports.
Even without a FIFO, at 115200 bps the CPU has almost 87 us to handle
each byte - I guess a pentium chip can run 5000-10000+ instructions in
that time.  What in the world is the kernel doing for such a long period
of time, running with interrupts disabled?  With an 8-byte effective
FIFO, there is time enough for a good nap (694 us) to handle one
interrupt and the 8-16 invoming bytes.  That must be some 30000-70000+
instructions on a pentium system.. and _still_ data is lost every now
and then (under NetBSD 1.2 - no experience of the improved com driver
of -current).

I don't think it's just a few lines of code causing this.. unless it's
a while(1) loop :-}

  -jm


-- 

                       1503 kHz @ 22:30 EET DST Mon-Fri

                     ---> http://www.jmp.fi/~jmarin/ <---