From: Martin Josefsson <gandalf@wlug.westbo.se>
To: "Gabor Z. Papp" <gzp@papp.hu>
Cc: linux-kernel@vger.kernel.org, jgarzik@pobox.com,
Feldman@tux.rsn.bth.se, Scott <scott.feldman@intel.com>
Subject: Re: 2.4.24 eth0: TX underrun, threshold adjusted.
Date: Sat, 10 Jan 2004 15:56:00 +0100 [thread overview]
Message-ID: <1073746559.752.44.camel@tux.rsn.bth.se> (raw)
In-Reply-To: <x665fkb59o@gzp>
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-01-10 14:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-10 8:02 Gabor Z. Papp
2004-01-10 14:56 ` Martin Josefsson [this message]
2004-01-10 17:39 ` Gabor Z. Papp
2004-01-10 17:53 ` Martin Josefsson
2004-01-10 17:58 ` Gabor Z. Papp
2004-01-10 18:23 ` Martin Josefsson
2004-01-10 19:07 ` Gabor Z. Papp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1073746559.752.44.camel@tux.rsn.bth.se \
--to=gandalf@wlug.westbo.se \
--cc=Feldman@tux.rsn.bth.se \
--cc=gzp@papp.hu \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=scott.feldman@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®