Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 119965
Summary: | (NET 3C59X MII) 3c90x MII is wrong preventing driver use | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | jeroen <jeroen> | ||||||
Component: | kernel | Assignee: | John W. Linville <linville> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||
Severity: | high | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | 3 | CC: | alan, anvil, barryn, chris.ricker, cs-spencer, dgunchev, djuran, fedora, jaakanshorter, jaboutboul, linville, marius.andreiana, mattdm, pmoore, wtogami | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | i386 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2005-05-23 12:23:10 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 114963, 123268, 136451 | ||||||||
Attachments: |
|
Description
jeroen
2004-04-04 08:47:30 UTC
ditto here on kernels for 3c905 on fedora core 2 test 2 (updated to kernel 2.6.4-1.305 *** Bug 118328 has been marked as a duplicate of this bug. *** one other note - the anaconda kernel will boot just fine. Like said in Bug 118328 this could be a driver problem which prevent mii-tool/ethtool to work correctly. And since ifup ask for a link to be plugged into the NIC before bringing up the interface, ifup will simply fail. Anaconda just doesnt check the link with mii-tool/ethtool i suppose. yah - it's just 4 lines in ifup - but the odd part if that mii-tool says it's 10mb halfduplex when it's clearly not and ethtool doesn't believe it exists. :) Did this work with previous kernels? 2.4.22 fc1 kernels are fine with me. But it *never* worked with all 2.6 kernel i've ever tested. I started running 2.6 kernel with some 2.6.0-testX kernel from arjan personal repository. I'm having the same problem with onboard 3com ethernet on a Dell OptiPlex GXa. It's a Pentium III 333Mhz, with 196mb ram. I did a 'dmesg' and got the following: 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 0000:00:11.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xdc80. Vers LK1.1.19 ***INVALID CHECKSUM 003e*** <7>divert: allocating divert_blk for eth0 eth0: Droping NETIF_F_SG since no checksum feature. eth0: Host error, FIFO diagnostic register 2000. eth0: PCI bus error, bus status 00a00029 Badness in local_bh_enable at kernel softirq.c:136 Call Trace: [<0212b43c>] local_bh_enable+0x39/0x56 [<0e940ba9>] mdio_read+0x1b1/0x1ce [3c59x] [<0e93e012>] vortex_up+0x2d3/0x6a2 [3c59x] [<0e93edb9>] vortex_error+0x1fb/0x2a2 [3c59x] [<0e93f9ea>] boomerang_interrupt+0x2c5/0x410 [3c59x] [<0210f19e>] handle_IRQ_event+0x21/0x41 [<0210f68a>] do_IRQ+0x1be/0x303 ======================== [<0e93e3c4>] vortex_up+0x685/0x6a2 [3c59x] [<0e93e52b>] vortex_open+0x14a/0x17c [3c59x] [<02271610>] dev_open+0x5f/0xcc [<022729f9>] dev_change_flags+0x48/0xee [<022ab3b4>] devinet_ioctl+0x255/0x4a1 [<022ace89>] inet_ioctl+0x69/0x9b [<0226b07c>] sock_ioctl+0x2d7/0x38d [<0226b4c7>] sys_socket+0x2a/0x3d [<0217c1cb>] sys_ioctl+0x2a0/0x341 eth0: Transmit error, Tx status register 90. Flags; bus-master 1, dirty 1(1) current 1(1) Transmit list 00000000 vs. 059a2a0. 0: @0595a200 length 8000005a status 8000005a 1: @0595a2a0 length 00000000 status 00000000 2: @0595a340 length 00000000 status 00000000 3: @0595a3e0 length 00000000 status 00000000 4: @0595a480 length 00000000 status 00000000 5: @0595a520 length 00000000 status 00000000 6: @0595a5c0 length 00000000 status 00000000 7: @0595a660 length 00000000 status 00000000 8: @0595a700 length 00000000 status 00000000 9: @0595a7a0 length 00000000 status 00000000 10: @0595a840 length 00000000 status 00000000 11: @0595a8e0 length 00000000 status 00000000 12: @0595a980 length 00000000 status 000000001 13: @0595aa20 length 00000000 status 00000000 14: @0595aac0 length 00000000 status 00000000 15: @0595ab60 length 00000000 status 00000000 eth0: no IPv6 routers present It appears turning kudzu off at boot fixed the 3com 3c905 Bommerange problem for me. Brandon Petersen I tried that here, no change. my kernel does freak out - it's just not detecting a link. FWIW, bug still present in kernel 2.6.5-1.327smp (stock fc2t3). The whole installation process went fine except this detail. I had to patch network-functions to ignore mii-tool/ethtool link non-detection. <aol> me too </aol> same here on fc2t3 What sort of love does this need? *** Bug 119376 has been marked as a duplicate of this bug. *** heh.. does this information help ? [root@gruyere ~]# lspci|grep -i 3com 02:06.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 30) [root@gruyere ~]# mii-tool eth0: 10 Mbit, half duplex, no link [root@confiote /etc/mail]# lspci|grep -i 3com 00:08.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) [root@confiote /etc/mail]# mii-tool eth0 eth0: negotiated 100baseTx-FD flow-control, link ok so, rev 30 -> bad. rev 78 -> Good. so, just to check - any status change on this? I know it's too late for the release now but this problem is going to hit a bunch of people. Present in FC2 , just installed it. Installation over network went fine, configured a static IP to the card(a Bommerange). Booting up after installation the interface seems ok, but nothing ever gets on the wire. Log shows eth0: Transmit error, Tx status register 90. Flags; bus-master 1, dirty 1(1) current 1(1) Transmit list 00000000 vs. 059a2a0. 0: @0595a200 length 8000005a status 8000005a I deleted eth0 in system-config-network and readded it, as well as disabled kudzu at boot. Not sure which one fixed it, bot no problems now. This problem is also in Core 1 2.4.22-1.2115 No it isnt. I've never encountered that in FC1. With any FC 2.4.x kernel. It is probably something else. I have to agree with Anvil - I've never seen this behavior on any 3c905 on a 2.4 kernel. I've seen some 2.4 reports and the patch I sent to Arjan would support the fact that 2.4 miht also get bitten could you post the patch here? I've just install FC2, I get no network, and I've got a 3c509 (boomerang). I tried the suggestion from the release notes (which is to do a "chmod -x /sbin/mii-tool"), and rebooted. This didn't help. I'm no expert - I don't know HOW to disable kudzu. What do I do next? Load a different distro of Linux? 3c509 or 3c905 ? If its a 906 then the easiest way to disable kudzu is to log in as the root user and "chkconfig kudzu off". Graphically you can use the system tools to do this also. just tried this with .406 from testing-updates and no change. still fails to detect a link via mii-tool so it balks on startup. However, performance is less crappy. Seth. Can you see what occurs if you do ifconfig eth0 up [wait 30 seconds] mii-tool for the link Alan no change. I did it twice - unloading the module in between. mii-tool still says 10mbit half duplex, no link. Sorry, my last entry was dyslexic - I meant 3c905, not 3c509. I haven't used an ISA network adapter in many years. I can confirm that disabling kudzu makes the 3c905 adapter work. With kudzu enabled, eth0 initialization fails. With kudzu disabled, it succeeds. In contrast, the workaround in the release notes (chmod -x /sbin/mii-tool) does not seem to have any effect at all. So, the obvious suggestion: could kudzu be leaving the network adapter in a funny state, such that it cannot properly initialize afterwords? I can confirm that the 3c509 problems are worked around by disabling Kudzu. Thanks Alan Disabling kudzu finally got my 3c905 [Boomerang] card to work, thank you. Loged in as root I can manually start kudzu and the card still works. The 3c905 [Tornado] card always works. Latest fc2 kernel (2.6.7-1.494.2.2) seems to have fixed the problem here.. Well, good for you... Unfortunatly I had no such luck with my card )-:
kernel-smp-2.6.7-1.494.2.2
kudzu-1.1.62-1
00:0b.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (750ns min, 2000ns max)
Interrupt: pin A routed to IRQ 17
Region 0: I/O ports at a800
RHEL ES 3 - kernel 2.4.21-15.EL, 2.4.21-15.0.4.EL Dell Latitude - 3c905C at 0xfc00 Vers LK1.1.18-ac Disabling Kudzu doesn't fix it. - No traffic at all on the lan during DHCP. - setting static ip address doesn't fix it either. Created attachment 102503 [details]
log of juggling PCI devices and kudzu's effects on 3c59x
It seems like kudzu, but not only does it have to be turned off, but the pci
devices need to be juggled in bios to get back into a healthy state.
- At least that seems to be the case if I only do warm reboots.
Why isn't the main network scripts "functions" updated to support a MII_DISABLED or similar type directive that can be set in the ifcfg-eth0 file?? This is what Mandrake linux does in there network-scripts. The problem still exists on kernel-smp-2.6.8-1.541 Could we change the Fedora version this bug is reported against apropriately? *** Bug 134428 has been marked as a duplicate of this bug. *** A patch has been submitted (and internally for the Fedora kernel) which should fix the "3c905 doesn't work w/ kudzu" problem. I'll attach the patch below -- it should apply (perhaps w/ some offsets) to any recent Fedora kernels as well. Created attachment 105201 [details]
3c59x-reset.patch
Proper reset of 3c905 devices at rmmod...
Will this be part of FC3 then? FC3 is pretty far along -- I doubt if it will make the first release. However, it might make an update... Sorry! I wish I had gotten it fixed sooner... Seems to work now with kernel-smp-2.6.9-1.681_FC3 and kudzu-1.1.95-1 (-: Is this still an issue for anyone? It has been sitting MODIFIED since November 2004 with no comments. Works fine for me (updated FC3 and FC4 test). Works on FC3 here. (didnt try FC4 Test yet) |