:...
:> I'm pretty sure that the box was getiting receive interrupts because
:> every time I sent a packet to it from the outside systat -vm showed
:> a PCI interrupt for the network device. However 'netstat -in 1' did
:> not show the statistics for the received packets until 64 had
:> accumulated. It could be that the statistics are not being accumulated
:> on a per-reception basis and that the receive packets are actually
:> getting through, and that its the transmit side which is broken. I don't
:> know the code well enough yet to make the determination.
:
:If things are done in these drives as they are in the if_de driver then
:what you are seeing is the fact that if_opackets and are only
:updated when the tx ring is reclaimed by an interrupt, not
Next time this bug rears its ugly head I'll get a tcpdump going to try
to figure out what is actually going on. Ooh, and I just had a
thought -- a profiled kernel might help track down the problem as well
by enabling it to see which routines get hit (and which don't).
I don't see anything specific in the code so far, other then there being
a lot of memory mapped (apparently shared with the device) objects that
haven't been volatilized. So far I can't tie that into anything though.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
