Bug 119965

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)