> 4) The de driver reports stuff like this before calming down:

   > de0: abnormal interrupt: transmit underflow (raising TX threshold to 128|512)
   > de0: abnormal interrupt: transmit underflow (raising TX threshold to 160|1024)
   > de0: abnormal interrupt: transmit underflow (switching to store-and-forward mode)

   I'm not really familiar with the fine print in that area, but I'll 
   give a try...

   The tranmsmit side of the Tulip has a FIFO.  After the FIFO has <N> 
   bytes in it, the Tulip starts sending bits out the wire.  If N is 
   less than the packet length and the DMA machine can keep up, everybody 
   is happy and you have reduced the round trip latency. 

   If the DMA machine can't keep up, the Tulip does something like fake  
   a collision and try again.  And it gives an error to the driver so 
   that N can be adjusted. 

   There is a knob in the hardware that adjusts N.  Each time the driver 
   notices an underrun error because the DMA side couldn't keep up, 
   it kicks the knob up to the next higher setting.

   So if your system is up for a long time, you should see messages 
   similar to the ones above, but only a few of them.  After that, N 
   should be big enough so that the hardware can keep up.  (One of the 
   otpions is whole-packet.)


This happens minutes after the machine is up with only the most minor bit
of traffic on the wire.  After it has step to "store-and-forward" there is
no further such changes.  Of course, this might all be related to the odd
output errors that seem to occure a lot.  Something is certainly confused.

Thanks...


Brad Spencer - brad@anduin.eldar.org   http://anduin.eldar.org
[finger brad@anduin.eldar.org for PGP public key]