Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 155837 - 3Com PCI 3c905B Cyclone slow network copies
Summary: 3Com PCI 3c905B Cyclone slow network copies
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Brian Brock
Depends On: 173225
TreeView+ depends on / blocked
Reported: 2005-04-24 14:28 UTC by Jeff Groves
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-01-04 05:32:16 UTC

Attachments (Terms of Use)
jwltest-3c59x-mmio.patch (deleted)
2005-09-01 19:02 UTC, John W. Linville
no flags Details | Diff

Description Jeff Groves 2005-04-24 14:28:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Description of problem:
After upgrading from FC2 to FC3 and then bringing systems up2date, network file copies to this machine are very slow.  

I saw this problem in FC1 and the suggested fix was to upgrade to FC2 to resolve the issue.

It seems that whatever was the problem in FC1 for the 3Com PCI 3c905B Cyclone and was fixed in FC2 has once again slipped back into the code.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Upgrade FC2 machine to FC3
2.Run up2date -u as your network file copies take forever

Actual Results:  Slow LAN file copies

Expected Results:  Faster network file copies as I had with FC2

Additional info:

Comment 1 John W. Linville 2005-05-04 16:48:59 UTC
*** Bug 155010 has been marked as a duplicate of this bug. ***

Comment 2 Orion Poplawski 2005-05-04 16:53:29 UTC
Not sure I agree with marking 155010 as a duplicate.  I've never had an issue
with FC3.

Comment 3 John W. Linville 2005-05-04 17:06:31 UTC
Except for a one-line cosmetic change, there is no difference between the 
3c59x driver in the latest FC3 and FC4 (i.e. rawhide) kernels. 

Comment 4 Jeff Groves 2005-05-05 03:17:10 UTC
What about between FC2 and FC3?  That is where I ran into the rub.

Comment 5 John W. Linville 2005-05-06 19:44:01 UTC
I'm still looking at it...there are difference between FC2 and FC3, but most 
are ethtool support and power management.  There looks like there is some 
extra statistics collection, which is the only thing I saw that seemed likely 
to effect performance.  I'll have to get back to you... 

Comment 6 Jeff Groves 2005-05-06 22:37:47 UTC
You should also take a look at what changed between FC1 and FC2, because FC1 had
the same problem as FC3. 

It's almost like the changes that were made to fix it for FC2 were left out in

Almost like the fixes for FC2 were made after the FC3 code base created.

Thanks for your help,

Jeff G.

Comment 7 John W. Linville 2005-05-31 20:37:45 UTC
There was an upstream patch dealing with the 3c59x driver and power 
management.  It seems to have cleared-up some "flakiness" with the 3c59x 
driver for some users. 
I have included the patch in my test kernels here: 
Would you mind giving them a try?  Please post the results here as well.  

Comment 8 Jeff Groves 2005-05-31 22:29:20 UTC
I've installed the kernel-2.6.11-1.29_FC3.jwltest.11.i686.rpm and no improvement
in file copy speed.

Copies that took 3 minutes in FC2 are still taking upwards of 11-13 minutes in FC3

Thanks for you help in this matter,

Jeff G.

Comment 9 John W. Linville 2005-06-01 12:26:10 UTC
Well, thanks for the report.  Unfortunately, I don't have anything else 
ATM...I'll have to get back to you... :-( 

Comment 10 Jeff Groves 2005-06-01 13:15:35 UTC
I know this must be frustrating and sorry that I didn't have a more favorable

Thanks for your help.

Jeff G.

Comment 11 John W. Linville 2005-06-10 17:39:14 UTC
I would like for you to add a line to /etc/modules.conf:  
   options 3c59x debug=7  
Then, execute these commands:  
   # ifdown eth0  
   # modprobe -r 3c59x  
   # dmesg -c  
   # ifup eth0  
   # dmesg  
Finally, attach the output of that last "dmesg" command to this bug.   
Hopefully that will be informative...? :-) Thanks!  

