From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Description of problem: Following a successful installation of RHEL WS 3.0 on an Athlon XP 2100+ w/MSI motherboard and dual 3com 3c905-TX NICs, it failed to connect to Red Hat during firstboot. After cancelling and logging in as root, the system could see each of the NIC cards, but dmesg was full of PCI bus Error / Host Error messages. Pinging or any kind of network activity did not work, pinging would try to send a few packets and then produce the PCI bus error messages. I placed a Netgear FA311 card into the system, and downloaded vanilla kernel 2.4.22, recompiled and the NICs worked fine. However, the RedHat network scripts were fairly messed up, they kept trying to remap eth0 to eth2, and ended up calling one device (instead of eth2) dev025325. The installation was pretty hosed, so I removed both 3com 3c905-TX cards, and reinstalled with an Intel EEPRO and Netgear FA311, and it worked flawlessly. I retested with two other 3com 3c905-TX, the first test was with a Rev A and Rev B card, I tried it with two Rev.B cards (different cards) in a different system (Pentium III 800MHz Dell) and had the same results. It looks like either the driver in 2.4.21 is hosed, or something RHEL has patched into the kernel is interfering with the driver. It would be nice if Red Hat could fix this kernel issue, and provide new ISOs with an updated kernel so this can be cleanly installed on systems with 3c905-TX cards. Version-Release number of selected component (if applicable): kernel-2.4.21-4.EL How reproducible: Always Steps to Reproduce: 1.Install RHEL WS 3.0 on a system with two or more 3c905-TX cards 2.Boot up, and look in dmesg Actual Results: Received PCI bus errors (sorry don't have exact output, was in a rush to get the system back up and running). Expected Results: Ethernet / IP to work correctly Additional info: set severity to high as RHEL WS 3.0 fails to work on a system with a 3c905-TX card.
See bug #102685. Which card do you use? 3c905 (Boomerang) --> your report!? 3c905B (Cyclone) --> do not work on 10 MB hub, no 10HD 3c905C (Tornado) build in 1999 works correct in all modes by me
This is not related to 102685, both cards are connected to 10/100 ports on a Cisco Catalyst 5500 WS-X5225R blade. The ports were both running at 100 base. The system had : 3c905 (boomerang - REV A card) 3c905b (cyclone - REV B card) There was no network functionality available.
3c905: no network functionality available, see your messages file 3c905b: no 10Mbit HD on 10 MB hub, on 10/100 switch 100 Mbit FD is ok mii-tool -v means, this card do not know 10 MB [root@pclin02 root]# mii-tool -v eth0: 10 Mbit, full duplex, link ok product info: vendor 01:e1:c1, model 56 rev 7 basic mode: isolate, collision test, 10 Mbit, full duplex basic status: autonegotiation restarted, link ok capabilities: advertising: 100baseT4 100baseTx-FD 100baseTx-HD flow-control link partner: 100baseT4 100baseTx-FD 100baseTx-HD flow-control No MII transceiver present!. Sorry, the card works with 100baseTx-FD at this time. I use autonegotiation on switches because the FS108 (Netgear) or AT-FS716 (Allied Telesyn) are not user-managed switches.
See my messages file, thats helpful. I have already FIXED this problem, I'm trying to help you out, because I like Red Hat. Right now if someone has a 3com 3c905a/b card in their system, Red Hat Enterprise Linux is unusable!! This is very odd, because the problem ONLY exists with Red Hat Enterprise Linux. The system was working fine, running the same kernel version with Mandrake Linux 9.2rc2, and later Mandrake Linux 9.2. The problem ONLY occurs with Red Hat Linux Enterprise WS 3.0. To prove this point, I have a second system (same CPU, memory, motherboard, and installed the same NICs, which were removed from the original system). The original system works fine, with other NIC cards in it. I installed RHEL WS 3.0 on the secondary system, again it did the same thing. If for example, I try to ping out eth0 (3c905), it would send 5-10 packets, you'd see nothing come out the NIC card, and the ping tool would report destination host unreachable. After 10 packets, the console would display a PCI bus error. I removed the 3c905, and installed another one, to make sure it wasn't the card. Problem still occured. I removed the 3c905b, and placed another one in, same problem. Next, I took another Enterprise Linux product, and installed it. It worked fine, both NICs, no problems. I tried 3 different versions of this other product, 0.1.4 (which ran 2.4.21), 0.2.0 (which ran 2.4.22) and 0.3.2 (which runs 2.6.0-test9). They all worked without any problems. I reinstalled RHEL WS 3.0 on the system, put a third NIC (netgear) into it. Downloaded 2.4.22 kernel source, rebuilt the kernel, and it worked fine.
I have the same problem with Fedora core (test 1- release) and my 3c905 Boomerang card which had no probs with RH 7-9. The problem appears to be with Kudzu vers above 0.99 (after RH9). If Kudzu is off at boot time for the runlevel the cards initialize ok. When I downgraded Kudzu to the RH9 version (0.99) the NIC initialized ok without problems.
See also bug # 107389 and the effect of kudzu at boot time https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107389 . Looks like the same problem to me. Try turning off Kudzu at boot time with chkconfig and see what happens. Also since I am not using Ent. WS V3 what version of Kudzu is used with that OS?
Dan, kudzu-1.1.21-1 is whats on Ent. WS v3. The error message posted in #107389, is one of two messages I saw. Have you seen one about the PCI bus ? I would get both if I made any ping attempts. *** This bug has been marked as a duplicate of 107389 ***
Without kudzu at boot time the 3c905 (Boomerang) works correct. I tested it with RHEL WS 3. I think, there will be the same result in RHEL ES 3 (the same RPM for kudzu) and also the same result with 3c905b (Cyclone). But let me test it.
3c905 (Boomerang) and 3c905B (Cyclone) works correct with RHEL ES 3 if kudzu is not running at boot time.
there may be a patch in BZ 102685 tht fixes this
There appears to be a bug with the network driver that only affects certain revisions of these cards. I'll try to get hold of the specific cards and post the details here.
As promised, this what dmesg showed for one of these cards: 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 00:10.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xe880. Vers LK1.1.18-ac 00:10:5a:40:94:bf, IRQ 9 product code 5152 rev 00.12 date 08-30-98 Full duplex capable Internal config register is 2400000, transceivers 0xa. 8K byte-wide RAM 5:3 Rx:Tx split, 100baseTX interface. MII transceiver found at address 24, status 784d. Enabling bus-master transmits and whole-frame receives. 00:10.0: scatter/gather enabled. h/w checksums enabled divert: allocating divert_blk for eth0 divert: freeing divert_blk for eth0 ip_tables: (C) 2000-2002 Netfilter core team ip_conntrack version 2.1 (1024 buckets, 8192 max) - 304 bytes per conntrack 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 00:10.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xe880. Vers LK1.1.18-ac 00:10:5a:40:94:bf, IRQ 9 product code 5152 rev 00.12 date 08-30-98 Full duplex capable Internal config register is 1000000, transceivers 0xa. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/10baseT interface. MII transceiver found at address 24, status 7849. Enabling bus-master transmits and whole-frame receives. 00:10.0: scatter/gather enabled. h/w checksums enabled The same card is detected twice. This didn't work with the current latest kernel (2.4.21-27.0.4), but swapping it with another card did. I can do more testing or even post the card to someone if that helps.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.