From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0-10)
Description of problem:
I have upgraded my two systems to the new kernel. System A ist an Intel Pentium2 450 MHz System, System B ist an AMD 1000 Mhz. Both system are connected via 100 Mb network. With kernel 2.4.18-4 on both sides nfs is working fine. After upgrading I have a read perfomance of about 30 kbit/s.
If I use the old kernel on the athlon machine the performance is good again.
With tcpdump I see many icmp messages: "ip reassembly time exceeded tos 0xc0"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. running kernel 2.4.18-5 on Intel
2. running kernel 4.4.18-5 on AMD
3. using NFS
Actual Results: slow nfs performance
Expected Results: normal nfs performance
Which network cards and drivers are being used between the systems? What is the
configuration of the nfs server?
Created attachment 62604 [details]
nfs startup script
Ok, on both servers are 3Com PCI 3c905B Cyclone 100baseTx installed, using the default
driver 3c59x comming with the kernel. Configured with option=8 in /etc/modules.conf. With
these settings I get a 100 Mbit/s full-duplex connection. I have also checked
/var/log/messages to see that it's really a full-duplex connection.
I haven't changed any settings for the nfs-server. But nevertheless I have attached the
nfs-startup script to be sure.
I have done some more tests and have seen that it's not only a problem with nfs, even ftp
is really slow independet of the network card configuration - I have tried option=5
(100base-FX) on both sides - nothing changed. With SFTP I will get a transfer rate of
about 300-400 kbit/sec without any icmp messages and without errors on the eth0
What network drivers are involved?
Sorry, I don't understand your question. I'm using the default kernel driver 3c59x.o.
Maybe this helps:
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x9800. Vers LK1.1.17
00:04:76:73:3b:d7, IRQ 10
product code 4d4c rev 00.12 date 07-26-01
Internal config register is 1000000, transceivers 0xa.
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/10baseT interface.
00:0b.0: Media override to transceiver type 5 (100baseFX).
MII transceiver found at address 24, status 784d.
Enabling bus-master transmits and whole-frame receives.
00:0b.0: scatter/gather enabled. h/w checksums enabled
eth0: Media override to transceiver 5 (100baseFX).
eth0: Initial media type 100baseFX.
eth0: vortex_up() InternalConfig 01500000.
eth0: vortex_up() irq 10 media status 8080.
These servers are connected with an switch from `level one`. Or, also tested, directly
with an crossover cable. Is it that what you've ment?
Could you try the 2.4.18-5a kernel at
it has a 3c59x bugfix...
Here my success report for -5a:
After I upgraded my LTSP server to -5, the X connections became slow and
jerkily. The network card used on the server is a 3c905B. Everything works fine
If have installed the -5a kernel on both machines, but nothing changed. There are still
the performance problems and I still see the icmp-messages.
See also my bug #67199 "kernel-2.4.18-5, very slow nfs(w/sync) ~50k writes".
The NFS problem may be the result of a known problem with the IP fragmentation
logic in the IP layer. From your description, you are probably using NFS over
Try increasing the transport socket buffer size:
1. Log onto your client as root
2. cd /proc/sys/net/core
3. echo 262143 > rmem_max
4. echo 262143 > wmem_max
5. echo 262143 > rmem_default
6. echo 262143 > wmem_default
7. Remount your NFS file systems on the client
Another option is to try mounting explicitly with NFS over TCP.
Actually, this hints at the real cause, which may be network problems causing
severe packet losses.
*** Bug 67199 has been marked as a duplicate of this bug. ***
FYI, the 2.4.18-7 test kernels work great! NFS speeds are respectable, even
when exported/mounted 'sync'.
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/