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.
etherwake uses obsolete (PF_INET,SOCK_PACKET)
IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:07:e9:12:49:34:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=576 TOS=0x00 PREC=0x00 TTL=20 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=556 IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:07:e9:12:49:34:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=576 TOS=0x00 PREC=0x00 TTL=20 ID=1 PROTO=UDP SPT=68 DPT=67 LEN=556
IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:07:e9:12:49:34:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=576 TOS=0x00 PREC=0x00 TTL=60 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=556 IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:07:e9:12:49:34:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=576 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=556
IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:07:e9:12:49:34:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=576 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=556
eth0: TX underrun, threshold adjusted.
[10 times]
eth0: TX underrun, threshold adjusted.
Host bridge: Intel Corp. 82845G/GL [Brookdale-G]
P4-2.4GHz 512MB RAM
eth0 intel eepro100
eth1 onboard b44 (for pppoe)
Never noticed such problem with 2.4.23 or earlier kernels.
Just noticed, on the nfsroot client getting the same message 4 times.
There is only one eepro100:
Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 10)
Subsystem: Intel Corp.: Unknown device 0070
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at f7800000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at d000 [size=64]
Region 2: Memory at f7000000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Additional debug infos available on request.
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
* Martin Josefsson <[email protected]>:
| > 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?
No, you aren't.
| 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
Funny because I have changed the mobo/cpu/ram from P3 to P4. Maybe
its related to that change?
| This happens with the eepro100 driver as well but it doesn't tell you
| about it, it just increases the threshold and goes on.
I'm using Becker's eepro100, I'm sure.
| I hope this helps to explain this message.
Thanks.
On Sat, 2004-01-10 at 18:39, Gabor Z. Papp wrote:
> | 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?
>
> No, you aren't.
Ok, this time I actually looked at the sources instead of using my
memory which evidently, isn't that good.
You are right, it's the eepro100 driver that prints the messages. But I
was correct that it's the e100 driver that decreases it again :)
Sorry for the confusion.
> | 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
>
> Funny because I have changed the mobo/cpu/ram from P3 to P4. Maybe
> its related to that change?
Most probably.
Scott, disregard most of what I wrote :)
But I still don't really see why the e100 driver decreases the threshold
all the time...
--
/Martin
* Martin Josefsson <[email protected]>:
| > | 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
| >
| > Funny because I have changed the mobo/cpu/ram from P3 to P4. Maybe
| > its related to that change?
|
| Most probably.
This means the old P3 performs better on PCI than the new P4? :-)
Anyway I haven't noticed any incerase in speed... Hello intel.
On Sat, 2004-01-10 at 18:58, Gabor Z. Papp wrote:
> | > Funny because I have changed the mobo/cpu/ram from P3 to P4. Maybe
> | > its related to that change?
> |
> | Most probably.
>
> This means the old P3 performs better on PCI than the new P4? :-)
> Anyway I haven't noticed any incerase in speed... Hello intel.
From my understanding you need to use an intel server-chipset to get
good pci-performance, or a serverworks one.
It seems the old Intel chipsets had quite good pci-performance but the
newer low to medium-range chipsets just suck. But I might be mistaken,
won't be the first time :)
--
/Martin
* Martin Josefsson <[email protected]>:
| From my understanding you need to use an intel server-chipset to get
| good pci-performance, or a serverworks one.
| It seems the old Intel chipsets had quite good pci-performance but the
| newer low to medium-range chipsets just suck. But I might be mistaken,
| won't be the first time :)
Switched from *i815* [Asus TUSL2-C] to *i845G* [Asus P4PE-X].
Both old and new config had 6 PCI and 1 AGP card installed.
(2 VGA, 2 NIC, 1 Sound, 1 ATA and the AGP card)