Bug 155837

*** Bug 155010 has been marked as a duplicate of this bug. ***

Not sure I agree with marking 155010 as a duplicate.  I've never had an issue
with FC3.

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. 

What about between FC2 and FC3?  That is where I ran into the rub.

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... 

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
FC3.  

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

Thanks for your help,

Jeff G.

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: 
 
   http://people.redhat.com/linville/kernels/fc3/ 
 
Would you mind giving them a try?  Please post the results here as well.  
Thanks! 

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.

Well, thanks for the report.  Unfortunately, I don't have anything else 
ATM...I'll have to get back to you... :-( 

I know this must be frustrating and sorry that I didn't have a more favorable
report.

Thanks for your help.

Jeff G.

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!  

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. www.scyld.com/network/vortex.html
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=192.168.0.107 DST=255.255.255.255
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=192.168.0.107 DST=255.255.255.255
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. www.scyld.com/network/vortex.html
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

"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! 

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.

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.

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.

Thanks,

Jeff G.

Created attachment 118363 [details]
jwltest-3c59x-mmio.patch

Test kernels w/ above patch available here: 
 
   http://people.redhat.com/linville/kernels/fc3/ 
 
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! 

Installed patched kernel and found no noticeable difference in copy speeds at all.

Thanks for your efforts,

Jeff G.

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. 

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.

Are you still on FC3?  If you have moved to FC4, then I would like for you to 
try the fedora-netdev kernels: 
 
   http://people.redhat.com/linville/kernels/fedora-netdev/ 
 
Please try using those kernels and report the results...thanks! 

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.

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
question.

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.

Could you attach the output of running "ethtool eth0" (substituting the 
correct interface for eth0 if appropriate)?  Thanks! 

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).

Thanks,

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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Well, 10Mb at least explains the slow speed...hmmm... 

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! 

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.

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
site.

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
settings.

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.

Thanks,

Jeff G.

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.

Thanks,

Jeff G.

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.