Hide Forgot
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): How reproducible: Always 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 Additional info:
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 interfaces.
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 See Documentation/networking/vortex.txt 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 http://people.redhat.com/arjanv/testkernels/ 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 with -5a.
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".
Steffen- 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 UDP. 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 persists. 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/