interrupt routing problem?

[EM1897 at aol.com]

In a message dated 2/9/2005 4:39:39 PM Eastern Standard Time, Matthew Dillon 
<dillon at xxxxxxxxxxxxxxxxxxxx> writes:

>:>
>:>    We currently have some issues with gdb'ing kernel cores that may make
>:>    it more difficult to track the problem down.  Joerg has been working on
>:>    them.
>:>
>:
>:I can do that, but I'm not sure you understood properly. When I said "lock 
up"
>:I didnt mean that the system locked up, but just the controller. I can run
>:ifconfigs to revive the port, so I can add trace code or whatever is 
necessary
>:to look at things.
>:
>:Since my last post I fired up linux and linux runs fine with no problems. 
The
>:interrrupt that both ports on the PCI-X slot is using is 9.
>:
>:Also, why does dragonfly put stray interrupts into the vmstat output? Is 
>:that useful for something?
>
>    If you get a dump I can look at the EM driver's management structures
>    to try to figure out what state the EM driver is in.
>
>    keeping track of stray interrupts is a good debugging tool.

I may have spoken too soon. It appears that I may have been trashing my
(cheapo) switch, which caused an actual transmitter failure/device timeout. 
The machine with dfly ran while I was at lunch without failing. In FreeBSD 4.9
it locks up the transmitter in a minute or 2. I'm going to run it overnight. 

I do have a question about my top measurements. Running the same test on 
the same MB, In Dragonfly, I see about 8% system and 12% interrupt, but 
FreeBSD 4.11 only shows 12%-14% interrrupt and 0% for system. Is freeBSD 
not including cycles that Dfly is? Is this going to be like measuring a 
beachball
with a yardstick?