Description of problem: First off, this problem also existed in kernel-2.4.22-1.2061. The following messages show up in /var/log/messages: Oct 16 15:41:42 wirepub kernel: eth0: Transmit error, Tx status register 82. Oct 16 15:41:42 wirepub kernel: Probably a duplex mismatch. See Documentation/networking/vortex.txt Oct 16 15:41:42 wirepub kernel: Flags; bus-master 1, dirty 21452(12) current 21453(13) Oct 16 15:41:42 wirepub kernel: Transmit list 00000000 vs. cb2cc500. Oct 16 15:41:42 wirepub kernel: <gth 800005c6 status 000105c6 Oct 16 15:41:42 wirepub kernel: 2: @cb2cc280 length 800005c6 status 000105c6 Oct 16 15:41:42 wirepub kernel: 3: @cb2cc2c0 length 800005c6 status 000105c6 Oct 16 15:41:42 wirepub kernel: 4: @cb2cc300 length 800005c6 status 000105c6 Oct 16 15:41:43 wirepub kernel: 5: @cb2cc340 length 800005c6 status 000105c6 Oct 16 15:41:43 wirepub kernel: 6: @cb2cc380 length 800005c6 status 000105c6 Oct 16 15:41:43 wirepub kernel: 7: @cb2cc3c0 length 800005c6 status 000105c6 Oct 16 15:41:43 wirepub kernel: 8: @cb2cc400 length 800005c6 status 000105c6 Oct 16 15:41:43 wirepub kernel: 9: @cb2cc440 length 800005c6 status 000105c6 Oct 16 15:41:43 wirepub kernel: 10: @cb2cc480 length 800005c6 status 800005c6 Oct 16 15:41:43 wirepub kernel: 11: @cb2cc4c0 length 800005c6 status 000105c6 Oct 16 15:41:43 wirepub kernel: 12: @cb2cc500 length 800005c6 status 000105c6 Oct 16 15:41:43 wirepub kernel: 13: @cb2cc540 length 800005c6 status 000105c6 Oct 16 15:41:43 wirepub kernel: 14: @cb2cc580 length 800005c6 status 000105c6 Oct 16 15:41:43 wirepub kernel: 15: @cb2cc5c0 length 800005c6 status 000105c6 The HP switch port on our procurve 4108gl to which this computer is directly connected shows the following errors: W 10/17/03 11:58:02 FFI: port B11-Excessive CRC/alignment errors. See help. W 10/17/03 11:58:23 FFI: port B11-Excessive CRC/alignment errors. See help. W 10/17/03 11:58:44 FFI: port B11-Excessive CRC/alignment errors. See help. W 10/17/03 12:04:52 FFI: port B11-Excessive undersized/giant packets. See help. W 10/17/03 12:08:11 FFI: port B11-Excessive undersized/giant packets. See help. W 10/17/03 12:47:13 FFI: port B11-Excessive undersized/giant packets. See help. W 10/17/03 13:08:14 FFI: port B11-Excessive CRC/alignment errors. See help. W 10/17/03 13:09:48 FFI: port B11-Excessive CRC/alignment errors. See help. the hp switch port is running at 100FDx and set to auto-negotiate. Compiling and using the 3c59x module from Donald Beckers' net-drivers package fixes the problem. Version-Release number of selected component (if applicable): kernel-2.4.22-1.2088.nptl How reproducible: Always Steps to Reproduce: 1.Reinstall this computer with Fedora Core 3. 2.Do some network transfers 3.Watch the logs. Actual results: Erros as detailed above Expected results: No network errors. Additional info: # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping : 3 cpu MHz : 547.186 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1091.17 lspci -v : 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) Subsystem: Dell Computer Corporation: Unknown device 0080 Flags: bus master, medium devsel, latency 64 Memory at ec000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: fc000000-fdffffff Prefetchable memory behind bridge: f2000000-f5ffffff 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 64 I/O ports at ffa0 [size=16] 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 64, IRQ 14 I/O ports at dce0 [size=32] 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) Flags: medium devsel, IRQ 9 00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] Subsystem: Dell Computer Corporation 3C905B Fast Etherlink XL 10/100 Flags: bus master, medium devsel, latency 64, IRQ 14 I/O ports at dc00 [size=128] Memory at fe000000 (32-bit, non-prefetchable) [size=128] Expansion ROM at f9000000 [disabled] [size=128K] Capabilities: [dc] Power Management version 1 00:13.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, medium devsel, latency 64 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 I/O behind bridge: 0000e000-0000efff Memory behind bridge: fa000000-fbffffff Prefetchable memory behind bridge: 00000000f1000000-00000000f1f00000 Capabilities: [dc] Power Management version 1 01:00.0 VGA compatible controller: nVidia Corporation NV5 [RIVA TNT2/TNT2 Pro] (rev 11) (prog-if 00 [VGA]) Subsystem: Diamond Multimedia Systems RIVA TNT2/TNT2 Pro Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11 Memory at fc000000 (32-bit, non-prefetchable) [size=16M] Memory at f4000000 (32-bit, prefetchable) [size=32M] Expansion ROM at 80000000 [disabled] [size=64K] Capabilities: [60] Power Management version 1 Capabilities: [44] AGP version 2.0 02:0a.0 SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891/7890 Subsystem: Dell Computer Corporation: Unknown device 0080 Flags: bus master, medium devsel, latency 64, IRQ 10 BIST result: 00 I/O ports at ec00 [disabled] [size=256] Memory at fafff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at fb000000 [disabled] [size=128K] Capabilities: [dc] Power Management version 1 02:0e.0 SCSI storage controller: Adaptec AIC-7880U (rev 01) Subsystem: Adaptec AIC-7880P Ultra/Ultra Wide SCSI Chipset Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at e800 [disabled] [size=256] Memory at faffe000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at fb000000 [disabled] [size=64K] Capabilities: [dc] Power Management version 1
Hi, I'm seeing something that seems to be very similar. I'm not able to get network communication to work and /var/log/messages is filled with: Oct 17 15:45:11 eddy kernel: NETDEV WATCHDOG: eth0: transmit timed out Oct 17 15:45:11 eddy kernel: eth0: transmit timed out, tx_status 00 status e000. Oct 17 15:45:11 eddy kernel: diagnostics: net 0cc0 media 8802 dma 00000000. Oct 17 15:45:11 eddy kernel: Flags; bus-master 1, dirty 1(1) current 17(1) Oct 17 15:45:11 eddy kernel: Transmit list 00000000 vs. c46dc240. Oct 17 15:45:11 eddy kernel: 0: @c46dc200 length 8000002a status 8000002a Oct 17 15:45:11 eddy kernel: 1: @c46dc240 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 2: @c46dc280 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 3: @c46dc2c0 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 4: @c46dc300 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 5: @c46dc340 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 6: @c46dc380 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 7: @c46dc3c0 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 8: @c46dc400 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 9: @c46dc440 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 10: @c46dc480 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 11: @c46dc4c0 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 12: @c46dc500 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 13: @c46dc540 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 14: @c46dc580 length 8000002a status 0000002a Oct 17 15:45:11 eddy kernel: 15: @c46dc5c0 length 8000002a status 8000002a The hardware is a Dell Dimension XPS D333 with the following: 00:00.0 Host bridge: Intel Corp. 440LX/EX - 82443LX/EX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 440LX/EX - 82443LX/EX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 01) 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 01) 00:0d.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] 00:0e.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 14) 00:0e.1 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 14) 01:00.0 Display controller: Texas Instruments TVP4020 [Permedia 2] (rev 01) running a freshly installed fedora core: Fedora Core release 0.95 (Severn) kernel-2.4.22-1.2088.nptl kernel-utils-2.4-8.31 Is something fishy with the 3c9xx driver(s)? I'll grab a spare NIC and see if I can at least get the networking up. Please feel free to contact me if you'd like more hardware details. Ed ==> eh3 at mit dot edu
I installed RH 9 on the same system and the 3c905 works without a hitch, so it seems likely that theres something wrong with the driver in Fedora Core release 0.95 (Severn). I have a spare partition on the machine and will re-install Fedora Core as soon as the next update is available.
Hi again! I now have the above Dell machine dual-booting RH9 and the latest Fedora Core with the upgraded kernel (kernel-2.4.22-1.2097.nptl.i686.rpm). DHCP networking is just fine with RH 9. Fedora Core fails to get the identical, simple DHCP networking running and returns: Determining IP information for eth0... failed. with the following in /var/log/messages: Oct 18 07:34:21 localhost login(pam_unix)[1916]: session opened for user root by LOGIN(u id=0) Oct 18 07:34:22 localhost -- root[1916]: ROOT LOGIN ON tty1 Oct 18 07:35:05 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 inte rval 3 Oct 18 07:35:05 localhost kernel: eth0: Transmit error, Tx status register d0. Oct 18 07:35:05 localhost kernel: Flags; bus-master 1, dirty 1(1) current 1(1) Oct 18 07:35:05 localhost kernel: Transmit list 00000000 vs. c48fd240. Oct 18 07:35:05 localhost kernel: 0: @c48fd200 length 80000156 status 80000156 Oct 18 07:35:05 localhost kernel: 1: @c48fd240 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 2: @c48fd280 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 3: @c48fd2c0 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 4: @c48fd300 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 5: @c48fd340 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 6: @c48fd380 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 7: @c48fd3c0 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 8: @c48fd400 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 9: @c48fd440 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 10: @c48fd480 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 11: @c48fd4c0 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 12: @c48fd500 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 13: @c48fd540 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 14: @c48fd580 length 00000000 status 00000000 Oct 18 07:35:05 localhost kernel: 15: @c48fd5c0 length 00000000 status 00000000 Oct 18 07:35:08 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 inte rval 8 Oct 18 07:35:16 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 inte rval 12 Oct 18 07:38:35 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 inte rval 5 Oct 18 07:38:35 localhost kernel: eth0: Transmit error, Tx status register d0. Oct 18 07:38:35 localhost kernel: Flags; bus-master 1, dirty 1(1) current 1(1) Oct 18 07:38:35 localhost kernel: Transmit list 00000000 vs. c48fd240. Oct 18 07:38:35 localhost kernel: 0: @c48fd200 length 80000156 status 80000156 Oct 18 07:38:35 localhost kernel: 1: @c48fd240 length 80000156 status 00000156 Oct 18 07:38:35 localhost kernel: 2: @c48fd280 length 80000156 status 80000156 Oct 18 07:38:35 localhost kernel: 3: @c48fd2c0 length 00000000 status 00000000 Oct 18 07:38:35 localhost kernel: 4: @c48fd300 length 00000000 status 00000000 Oct 18 07:38:35 localhost kernel: 5: @c48fd340 length 00000000 status 00000000 ... Oct 18 07:38:40 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 inte rval 9 ... Oct 18 07:41:23 localhost dhclient: No DHCPOFFERS received. Both RH 9 and Fedora Core report the hardware as: 00:00.0 Host bridge: Intel Corp. 440LX/EX - 82443LX/EX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 440LX/EX - 82443LX/EX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 01) 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 01) 00:0e.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] 00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 14) 00:10.1 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 14) 01:00.0 VGA compatible controller: Texas Instruments TVP4020 [Permedia 2] (rev 01) Both RH 9 and Fedora Core are using the "3c59x.o" module. Please don't hesitate to contact me if you'd like further info.
I've had some (similar) problems with a PCMCIA 3c575 (also uses 3c59x.o module) - see my bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106838 Problems also started with Severn, it worked flawlessly with 9 and before. It also works for me without rhgb. I haven't pinpointed the source of the problem yet (seems to be rhgb+kernel related), but restarting the pcmcia service seems to bring the card back to life. Can you try removing the 3c59x module and loading it again after the system has booted up?
I had the same problem. The weird thing is that it went away when I disabled the kudzu service. I did nothing else. It seems that something kudzu does during its probing makes a 3c905 very unhappy. My setup is a Athlon XP 1900+, VIA KT333Pro (Asus A7V333 motherboard) with a PCI 3c905.
I have a 3com 3c900B card requiring the 3c59x module. I was not able to setup networking (in FCtest3) untill I disabled the kudzu service on bootup. (I didn't use any updates from rawhide or elsewhere) I still use the graphical bootup. Everything works now wich is great.
I had a somewhat similar problem, on my 3c905 Cyclone with kernel-2.4-20-20.9 and some rawhide upgrades. (My problem was probably kudzu, similar to the above comment). Replacing the normal network drivers with the latest netdrivers at http://www.scyld.com/network/ fixed the problem for me without updating my kernel or removing kudzu. It's possible that my problem wasn't the same, but it's also possible that newer netdrivers will fix this problem as well. -M
Just a 'me too' report. On my Linux machine (a HP Vectra with a 3Com 3c905 onboard) I experience the same problem as described here (problems with the 3c59x module). The PC is running Fedora Core release 0.95 (Severn) without any updates from Rawhide. Starting an X application (eg. Mozilla) on that machine on the display of another PC (with 'export DISPLAY') takes a _long_ time before the output of Mozilla displays. Because communication (100 Mbit) on that network is realised with a hub, I checked the network card speed with the command "mii-tool". It seems that the 3Com card in the PC with the troubles has 'auto-negotiated' itself on 10 Mbit. Strange, because it is on a 100 MBit hub. Then I, as suggested in comment #5, disabled kudzu in all runlevels and rebooted. After the reboot "mii-tool" reported that it was running on 100 Mbit - as it should. So, also for me the fix was in disabling Kudzu. It seems Kudzu screws with the network card configuration somewhere. If needed I can attach some specs and information about the machine with the problem.
Another "me too" report. System is a dual P3-800 with a 3Com Corporation 3c905 100BaseTX [Boomerang]. Running the latest Fedora Test kernel (2.4.22-1.2111.nptlsmp) networking dies and the kernel log fills up with: eth0: Transmit error, Tx status register 90. Flags; bus-master 1, dirty 1(1) current 17(1) Transmit list 1a8df280 vs. da8df240. 0: @da8df200 length 8000002a status 8000002a 1: @da8df240 length 8000002a status 0000002a 2: @da8df280 length 8000002a status 0000002a 3: @da8df2c0 length 8000002a status 0000002a 4: @da8df300 length 8000002a status 0000002a ... Running an unpatched 2.6.0-test9 kernel works perfectly.
This is still broken with 2.4.22-1.2115.nptlsmp...
Same problems with Fedora Core 1 release (yarrow). Using 2.4.22- 1.2115.nptl. I have to turn off Kudzu at the boot runlevel in order for my 3c905 to initialize properly. This is on an Asus P2b a very solid 440BX based board that worked without a hitch in Redhat 7.0- 9.0 and has no problem with other Distros. I will try a 2.6 series kernel and see what happens as well.
Using 2.6.0-0.test9.1.70 I can boot the system with Kudzu on at the given runlevel (5) and eth0 (3c905) initializes and the network works properly. One weird thing however when the system booted Kudzu started detected a hardware change and asked me to remove the config for eth0 which I did not (I optioned to keep the existing configuration).
I downgraded kudzu to the 0.99 version rpm from Redhat 9 with Fedora (yarrow) rebooted with kudzu on and eth0 initializes ok and the network works. As soon as I updated kudzu to the latest version from Fedora the 3c905 just hangs again when kudzu is on at the runlevel. the mii-tool also fails and outputs no MII found. When kudzu is off at boot time mii-tool shows that the 3c905 has negotiated 100Mbitfull-duplex and the nic works.
*** Bug 107998 has been marked as a duplicate of this bug. ***
Two things to try: - run with kudzu enabled and the Red Hat Linux 9 errata kernel instead of the Fedora Core kernel - boot without loading the driver. Turn off hotplug so the interface doesn't automatically come up. Then load the module, run 'ethool -i <interface>', run 'ifconfig', and then bring up the interface.
Bill: Downgrading to RHL9's 2.4.20-8 errata kernel had no effect for me. Still have no network connectivity as long as kudzu is enabled. (I'm getting the same errors as Ed Hill.) I'd also like to add that this problem occurs independently of whether a Red Hat kernel is used. I experience the same problem when running an unpatched 2.4.22 kernel. My config: Athlon, VIA KT133 chipset, 3C905-TX NIC
Also, I tried replacing the 3C905-TX card with a 3C980C-TXM card, and it works fine with kudzu (1.1.36-1) enabled. Both models use the same 3c59x driver.
*** Bug 109547 has been marked as a duplicate of this bug. ***
*** Bug 109548 has been marked as a duplicate of this bug. ***
*** Bug 109703 has been marked as a duplicate of this bug. ***
Another "Me too" I have an HP Vectra VE 6/350 with a 3c905 card and it experiences exactly the same issue. Fortunately the trick of disabling Kudzu solved the issue for me.
An another workaround I discovered in Enterprise Linux 3.0 (Bug 107998 as a duplicate of this bug) is to explicitly insert 3c59x module before kudzu. I made a 'dirty' change in rc.sysinit to add insmod 3c59x. It fixed this problem as well.
"An another workaround I discovered in Enterprise Linux 3.0 (Bug 107998 as a duplicate of this bug) is to explicitly insert 3c59x module before kudzu. I made a 'dirty' change in rc.sysinit to add insmod 3c59x. It fixed this problem as well." can you explain this? i don't understand what you mean...
Using a PCI version of the Vortex Boomerang NIC. I get a cable unplugged error on bootup. This error started with Severn1 and I assume that it is still a problem. In my case, I could run dhclient from a root terminal and get a IP address. There were then a lot of problems with mozzila, GNOME and other problems. I changed the NIC with a 3com Tornado and it works without problems. I believe that the card was detected as a hurricane, instead of a vortex Boomerang, like it should be identified as. I have a bug that I entered previously with the cable unplugged problem that I encountered, I could not locate it on Bugzilla though.
With a PCMCIA 3c575 (module 3c59x) in an old laptop I had no network, and was getting these same error messages, but disabling rhgb as Milos suggested above cured it for me.
Running 3c905B with the default settings (100MBit) it has a througput of about 10k/s. I've encountered a very high carrier count. Whenn running the card at 10MBit i get ~600k/s. Additionally when enabling debug information (options 3c59x debug=3) in /etc/modules.conf I get lots of: eth0: vortex_error(), status=0xe081 (at 100MBit and at 10MBit). The Card was running fine on RH 8.0. Disabling Kudzu at startup does not solve the problem.
Is it possible that this has something to do with bug 75062 or bug 75813, both of which are still unresolved? Granted, one is for 8.0, and another for 7.x, but it's possible that a change in FC1 exposed these problems in a more significant fashion. Also - does anybody know the exact version of kudzu at which this starts happening? We know that it doesn't happen with 0.99, and that it DOES happen with the most recent release, 1.1.36-1. Can we get any more accurate than that? -M
Some other bug that deals with a pci devices bug mentioned to change the below. Ths comment was from the fedora mailing list for the distribution. Try changing the line to say the below. Excerpt: Could be the PCI bug they've been struggling with. Try setting /etc/sysconfig/init line "GRAPHICAL=no" and rebooting. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100920
Max K-A; it almost certainly started when kudzu started using ethtool.
*** Bug 110678 has been marked as a duplicate of this bug. ***
Another data point. I have an HP Vectra VL, P2-450, 128M, 10G with this problem. If there is a cable plugged into the 3c905b card, the machine locks up. Only a power cycle brings it back.
Another datapoint, Fedora core-1 machine eth0: Transmit error, Tx status register 82. Probably a duplex mismatch. See Documentation/networking/vortex.txt Flags; bus-master 1, dirty 2514184(8) current 2514184(8) Transmit list 00000000 vs. db805400. 0: @db805200 length 800005ea status 000105ea 1: @db805240 length 800005ea status 000105ea 2: @db805280 length 800005ea status 000105ea 3: @db8052c0 length 800005ea status 000105ea 4: @db805300 length 800005ea status 000105ea 5: @db805340 length 800005ea status 000105ea 6: @db805380 length 800005ea status 000105ea 7: @db8053c0 length 800005ea status 800105ea 8: @db805400 length 800005ea status 000105ea 9: @db805440 length 800005ea status 000105ea 10: @db805480 length 800005ea status 000105ea 11: @db8054c0 length 800005ea status 000105ea 12: @db805500 length 800005ea status 000105ea 13: @db805540 length 800005ea status 000105ea 14: @db805580 length 800005ea status 000105ea 15: @db8055c0 length 800005ea status 000105ea [root@kiki james_]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 1 cpu MHz : 696.418 cache size : 256 KB physical id : 0 siblings : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse runqueue : 0 bogomips : 1389.36 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 3 cpu MHz : 696.418 cache size : 256 KB physical id : 0 siblings : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse runqueue : 1 bogomips : 1392.64 [root@kiki james_]# /sbin/lspci -v 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03 ) Subsystem: Dell Computer Corporation: Unknown device 0080 Flags: bus master, medium devsel, latency 64 Memory at f0000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: fc000000-fdffffff Prefetchable memory behind bridge: e0000000-efffffff 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 64 I/O ports at 1000 [size=16] 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 64, IRQ 19 I/O ports at ece0 [size=32] 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) Flags: medium devsel, IRQ 9 00:0e.0 FireWire (IEEE 1394): Lucent Microelectronics FW323 (rev 04) (prog-if 10 [OHCI]) Subsystem: Lucent Microelectronics FW323 Flags: bus master, medium devsel, latency 64, IRQ 17 Memory at fe001000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:10.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02) Subsystem: Adaptec 29160N Ultra160 SCSI Controller Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 19 BIST result: 00 I/O ports at e800 [disabled] [size=256] Memory at fe000000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at f9000000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] Subsystem: Dell Computer Corporation 3C905B Fast Etherlink XL 10/100 Flags: bus master, medium devsel, latency 64, IRQ 19 I/O ports at ec00 [size=128] Memory at fe002000 (32-bit, non-prefetchable) [size=128] Expansion ROM at f9000000 [disabled] [size=128K] Capabilities: [dc] Power Management version 1 00:13.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) (prog-i f 00 [Normal decode]) Flags: bus master, medium devsel, latency 64 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 I/O behind bridge: 0000f000-0000ffff Memory behind bridge: fa000000-fbffffff Prefetchable memory behind bridge: 00000000f5000000-00000000f5f00000 Capabilities: [dc] Power Management version 1 01:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3 Ti 200] (re v a3) (prog-if 00 [VGA]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 8503 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 16 Memory at fc000000 (32-bit, non-prefetchable) [size=16M] Memory at e8000000 (32-bit, prefetchable) [size=128M] Memory at e7f80000 (32-bit, prefetchable) [size=512K] Expansion ROM at 80000000 [disabled] [size=64K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 2.0 02:0a.0 SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891/7890 Subsystem: Dell Computer Corporation: Unknown device 0080 Flags: bus master, medium devsel, latency 64, IRQ 18 BIST result: 00 I/O ports at fc00 [disabled] [size=256] Memory at fafff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at fb000000 [disabled] [size=128K] Capabilities: [dc] Power Management version 1 02:0e.0 SCSI storage controller: Adaptec AIC-7880U (rev 01) Subsystem: Adaptec AIC-7880P Ultra/Ultra Wide SCSI Chipset Flags: bus master, medium devsel, latency 64, IRQ 18 I/O ports at f800 [disabled] [size=256] Memory at faffe000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at fb000000 [disabled] [size=64K] Capabilities: [dc] Power Management version 1 Networking works but is not fast .. Plugged in to a cisco 501
I reinstalled the boomerang into the machine and tried it out with both the 2.6 kernel and the 2.4 kernel. The first output is from the working tornado NIC with the latest Fedora 2.4 kernel. The later is output from the boomerang which gives me a check cable with the 2.4 and does not seem to be present for the 2.6 kernel. I pinged both cards from another machine and there were no packages dropped. The same situation exists. I can run dhclient and get an IP address from the boomerang 3com NIC. Both cards are setup for dhcp. ifconfig initially states the below before running dhclient. ifconfig eth0 Link encap:Ethernet HWaddr 00:01:02:FA:69:F3 inet addr:192.168.1.102 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:39400 errors:0 dropped:0 overruns:0 frame:0 TX packets:37287 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:55112354 (52.5 Mb) TX bytes:2635316 (2.5 Mb) Interrupt:11 Base address:0xd880 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3246 errors:0 dropped:0 overruns:0 frame:0 TX packets:3246 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2713992 (2.5 Mb) TX bytes:2713992 (2.5 Mb) It later shows this output, after running dhclient. Kudzu is enabled and no changes were done manually to any file. (Such as return 1 to trick the card into thinking the NIC did not error with check cable) after dhclient: ifconfig eth0 Link encap:Ethernet HWaddr 00:01:02:FA:69:F3 inet addr:192.168.1.102 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:41911 errors:0 dropped:0 overruns:0 frame:0 TX packets:39705 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:58690820 (55.9 Mb) TX bytes:2804420 (2.6 Mb) Interrupt:11 Base address:0xd880 (boomerang below)) eth1 Link encap:Ethernet HWaddr 00:10:5A:14:8D:EE inet addr:192.168.1.103 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:1 txqueuelen:1000 RX bytes:2882 (2.8 Kb) TX bytes:684 (684.0 b) Interrupt:10 Base address:0xdc00 lo Link encap:Local Loopback UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3248 errors:0 dropped:0 overruns:0 frame:0 TX packets:3248 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2714648 (2.5 Mb) TX bytes:2714648 (2.5 Mb) I hope this helps. I can also post 2.6 messages if needed. Jim PCI: Found IRQ 11 for device 01:00.0 PCI: Sharing IRQ 11 with 00:02.0 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 01:00.0: 3Com PCI 3c905C Tornado at 0xd880. Vers LK1.1.18-ac 00:01:02:fa:69:f3, IRQ 11 product code 4552 rev 00.13 date 12-01-00 Internal config register is 1800000, transceivers 0xa. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. 01:00.0: scatter/gather enabled. h/w checksums enabled divert: allocating divert_blk for eth0 PCI: Found IRQ 10 for device 01:01.0 PCI: Sharing IRQ 10 with 00:1f.3 PCI: Sharing IRQ 10 with 00:1f.5 See Documentation/networking/vortex.txt 01:01.0: 3Com PCI 3c900 Cyclone 10Mbps TPO at 0xdc00. Vers LK1.1.18-ac 00:10:5a:14:8d:ee, IRQ 10 product code 504e rev 00.4 date 08-02-98 Internal config register is 1800000, transceivers 0x8. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 182d. Enabling bus-master transmits and whole-frame receives. 01:01.0: scatter/gather enabled. h/w checksums enabled divert: allocating divert_blk for eth1 divert: freeing divert_blk for eth0 divert: freeing divert_blk for eth1 ip_tables: (C) 2000-2002 Netfilter core team ip_conntrack version 2.1 (4087 buckets, 32696 max) - 292 bytes per conntrack PCI: Found IRQ 11 for device 01:00.0 PCI: Sharing IRQ 11 with 00:02.0 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 01:00.0: 3Com PCI 3c905C Tornado at 0xd880. Vers LK1.1.18-ac 00:01:02:fa:69:f3, IRQ 11 product code 4552 rev 00.13 date 12-01-00 Internal config register is 1800000, transceivers 0xa. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. 01:00.0: scatter/gather enabled. h/w checksums enabled divert: allocating divert_blk for eth0 PCI: Found IRQ 10 for device 01:01.0 PCI: Sharing IRQ 10 with 00:1f.3 PCI: Sharing IRQ 10 with 00:1f.5 See Documentation/networking/vortex.txt 01:01.0: 3Com PCI 3c900 Cyclone 10Mbps TPO at 0xdc00. Vers LK1.1.18-ac 00:10:5a:14:8d:ee, IRQ 10 product code 504e rev 00.4 date 08-02-98 Internal config register is 1000000, transceivers 0x8. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/10baseT interface. Enabling bus-master transmits and whole-frame receives. 01:01.0: scatter/gather enabled. h/w checksums enabled
I am a Red Hat 6.x, 7.x sysadm, Fedora newbie, working on my first install (I picked "Custom"): # rpm -qa|grep kernel kernel-2.4.22-1.2115.nptl kernel-pcmcia-cs-3.1.31-13 kernel-utils-2.4-9.1.101.fedora Networking seems to function fine (ping, ssh), but when I browse to default welcome page, I encounter on system console: eth0: Transmit error, Tx status register 82. Probably a duplex mismatch. See Documentation/networking/vortex.txt Flags; ... Transmit list ... 0: @c6b86200 length 8000005e ... ... In addition, /var/log/messages shows (my system time was off at this point): Dec 30 16:24:33 fedora kernel: eth0: Transmit error, Tx status register 82. I also noticed in ssl_error_log: [Tue Dec 30 11:23:05 2003] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? I found this bugzilla page and wanted to share my findings. I hope this helps. I tried the change /etc/sysconfig/init: GRAPHICAL=no (and reboot) with no effect. It seems like I have managed to get the error to go away with: * I commented out all of /etc/httpd/conf.d/welcome.conf * Corrected /etc/hosts FROM: 127.0.0.1 fedora localhost.localdomain localhost TO: 127.0.0.1 localhost.localdomain localhost 192.168.1.135 fedora
I apologize, the problem is still there. /var/log/messages: Dec 30 12:35:07 fedora kernel: eth0: Transmit error, Tx status register 82. Dec 30 12:35:07 fedora kernel: Probably a duplex mismatch. See Documentation/networking/vortex.txt Dec 30 12:35:07 fedora kernel: Flags; bus-master 1, dirty 4121(9) current 4121(9) Dec 30 12:35:07 fedora kernel: Transmit list 00000000 vs. c6ee5440. Dec 30 12:35:07 fedora kernel: 0: @c6ee5200 length 800005ea status 000105ea Dec 30 12:35:07 fedora kernel: 1: @c6ee5240 length 80000093 status 00010093 Dec 30 12:35:07 fedora kernel: 2: @c6ee5280 length 80000036 status 00010036 Dec 30 12:35:07 fedora kernel: 3: @c6ee52c0 length 800005ea status 000105ea Dec 30 12:35:07 fedora kernel: 4: @c6ee5300 length 800005ea status 000105ea Dec 30 12:35:07 fedora kernel: 5: @c6ee5340 length 800005ea status 000105ea Dec 30 12:35:07 fedora kernel: 6: @c6ee5380 length 800005ea status 000105ea Dec 30 12:35:07 fedora kernel: 7: @c6ee53c0 length 800005ea status 000105ea Dec 30 12:35:07 fedora kernel: 8: @c6ee5400 length 800005ea status 800105ea Dec 30 12:35:07 fedora kernel: 9: @c6ee5440 length 8000005e status 0001005e Dec 30 12:35:07 fedora kernel: 10: @c6ee5480 length 8000005e status 0001005e Dec 30 12:35:07 fedora kernel: 11: @c6ee54c0 length 8000005e status 0001005e Dec 30 12:35:07 fedora kernel: 12: @c6ee5500 length 800005ea status 000105ea Dec 30 12:35:07 fedora kernel: 13: @c6ee5540 length 800005ea status 000105ea Dec 30 12:35:07 fedora kernel: 14: @c6ee5580 length 800005ea status 000105ea Dec 30 12:35:07 fedora kernel: 15: @c6ee55c0 length 800005ea status 000105ea
Installing the 3c59x module in single-user solved the problem for me. I'm be interested to see what the final solution will be for this one :)
*** Bug 108473 has been marked as a duplicate of this bug. ***
Created attachment 97149 [details] 3c59x.o requires special parameters in Fedora Core 1 I have had the same problems with a recent upgrade from RH 9 to Fedora Core 1 with kernel-smp-2.4.22-1.2149.nptl. If I specify the parameters in the modules.conf, the NIC starts perfectly after reboot: alias eth1 3c59x debug=6 options=4 full_duplex=1 I am using debug=6 (very verbously) for diagnostics, but it also works with debug=1 or debug=0 I guess this bug has to do with the fact that the driver is not been able to auto negotiate the Ethernet Speed. Hope this helps out. Best regards, Ivan
*** Bug 114171 has been marked as a duplicate of this bug. ***
*** Bug 110337 has been marked as a duplicate of this bug. ***
*** Bug 113804 has been marked as a duplicate of this bug. ***
*** Bug 98832 has been marked as a duplicate of this bug. ***
I am having the same problem with Fedora Core 2 Test 1 and the 3Com 3c556B Hurricane CardBus (rev 20) card in my IBM Thinkpad laptop (A21m).
Hey, this isn't by any chance a duplicate of BZ 102685 is it? I saw the same issues and then some under a boomerang card with the RHEL3 driver, and chased the problem down to a macro that check the device config register. It appears that a) it doesn't mask off the right bits when checking for the phy type on the card, which causes the phy address data to get improperly populated. This in turn leads to strange/random behavior when trying to drive data over the mii interface, including the transmit problems described above. I've got a patch which appears to correct this behavior over in BZ 102685
It couldn't hurt to try that patch.
someone who understands the driver way better than i do should look carefully at that patch, especially the addition of the break. for instance: does SIOCGMIIPHY rely on falling through to the mdio_read? (i'm *guessing* the only necessary change is the one to XCVR.) kudos to neil horman for suggesting the connection of this to BZ 102685
*** Bug 118715 has been marked as a duplicate of this bug. ***
Not a kernel bug (probably). Tried my old kernel and booted Fedora on that. No difference. I moved the service to be started first, before microcode update, iptables and kudzu and whoa! it works. Independent of the used kernel. Something else messes the media selection up. Both machines worked fine on RH9 (!!!note again: same kernel!!!) Both machines are Athlons and have 3Com 905B-TX's. I also noticed that in the other machine it was enough to postpone the microcode update (at least so it seemed), but the other one wanted to start network first and foremost.
my experiences and a working 3c59x within a few minutes, FC1 out of the box, 3c900 combo boomerang, PCI, 10BaseT it seems that the 3c59x driver or the 3com-nic is only working if the module is loaded for the *first* time while booting why ? it is always the same behaviour under different kernels and OSs # modinfo -d 3c59x "3Com 3c59x/3c9xx ethernet driver LK1.1.18-ac 1 July 2002" # modinfo -V 3c59x modinfo (Linux modutils) 2.4.25 try it out. it is only working - if you disable kudzu - if you start the network-service before kudzu or iptables while booting (Sxxnetwork < Sxxkudzu) - you can `rmmod 3c59x` but you will not be able to `modprobe 3c59x` a second time succesfully - our rhl 7.3 dsl-router (3c59x -> dsl-modem) has similiar problems. if the dsl-modem is a short time disconnected (1 time per year) the 3c59x is completely confused, rebooting the router is the solution, kudzu is disabaled. - under knoppix 3.x this card is working because knoppix is loading this module while booting and *nothing else* if you try to rmmod and modprobe 3c59x a second time you will get the same errors --snip-- eth0: Transmit error, Tx status register d0. Flags; bus-master 1, dirty 1(1) current 1(1) [...] --snap--
Same problem for me under FC1. Hardware is a Sony VAIO PCG-XG29 laptop with 3C3FEM656C PCMCIA card. What's worse, under FC2 test2, running kudzu crashes the system with a blue screen and gibberish on it. Not even a readable kernel panic.
On Red Hat Enterprise WS Linux 3 Update 1 I am experiencing similar problems. The system is a Dell Latitude C600, supposedly a certified laptop. On bootup an error appears when trying to configure eth0. Fine. From the console, the following command is run: modprobe 3c59x which receives the following error: /lib/modules/2.4.21-9.EL/kernel/drivers/net/3c59x.o: init_module: No such drive Hint: insmod errors can be caused by incorrect module paramters, including invalid IO or IRQ parameters. /lib/modules/2.4.21-9.EL/kernel/drivers/net/3c59x.o: insmod /lib/modules/2.4.21-9.EL/kernel/drivers/net/3c59x.o failed /lib/modules/2.4.21-9.EL/kernel/drivers/net/3c59x.o: insmod 3c59x failed lspci -v returns Communication controller: 3Com Corporation Mini PCI 56K Winmodem Subsystem: 3Com Corporation: Unknown device 6137 Flags: medium devsel, IRQ 11 Setting the IRQ with modprobe doesn't work as it returns a warning about it. Not even Knoppix recognizes the modem, and it's been able to configure everything properly so far. I tried downloading the 3c59x.c file and compile it but my system doesn't have the pci-scan.h and kern_compat.h files despite having the kernel source on the system. And that's that.
I think I saw the same thing with an Intel PRO 100 card and the e100 driver. After coming across the same problem with a 3COM 3c905 card in a newly upgraded FC1 box I swapped in an Intel card. Never got any errors logged, but the interface did not work. Disabled kudzu and now the 3com card works for me. System is a dual processor Athon MP box, AMD-760/8 chipset.
I have '3Com Corporation 3c590 10BaseT [Vortex]' which works with all FC1 kernels, but with FC2t3 (have not tested others) I have VERY strange behaviour... When I boot the PC (AMD Athlon(tm) XP 2000+ with ECS K7S5Av1 MB) when eth1 (this card) is going up I have 20-30 seconds freeze (no keyboard, no mouse) and then regular freezes every 10-60 seconds for 5-20 seconds. When I shut this card (I have also 8139C as eth0) everything comes back to normal. If I remove the network cable and bring it back on - there's no problem even after plugging back the cable. In all the cases 'tcpdump -n -i eth1' sees nothing. mii-tool shows '10 Mbit, half duplex, link ok', but no packet travels in or out. The strangest part for me is that unpluging and pluging back the cable stops the freezes (but does not make it work)... This is really old card, but it always worked like a rock (and still does with FC1). I have nothing in /var/log/messages indicating problems. SELinux is running in permissive mode.
*** Bug 122928 has been marked as a duplicate of this bug. ***
I think the problem is between 3c59x.ko and ipv6.ko... My '3c590 10BaseT [Vortex]' did not work with FC2 too. Unplugging the cable did not help this time - I had to power off, unplug the cable and then boot. The installation worked fine (even with the 3c59x module loaded and the cable plugged in). After a few tests I renamed '/lib/modules/2.6.5-1.358/kernel/net/ipv6/ipv6.ko' to ipv6.ko.disabled (this was the only way not to have IPv6 with FC2t3) and after the reboot I'm filling this comment, so I guess it workes now :) .
Having been over the code there are some questions. Some code paths seem to stick the chip into D3 (power saving) state when the driver is loaded. If kudzu then asks for the media status the driver seems to forget to power the chip back up before asking. Follow the probe path then the ioctl path.
*** Bug 116095 has been marked as a duplicate of this bug. ***
*** Bug 121299 has been marked as a duplicate of this bug. ***
*** Bug 122091 has been marked as a duplicate of this bug. ***
*** Bug 122220 has been marked as a duplicate of this bug. ***
With regards to the observation that 122091 is a duplicate of this bug, I've never had any problems with my 3com cards on RH9 or FC1; only FC2 caused trouble.
I first experienced this with unupdated FC1 - same symptoms as subsequent kernel and kudzu versions.
please see my comment unter #102685, does it help to reconfigure your nic with 3c90xcfg.exe and disabling kudzu?
I was wrong, disabling ipv6 had nothing to do with this problem. Disabling kudzu however did really help.
Following someone else's instructions, I was able to get the card to work on Fedora Core 2 by inserting this line at the top of /etc/rc.sysinit: insmod /lib/modules/2.6.5-1.358/kernel/drivers/net/3c59x.ko It gives an error message on bootup, something to the effect of "file exists", but the card works afterwards.
We just repeated the work around of Comment #65 and got the same successful result! Thanks Kevin!
Is it the 3c59x driver or Kudzu that is responsible for this bug?
Driver. There's a potential kernel patch that may fix this.
You may want to try the FC2 test update kernel... this has the 3c59x patch integrated.
00:0b.0 Ethernet controller: 3Com Corporation 3c900B-TPO Etherlink XL [Cyclone] (rev 04) The 2.6.6-1.408 doesn't fix it for me. I might be experiencing bug 119965, though. Actually, I wouldn't be surprised if all 3c59x bugs were actually that one. :-)
Just tried #65 work around on dual athlon running 2.6.5-1.358smp. Solved the problem. System had worked fine with RH8 & 9.
I get this error in FC2. One workaround is to boot into runlevel 2, which brings up networking without kudzu. Then "init 5" to get the graphics. At the Grub prompt just type "a" for append and " 2" for runlevel 2. I don't know if runlevel 2 is meant to boot without kudzu. It is not mentioned in /etc/inittab, so perhaps kudzu is left out by mistake?
Same bug found when upgrading Dell Optiplex with integrated 3c59x card. Had to add line to /etc/rc.sysinit as specified in comment #65. Bug still appeared with kernel 2.6.6-1.427. Adding the line to /etc/rc.sysinit with new kernel version number again fixed the problem. Thanks for the help folks.
Just a comment that in comment #33, my NIC was working for the eth0 in my comments. Now, I'm getting the check cable error again. I'm not sure how long the NIC was not functional, but it displays the same error symptom as my prior rev A card displayed. It appears that the degeneration of the driver is increasing. I haven't tried comment #65 solution because I have a realtech card that I use to connect to my router, not the 3com rev B card. After servicing another computer, which required me to unhook the wiring for this machine, to test the other machine, rehooking up the computer again brought 3COM card 2 to be broken, but was working previously. (In FC1)
I tried getting the 3com to work in rawhide and it came up alright. With FC2, it seems that the 3com rev b is working. The broken Ethernet card was the realtech card. All interfaces work in the current rawhide mix. Just to correct my misdiagnosis.
Any plans for a RHEL 3 fix as well ?
*** Bug 131749 has been marked as a duplicate of this bug. ***
I also found turning kudzu off fixed the problem. My configuration is an Intel 440BX M'board 400MHz Pentium II with 3C905 NIC. Same logs as #3. Turning off kudzu fixed the problem. Appreciate the info on this page.
I have '3Com Corporation 3c590 10BaseT [Vortex]' and with FC3t2 have no problems - kernel 2.6.8-1.541 (I gave up with, so I installed FC3t2 now). Time to close this?
Is kudzu running and no special scripts need editing?
Fresh FC3t2 install (not upgrade) and the network worked just fine (still working). For comment #79 - I wanted to say 'I gave up to use FC2 on my home PC' (I must have been sleeping).
Closing as RAWHIDE, then.
Does anyone know which package/configuration/whatever it is that make this magic happen? Because it certainly does not work on my mainly FC2 installation running kernel-smp-2.6.8-1.541 with a 3Com Corporation 3c905 100BaseTX [Boomerang]
I ditched my Boomerang back when FC1 was in testing phase. Are you getting the "check cable" error or is it not recognized? Previously, it worked throughout the release of RHL 5.2 to RHL10, which ended up as FC1. You probably ought to open up a new bug regarding the Boomerang being ill affected. The vortex seems to be fixed.
One note: I guess the next version is said to work according to the reporter for the vortex. This means the test version is where the problem ceases. FC2 still has the problem. FC3T2 seems to work correctly.
Created bug 134428 for my bomerang problem.
There seems to be a lot of instances that relate to this bug. Some of them seem to indicate that the bug is still going strong with the later builds, like FC32. I think that bugzilla needs to be able to specify drivers that are contained within the kernel, in order to narrow down problems specific to certain hardware.
(This appears to be related to more closely Bugzilla report 81422, but more relevant info is found in this report, and this report is referenced by http://fedorafaq.org/fc2/#3c905 -- "My 3com network card doesn't work!") I have been using RedHat 7.3 on an IBM Thinkpad A21m for several years without any issues. I decided it was time to upgrade, so I loaded FC2. However, the laptop's NIC appeared to be unsupported. Here are the specifics: > lspci -v > 00:03.0 Ethernet controller: 3Com Corporation 3c556B CardBus [Tornado] (rev 20) > Subsystem: 3Com Corporation: Unknown device 6356 > Flags: bus master, medium devsel, latency 64, IRQ 11 > I/O ports at 1800 > [virtual] Memory at f4101400 (32-bit, non-prefetchable) [size=128] > [virtual] Memory at f4101000 (32-bit, non-prefetchable) [size=128] > Capabilities: [50] Power Management version 2 > > 00:03.1 Communication controller: 3Com Corporation Mini PCI 56k Winmodem (rev 20) > Subsystem: 3Com Corporation: Unknown device 6159 > Flags: medium devsel, IRQ 11 > I/O ports at 2000 > Memory at f4101c00 (32-bit, non-prefetchable) [size=256] > Memory at f4101800 (32-bit, non-prefetchable) [size=128] > Capabilities: [50] Power Management version 2 > ip -o link show eth0 > 4: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000\ link/ether ff:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff Even with the latest FC2 kernel (2.6.9-1.6_FC2) and patches for the 3c59x driver, it still did not work. I found and entry on the SuSE mailing list that indicated that ACPI appears to be broken on the 3c556B NIC (and many other 3Com NICs), and that turning off acpi in the kernel will fix the problem. I tried this fix on the FC2 kernel bu adding "acpi=off" (no quotes) to the kernel entry in grub.conf, rebooted, and all now appears to be fat, dumb, and happy. The bottom line seems to be that a MAC of "ff:ff:ff:ff:ff:ff" on a NIC that lspci recognizes is probably a good indication that ACPI is probably broken on that NIC, and the fix is to turn off ACPI in the kernel. (Perhaps a kludge could be added to the 3c59x driver to turn off acpi for that device whenever it detects a MAC of all FFs.
I should add to my previous comment that turning off kudzu did nothing to fix the problem. The problem was 100% reproducable in single user mode when manually configuring and enabling the interface w/o the help of kudzu or any other tool/script.
*** Bug 147079 has been marked as a duplicate of this bug. ***