Bug 90847 - (NET 3C59X) slow file transfers under linux but not windows
(NET 3C59X) slow file transfers under linux but not windows
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-14 12:56 EDT by James Brusey
Modified: 2013-07-02 22:11 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Brusey 2003-05-14 12:56:52 EDT
Description of problem:

File transfers (for example using SSH) on the local network to/from laptop
running Redhat 8.0 (kernel 2.4.18-27.8.0) are slow.  Am also seeing vortex_error
messages after setting debug=6 for 3c59x driver.

They are noticeably much faster when the laptop is rebooted under Windows.  The
LAN card is 3CCFE575BT CardBus PCMCIA and the 3c59x driver is being used.

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

# uname -a 
Linux mlpc-cellmac 2.4.18-27.8.0 #1 Fri Mar 14 06:45:49 EST 2003 i686 i686 i386
GNU/Linux

# strings /lib/modules/2.4.18-27.8.0/kernel/drivers/net/3c59x.o | grep description
description=3Com 3c59x/3c9xx ethernet driver LK1.1.18-ac 1 July 2002


How reproducible:

By attempting to perform SCP file transfer.

Steps to Reproduce:
1. Perform SCP file transfer to another machine on the local network
2. Time the transfer.
    
Actual results:

This transfer was to the laptop.

time scp misc/downloads/acroread-5.06-4.i386.rpm root@mlpc-cellmac:
acroread-5.06-4.i386 100% |*****************************|  8994 KB    00:14

real    0m14.940s
user    0m0.010s
sys     0m0.029s

this transfer was to a different machine nearby:

[jpb54@mlpc-jpb54 jpb54]$ time scp misc/downloads/acroread-5.06-4.i386.rpm
mlpc-autoid1:
acroread-5.06-4.i386 100% |*****************************|  8994 KB    00:00

real    0m1.055s
user    0m0.004s
sys     0m0.014s


Expected results:


Additional info:
Comment 1 James Brusey 2003-05-14 13:05:47 EDT
p.s. I forgot to mention that the vortex errors look like this:
May 14 16:08:52 mlpc-cellmac kernel: eth0: vortex_error(), status=0xe481
May 14 16:11:04 mlpc-cellmac kernel: eth0: vortex_error(), status=0xe481
May 14 16:13:18 mlpc-cellmac kernel: eth0: vortex_error(), status=0xe481
May 14 16:15:39 mlpc-cellmac kernel: eth0: vortex_error(), status=0xe481
May 14 16:17:52 mlpc-cellmac kernel: eth0: vortex_error(), status=0xe481
May 14 16:20:02 mlpc-cellmac kernel: eth0: vortex_error(), status=0xe481
May 14 16:22:56 mlpc-cellmac kernel: eth0: vortex_error(), status=0xe481

and the network switch has the FDX light off, despite the following info from
vortex-diag:

[root@mlpc-cellmac root]# ./vortex-diag -a
vortex-diag.c:v2.14 12/28/2002 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Index #1: Found a 3CCFE575BT CardBus adapter at 0x4000.
 Station address 00:00:86:3f:2e:5b.
  Receive mode is 0x07: Normal unicast and all multicast.
The Vortex chip may be active, so FIFO registers will not be read.
To see all register values use the '-f' flag.
Initial window 4, registers values by window:
  Window 0: 0000 0000 0000 0000 0000 06ff ffff 0000.
  Window 1: FIFO FIFO 0000 0000 0000 0000 0000 2000.
  Window 2: 0000 3f86 5b2e 0000 0000 0000 0112 4000.
  Window 3: 0000 0060 05ea 0020 0040 1000 0800 6000.
  Window 4: 0000 0000 0000 0cc2 0003 a800 0000 8000.
  Window 5: 1ffc 0000 0000 0600 0807 06ce 06c6 a000.
  Window 6: 0000 0000 0000 0201 0100 a0aa 1883 c000.
  Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0x4000
  0x4010: **FIFO** 00000000 00000024 *STATUS*
  0x4020: 00000020 00000000 00080000 00000004
  0x4030: 00000000 490fb6f1 005a91a0 00080004
  0x4040: 00786739 00000000 00000000 00000000
  0x4050: 00000000 00000000 00000000 00000000
  0x4060: 00000000 00000000 00000000 00000000
  0x4070: 00000000 00000000 01600000 00000000
  DMA control register is 00000020.
   Tx list starts at 00000000.
   Tx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to empty.
   Rx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to full.
   Poll period Tx 00 ns.,  Rx 0 ns.
   Maximum burst recorded Tx 0,  Rx 352.
 Indication enable is 06c6, interrupt enable is 06ce.
 No interrupt sources are pending.
 Transceiver/media interfaces available:  MII.
Transceiver type in use:  MII.
 MAC settings: full-duplex.
 Station address set to 00:00:86:3f:2e:5b.
 Configuration options 0112.
Comment 2 James Brusey 2003-06-17 09:12:58 EDT
I think that I have found a bypass to this problem.  The performance problem is
resolved by using the 3c575_cb driver that comes with the pcmcia-cs package. 
I've only tested this under gentoo linux, but typical transfer rates have
improved substantially since switching to this driver (from 3c59x). (e.g. 50Kb/s
rather than 7Kb/s - although peak performance is greater still).
Comment 3 Bugzilla owner 2004-09-30 11:40:54 EDT
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/

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