Re: 2.4.24 eth0: TX underrun, threshold adjusted.

[Martin Josefsson]

On Sat, 2004-01-10 at 09:02, Gabor Z. Papp wrote:
> Replacing 2.4.23 with 2.4.24 went without any error I noticed.
> 
> After 8h uptime I have connected the first nfsroot client.
> 
> In the server host klog got 12 "eth0: TX underrun, threshold adjusted."
> messages while the client started to mount the dirs.

> eth0: TX underrun, threshold adjusted.
> [10 times]
> eth0: TX underrun, threshold adjusted.

> eth0 intel eepro100

I think you ran the eepro100 driver in 2.4.23 and now in 2.4.24 you are
using the e100 driver, am I correct?

This isn't really an error, it's an indicator that the pci-bus doesn't
really keep up, then the NIC has to increase the threshold (it tries to
start sending the packet out before it's fully transferred from main
memory to the NIC, it hopes the rest of the packet will have been
transferred in time, this message indicates that it wasn't so the NIC
had to increase the threshold of how much of the packet has to have been
transferred before it starts sending it out)

This happens with the eepro100 driver as well but it doesn't tell you
about it, it just increases the threshold and goes on.
The e100 driver tells you about it _and_ it actually decreases the
threshold if there hasn't been any underruns for a while, and when it is
decreased, the threshold gets too small and you get an underrun
again....

I hope this helps to explain this message.

Scott (cc'd), do you know why the e100 driver insists on decreasing the
threshold all the time? It's decreased when there havn't been any
underruns for a while (and there havn't been any underruns for a while
just because we increased the threshold). This _will_ give lots and lots
of these messages on machines where the pci is a bit too slow. How about
not decreasing it at all? Or only telling the user about the situation
until we have decreased it for the first time, then it shuts up as this
message gets quite annoying.

I can see that we might want to decrease the threshold if the reason for
it was temporary high load on the pci-bus, but that we will never know.
Or maybe increase the limit of which the decreasing is based, iirc it
only decreases if the threshold is above some value. I see the
decrease/increase "loop" here quite a bit on amd768 (mpx) chipsets.

-- 
/Martin

Attachment: signature.asc
Description: This is a digitally signed message part