From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 Description of problem: The via-rhine module shows incredibly slow throughput with via VT6102 onboard NIC; around 40kilobytes per second as opposed to 9megabytes. The following two onboard NICs are present in the affected systems ( from /etc/sysconfig/hwconf ): class: NETWORK bus: PCI detached: 0 device: eth0 driver: via-rhine desc: "VIA Technologies|VT6105 [Rhine-III]" network.hwaddr: 00:40:63:D4:52:4E vendorId: 1106 deviceId: 3106 subVendorId: 1106 subDeviceId: 0102 pciType: 1 pcibus: 0 pcidev: f pcifn: 0 - class: NETWORK bus: PCI detached: 0 device: eth1 driver: via-rhine desc: "VIA Technologies|VT6102 [Rhine-II]" vendorId: 1106 deviceId: 3065 subVendorId: 1106 subDeviceId: 0102 pciType: 1 pcibus: 0 pcidev: 12 pcifn: 0 Only the latter exhibits the problem. Compiling and forcing use of the rhinefet driver from VIA, currently at version 4.32, solves the issue. This leads to the conclusion that the via-rhine module, rather than the onboard NIC, is faulty. Version-Release number of selected component (if applicable): All RHEL3 kernel releases, currently up to 2.4.21-15.0.4.EL How reproducible: Always Steps to Reproduce: 1. Install RHEL3 on system as described above 2. Test throughput of second NIC ( eth1 above ) 3. Test with all released kernel errata if required Additional info:
Tramada, I don't understand your bugreport clearly, because I can't get the information whether "VIA Technologies|VT6105 [Rhine-III]" (eth0) or "VIA Technologies|VT6102 [Rhine-II]" (eth1) has the throughput problem. I still guess that eth1 is your problem card?! Thank you very much.
Correct; as mentioned, it is the VT6102, in this case eth1. Thanks for your interest :0)
Created attachment 102492 [details] linux-2.4.21-via-rhine_1.1.19.patch Did you try to disable the card of eth0 in BIOS and check whether it is maybe a driver conflict between those two cards? So I'm/we're running a box with Fedora Core 1 and "VIA Technologies|VT6102 [Rhine-II]" properly and plan to switch to RHEL3 at this box, but your problem makes me careful and scared, now :-S I did a diff at this driver between FC1's and RHEL3's latest kernels which should be useable as patch for the RHEL3 kernel. If you've got too much time, you can try it, maybe it solves your problem...even if I don't believe that really ;-)
With regards to your concern about moving a working FC1 machine to RHEL3, if you refer to the original bug report you'll see that the driver provided by VIA, 'rhinefet', currently at v4.32, solves the problem. So assuming you're happy with compiling this module whenever required, and everything that goes along with that, then you should be safe to complete the migration, at least in this respect :0)
Maybe of belong for this bug, but our RHEL3 (before FC1) machine with latest RHEL3 kernel works with a single "VIA Technologies|VT6102 [Rhine-II]" network card fine, we've got no slow throughput. So I think your problem seems to be related with the 2 network cards...
I'm seeing the exact same behaviour using Linux 2.4.25 on a custom Linux distribution. I'm using a VIA CL6000e motherboard. Will try rhinefet.
Works with rhinefet, although occasionally one or both NICs will drop to 1.3 mbyte/sec throughput (normally they run around 9.5-10.5 mbyte/sec).
(In reply to comment #7) > Works with rhinefet, although occasionally one or both NICs will drop to 1.3 > mbyte/sec throughput (normally they run around 9.5-10.5 mbyte/sec). Thanks for your input Michael, glad the rhinefet driver is performing for you. Once question though, have you tested both input and output throughput on both interfaces? We were never able to get perfect results in both directions on both interfaces at the same time, with any Linux driver, so ended up addind a third NIC in place of one of the VIAs - it was either that or run Windows :0) ...this resolved (read, bypassed/bandaided) the problem entirely.
RHEL ES v4 This single onboard NIC is the combination of the VT6102 MAC Connector and the VT6103 Physical Layer interface, according to the MoBo spec offered by the mfgr. ABIT/KD7A, brand/model VIA, VT 6102 Rhine II Fast Ethernet adapter: very slow throughput, not functionally usable I am currently experiencing this issue as reported, with a couple of twists: 1. O/S reference change to RHEL ES v4 2. Ethernet NIC referenced is a single NIC cfg. 3. Cfg. installed and NIC was recognized but did not work at all, at first: card could not be "activated." Activation failed and processes would hang. 4. After changing IRQ settings, the card accepted activation but xfers only at the excrutiatingly slow pace referred to in the original bug. 5. I do not know if this patch (rhinefet) will work successfully with RHEL 4, as the former initiator of the original bug finally swapped out one of the two rhine cards (one 6102 and one 6105 -though he does not specify which) in favor of another NIC completely. This bug seems to remain unresolved, as this is a fresh install of RHEL 4. Thank you for your input and assistance in analyzing and working to resolve this matter.
Same problem, using a DLink DFE-530TX NIC, ("VIA Technologies, Inc. VT6102 [Rhine-II]" from lspci command), as the single NIC in a system running kernel 2.4.27 (Debian...sarge). It reproducibly slows to a stop after some 100's of megabytes received since booting. Observation: some receive throughput is restored while flooding a directly attached router through this NIC, using ping -f. The ping command shows some dozen or so packets dropped.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.