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