Comment 12 Jeff Groves 2005-06-11 01:24:07 UTC
Here's your output!

I hope that it helps.

Jeff G.

PCI: Found IRQ 11 for device 0000:00:11.0
PCI: Sharing IRQ 11 with 0000:00:07.2
3c59x: Donald Becker and others.
0000:00:11.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xdc00. Vers LK1.1.19
PCI: Found IRQ 11 for device 0000:00:11.0
PCI: Sharing IRQ 11 with 0000:00:07.2
eth0: Setting full-duplex based on MII #24 link partner capability of 01e1.
IPT INPUT packet died: IN=eth0 OUT= MAC= SRC= DST=
LEN=198 TOS=0x00 PREC=0x00 TTL=64 ID=15915 DF PROTO=UDP SPT=631 DPT=631 LEN=178 
eth0: no IPv6 routers present
IPT INPUT packet died: IN=eth0 OUT= MAC= SRC= DST=
LEN=198 TOS=0x00 PREC=0x00 TTL=64 ID=15916 DF PROTO=UDP SPT=631 DPT=631 LEN=178 
PCI: Found IRQ 11 for device 0000:00:11.0
PCI: Sharing IRQ 11 with 0000:00:07.2
3c59x: Donald Becker and others.
0000:00:11.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xdc00. Vers LK1.1.19
PCI: Found IRQ 11 for device 0000:00:11.0
PCI: Sharing IRQ 11 with 0000:00:07.2

Comment 13 John W. Linville 2005-06-13 13:45:10 UTC
"IPT INPUT packet died:" lines look to be coming from iptables...I suspect 
that your firewall setup is interfering... 
I would suggesting testing after a "service iptables stop" and/or "iptables -t 
filter -F".  My guess is that things will work better after that.  If so, 
you'll need to refactor your iptables setup. 
Please post your results...thanks! 

Comment 14 Jeff Groves 2005-06-14 04:15:47 UTC
I performed the tests requested to no avail.

Unless something significant changed in iptables between FC2 and FC3, then I
would not have expected this test to succeed, since I had the same iptables
settings under FC2 as I now do under FC3.

Thanks for your continued attempts to troubleshoot this situation.

Jeff G.

Comment 15 Dave Jones 2005-07-15 20:32:58 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 16 Jeff Groves 2005-07-15 23:09:03 UTC
Still on FC3, and no, no improvement.  My similarly configured FC2 machine with
the same hardware still beats my FC3 machine in Samba file transfers by a factor
of 4.


Jeff G.

Comment 17 John W. Linville 2005-09-01 19:02:49 UTC
Created attachment 118363 [details]

Comment 18 John W. Linville 2005-09-01 20:31:22 UTC
Test kernels w/ above patch available here: 
Will have FC4 and FC5 (i.e. Rawhide) versions soon... 
The patch enables some 3c59x-based cards to use memory-mapped PCI I/O 
resources, which can improve performance.  In order to take advantage of that, 
you must add "use_mmio=1" as a 3c59x module option in /etc/modprobe.conf. 
Please give that a try and let me know a) if it works, and b) if it improves 
performace (even only slightly).  If it does work, please attach the output of 
lspci as well.  Thanks! 

Comment 19 Jeff Groves 2005-09-09 03:22:57 UTC
Installed patched kernel and found no noticeable difference in copy speeds at all.

Thanks for your efforts,

Jeff G.

Comment 20 John W. Linville 2005-09-09 12:39:02 UTC
Just to be clear, you did  add "use_mmio=1" as a 3c59x module option 
in /etc/modprobe.conf, right?  The use of memory-mapped PCI I/O resources is 
off by default. 

Comment 21 Jeff Groves 2005-09-09 18:28:11 UTC
Yes, sorry, I did make the requested update to /etc/modprobe.conf.

Sorry that I did not make that clear in my previous message.

Jeff G.

Comment 22 John W. Linville 2005-11-17 18:44:51 UTC
Are you still on FC3?  If you have moved to FC4, then I would like for you to 
try the fedora-netdev kernels: 
Please try using those kernels and report the results...thanks! 

Comment 23 Jeff Groves 2005-11-18 06:55:56 UTC
Great!  Yes, I've gone to FC4 and still have the same issue.

I've updated my yum config per your netdev web site and am in the process of
installing your kernel build at this time.

Stay tuned for results.

- Jeff G.

Comment 24 Jeff Groves 2005-11-18 07:13:22 UTC
A definate improvement over all the previous kernels.

A 349MB file took 8 minutes to copy over a 100base-T network to the machine in

Still not as fast as the 50 seconds that it took to copy the same file over the
same network to a nearly identical box that is still on FC2, but much better
than the 20+ minute copies that I was getting before.

Looks like you're on the right track!

Thanks for your continued work,

Jeff G.

Comment 25 John W. Linville 2005-12-02 16:44:25 UTC
Could you attach the output of running "ethtool eth0" (substituting the 
correct interface for eth0 if appropriate)?  Thanks! 

Comment 26 Jeff Groves 2005-12-04 03:04:30 UTC
Here is the output that you requested.  Please note, that I've tried forcing the
 card to 100/FDX 100/HDX in modprobe.conf with options like "options 3c59x
options=0x208" without any luck.

Additionally, If I force the card to 100fdx or 100hdx interactively using
ethtool, the card works and reports 100, but the file copy times are deplorable
(40 minutes for a file that takes 59 seconds on FC2).


Jeff G.

Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 24
        Transceiver: internal
        Auto-negotiation: on
        Current message level: 0x00000001 (1)
        Link detected: yes

Comment 27 John W. Linville 2005-12-05 16:17:43 UTC
Well, 10Mb at least explains the slow speed...hmmm... 

Comment 28 John W. Linville 2006-01-03 20:36:27 UTC
Take a look at bug 173225 comment 3.  Any chance you could obtain the 
3c90xcfg.exe program, boot under DOS, and use it to ensure the card is 
configured correctly? 
Please try that, and post the results here...thanks! 

Comment 29 Jeff Groves 2006-01-03 21:58:41 UTC
I'll try this if I can find a DOS bootable diskette, but why did this work under
Fedora Core 2 at 100MBPS just fine and not under Fedora Core 3 or 4?

It says to me that there is some way that this issue can be overcome regardless
of the CMOS setting on the network card.

Comment 30 Jeff Groves 2006-01-04 03:12:37 UTC
I found a download for this network card on the Dell web site under "Windows 98"
selection of downloads that had a image for a Windows 98 boot disk included with
the file.  I then downloaded the 3c90XCFG.EXE file from a third party site that
just happened to have the program file available for download.  Google search
for the file name and do a little hunting on the resulting web page and you'll
find it eventually.  I would post the URL here, except that it's not a 3COM web

Anyway, ran the program and found that the NIC had been forced to be 10MEG half
duplex speed by default.  I set the card to autonegotiate and saved the CMOS

What I don't understand is why Fedora Core 2 was able to detect this condition
and correct it during boot so that the card was switched to run at 100/full
duplex, while FC 3 and FC 4 were not able to do this.

Strangeness all around.


Jeff G.

Comment 31 Jeff Groves 2006-01-04 03:14:34 UTC
By the way, the network file copies are now back to their former sub-sixty
second copy rates again after setting the card to autonegotiate with 3c90xcfg.exe.


Jeff G.

Comment 32 Dave Jones 2006-01-04 05:32:16 UTC
great!  The reason it worked in FC2 was possibly that the media detection code
in use there was broken and only 'worked' by accident (ie, it was forcing the
link speed rather than detecting it).

Sounds like this issue is closed, so I'll close the bug.

Note You need to log in before you can comment on or make changes to this bug.