The same problem with kernel-2.4.21-1.1931.2.399.ent.

The same problem with kernel-2.4.21-1.1931.2.411.ent.

The driver in the kernel looks to be pretty old, or at least the starting point
is much older than the latest version. I see this in the source tree:

/* EtherLinkXL.c: A 3Com EtherLink PCI III/XL ethernet driver for linux. */
/*
        Written 1996-1999 by Donald Becker.

and on ftp://ftp.scyld.com/pub/network/3c59x.c, it is newer:

/* EtherLinkXL.c: A 3Com EtherLink PCI III/XL ethernet driver for linux. */
/*
	Written 1996-2003 by Donald Becker.


Not sure this would change things though.

The same problem with:
kernel-2.4.21-1.1931.2.411.ent
kernel-2.4.21-1.1931.2.423.ent
kernel-2.4.21-2.EL
kernel-2.4.21-3.EL

The same problem in RHEL 3.0 ES with kernel-2.4.21-4.EL.
And I also see the Problem in Fedora Core Beta3.

This bug was not fixed with the currentrelease of RHEL 3.0 ES.

Created attachment 95768 [details]
3Com messages and config files

I have tested 3c905 (Boomerang), 3c905B (Cyclon) and 3c905C (Tornado)
cards.

All cards works on network installation correct. The kernel-BOOT is
generated from the same source like the running kernel (i686). So I do
not understand why not in running kernel.

3c509 (3Com PCI 3c905 Boomerang 100baseTx at 0xa800. Vers LK1.1.18-ac)

00:0a.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xa800. Vers LK1.1.18-ac
 00:60:08:2c:d2:1e, IRQ 10
  product code 4b4b rev 00.0 date 11-15-96
  Internal config register is 102001b, transceivers 0xe040.
  64K word-wide RAM 1:1 Rx:Tx split, autoselect/10baseT interface.
  Enabling bus-master transmits and whole-frame receives.
00:0a.0: scatter/gather enabled. h/w checksums disabled
divert: allocating divert_blk for eth1
eth1: Dropping NETIF_F_SG since no checksum feature.
ip_tables: (C) 2000-2002 Netfilter core team
eth0: Transmit error, Tx status register d0.
  Flags; bus-master 1, dirty 1(1) current 1(1)
  Transmit list 00000000 vs. c2dd1240.
  0: @c2dd1200  length 8000002a status 8000002a
  1: @c2dd1240  length 00000000 status 00000000
  2: @c2dd1280  length 00000000 status 00000000
  3: @c2dd12c0  length 00000000 status 00000000
  4: @c2dd1300  length 00000000 status 00000000
  5: @c2dd1340  length 00000000 status 00000000
  6: @c2dd1380  length 00000000 status 00000000
  7: @c2dd13c0  length 00000000 status 00000000
  8: @c2dd1400  length 00000000 status 00000000
  9: @c2dd1440  length 00000000 status 00000000
  10: @c2dd1480  length 00000000 status 00000000
  11: @c2dd14c0  length 00000000 status 00000000
  12: @c2dd1500  length 00000000 status 00000000
  13: @c2dd1540  length 00000000 status 00000000
  14: @c2dd1580  length 00000000 status 00000000
  15: @c2dd15c0  length 00000000 status 00000000

Do not works! The interface is configured correct (ifconfig).

3c905B (3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24))

Do not works in 10MB HD mode.

3c905C (3Com Corporation|3c905C-TX/TX-M [Tornado])

Works correct in all modes.

Detail --> attachment 95768 [details]

I use kernel-2.4.21-4.0.1.EL.i686.rpm!

This is a Kudzu related problem with some of the 3com 905 based 
cards. Versions of Kudzu before 1.x are ok therefore Redhat 9 and the 
previous 2.1 Ent products are ok. If you turn of kudzu for the boot 
runlevel (chkconfig --level 345 kudzu off) and reboot; your nic will 
initialize fine and work. I downgraded kudzu to the RH 9 based 
version 0.99.x and the card is fine after booting (mind you 
downgrading dependency hell but I just went back up for testing). 
This has been a problem since Fedora test1 and in Fedora core 1 
release and in the Redhat AS and WS 3.0 line. Too bad it's not fixed 
yet. So currently just keep kudzu off at boot time unless you have 
added or changed hardware settings.

3c905 (Boomerang, build in 1996) and 3c905B (Cyclon, build in 1997)
works only correct if kudzu do not running at boot time.
The 3c905C (Tornado build in 1999) card do not have this problem!
I see the problem in RHEL Beta (this bugreport on 2003-08-19) and also
in Red Hat 9.093 ... Fedora test1, test2.

It is tragic that it is also a bug in final releases RHEL AS, ES, WS
and Fedora Core 1.

I have used the 3c905-TX cards with Red Hat 7.3 with no problems.  In
this case, the card is connected to a 10Mb DSL router.  I have not
tried it with 100base-T.

After installing RHEL 3.0 WS the card is no longer functional.  I
swapped in another 3c905-TX and it did not work either.  mii-tool
reported 100Mb full duplex and I was unable to get it to actually use
10Mb.  mii-tool was able to see link status change when I
unplugged/plugged network cable.

Replacing the card with a cheap RealTek RTL-8029 NIC solved the
problem, though I would rather not have to do this.

Following are example kernel messages:
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
00:04.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xec80. Vers LK1.1.18-ac
 00:60:97:b6:8f:db, IRQ 10
  product code 4848 rev 00.0 date 03-20-97
  8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
  MII transceiver found at address 24, status 786f.
  Enabling bus-master transmits and whole-frame receives.
00:04.0: scatter/gather enabled. h/w checksums disabled
eth1: Dropping NETIF_F_SG since no checksum feature.
eth1: Transmit error, Tx status register d0.
  Flags; bus-master 1, dirty 1(1) current 1(1)
  Transmit list 00000000 vs. e6021240.
  0: @e6021200  length 8000002a status 8000002a
  1: @e6021240  length 00000000 status 00000000
  2: @e6021280  length 00000000 status 00000000
  3: @e60212c0  length 00000000 status 00000000
  4: @e6021300  length 00000000 status 00000000
  5: @e6021340  length 00000000 status 00000000
  6: @e6021380  length 00000000 status 00000000
  7: @e60213c0  length 00000000 status 00000000
  8: @e6021400  length 00000000 status 00000000
  9: @e6021440  length 00000000 status 00000000
  10: @e6021480  length 00000000 status 00000000
  11: @e60214c0  length 00000000 status 00000000
  12: @e6021500  length 00000000 status 00000000
  13: @e6021540  length 00000000 status 00000000
  14: @e6021580  length 00000000 status 00000000
  15: @e60215c0  length 00000000 status 00000000

Created attachment 97278 [details]
Service Request Number 283194, output lspci -vv

See Service Request Number 283194

Is ther any progress being made on this? I have a RHEL box that will
not work with a 3c905 (boomerang) but works just fine with a
3c905B(cyclone). I would reallylike to be able to use the boomerang's
since we have a bunch of them and they used to work. 

Created attachment 98008 [details]
lspci -vv

here is another lspci to add to the list. This machine has 4 boomerangs and 1
cyclone in it. The boomerangs do not work, the cyclone works just fine. If the
actual errors from the logs would be useful let me know and I will attach them.

Created attachment 98374 [details]
patch to correct mii-tool behavior on 3c59x boomerang cards

Its not quite perfect, but I found a few coding errors, and according to the
docs the macro they were using to determine the presence of an MII interface
was off by a few bits.	I haven't had time to test the upstream version of the
driver, but I'm guessing its already fixed this stuff.	Until we move up a
revision or three, this patch seems to fix the described problems for as much
testing as I am able to do.

Is a recompiled kernel/module available for testing anywhere? I am
willing to test this if it needs testing.

No, nothing is available yet, but it patches cleanly into the
2.4.21-9.EL kernel source tree if you would like to try a test rebuild
yourself.  

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

thank you.  From what I could tell there is no dependency on issuing
any specific mdio read request when fetching the phy addresss via the
SIOCGMIIPHY ioctl.  I was concerned however, that since the reg_num
field isn't guaranteed to be set to anything valid on the SIOCGMIIPHY
ioctl, there was a chance in the fall through that the mii_read may
try to hit a non-existant register, or hit a read/clear register,
leading to potential problems down the road (a missed tx/rx complete
status, etc).  You are likely correct however, that the XCVR change is
the only  needed change.

Finally got around to testing the patch attached to this bug. It is
still no go with a boomerang. kudzu detected it but misconfigured it.
The system was seeing it as eth0 but kudzu only left a config file for
eth1. I copied ifcfg-eth1 to ifcfg-eth0, changed the device name in
the file and tried to bring up the interface. Since the interface is
set for dhcp it failed to come up. Setting a static ip allows it to
come up but I am unable to pass tcp traffic over it. One thing I did
notice is that in the logs ntpd loggs a message that it is
reestablishing connection to the ntp servers. I tried running ntpq and
seeing if it was really able to talk to the ntp servers but it does
not appear to be talking. There were no messages in the logs either.
Rebooting the machine gets kudzu to try to reconfigure the interfaces
again but still no joy. Rebooting a 3rd time and kudzu is happy to
leave the nic alone. Let me know what other info you need. I will be
happy to provide any info needed to t/s and fix this problem.

Apologies, I had thought I fixed the problem with the above patch, but
I was wrong as I did not sufficiently test.  The same result as the
patch can be achieved by setting the options=6 in the module options.
 Unfortunately in my current testing here, I found that forcing the
boomerand card to use the MII interface (so that mii-tool works
properly) results in occasional rx underrun errors accompanied by
strange pci bus status being reported in the DmaCtrl register.  I'm
still investigating.

Could it be that kudzu is reprogramming the nic by accident? My case:
I have a 3C900 Combo (Boomerang) card; there were no probs with rh9.
After  installing white box 3.0 via nfs (that part went through) the
first boot of WBEL ended with a system freeze after kudzu started.
Restarting again and disabling kudzu I had to reconfigure the card
with the dos utility 3c90xcfg.exe (autoconfigure did the job). After
booting again, the network is up like before.

I was surprised because I used a vanilla kernel 2.4.26 on rh9 and
wbel, but only on wbel I had the problem described here and in many
other lists.

to summarize: a quick fix for me was to reconfigure the nic with the
config program by 3com under dos and disabling kudzu (when I used the
debug options=6 I only got some messages like when the network link
was under load (eth0: vortex_error(), status=0xe081) but the link
stayed up)

Recently I was trying to upgrade from RH 7.3 to FC1. I've a similar  
problem because my 3c905B (Cyclone) doesn't work at all. I cleaned up 
entries of eth0 and eth1 next time at startup it was recognized then 
I disabled Kudzu and restarted the system again. Did someone got it 
working? if yes, can you please direct me to a location where I can 
find a step-by-step reference?

I've set on my FC2 server kudzu off and restarted but i'm still having
the same problems.

# uname -a
Linux master.softdev.nl 2.6.7 #3 Sat Jul 24 11:48:07 CEST 2004 i686
i686 i386 GNU/Linux

# mii-tool -v
eth0: 100 Mbit, full duplex, link ok
  product info: vendor 00:10:5a, model 0 rev 0
  basic mode:   100 Mbit, full duplex
  basic status: link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
flow-control


#lspci -vv

02:04.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
(rev 78)
        Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC
Management NIC
        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 (2500ns min, 2500ns max), Cache Line Size 08
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at c000
        Region 1: Memory at e9000000 (32-bit, non-prefetchable) [size=128]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-

Created attachment 103956 [details]
3c59x-backport.patch

This is a backport from 2.4.28-rc2 upstream plus a few other changes from 2.6
upstream.  This seems to correct a lot of mii-related problems for me.	I'd
appreciate from feedback... :-)

I have opened bug 133388 to cover the "Transmit error, Tx status
register d0." problem.  I will use this bug to cover the mii-tool
problems w/ the 3c59x driver.

A fix for the final part of the problem has just been committed to the
RHEL3 U4 patch pool this evening (in kernel version 2.4.21-20.12.EL).

(Sorry, by "final part" in the last comment, I meant "mii-tool part".)

A minor regression introduced in kernel version 2.4.21-20.12.EL
was fixed with tonight's U4 commits for version 2.4.21-20.13.EL.

An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-550.html

kernel-2.4.21-27.EL in U4 do not contain the 3c59x-reset-u3.patch?

[root@pclin02 modules]# find . -name 3c59x.o -exec ls -l {} ;

own kernel with 3c59x-reset-u3.patch
-rwxr--r--    1 root     root        40064 24. Okt 15:25
./2.4.21-20.EL.3COM/kernel/drivers/net/3c59x.o

after rebuild the 2.4.21-27.EL SRPM because it does not work
-rwxr--r--    1 root     root        38536 23. Dez 06:06
./2.4.21-27.EL/kernel/drivers/net/3c59x.o

# lspci
02:0c.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
# lspci -v
02:0c.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
      Flags: bus master, medium devsel, latency 32, IRQ 9
      I/O ports at 9800 [size=64]
      Expansion ROM at <unassigned> [disabled] [size=64K]

With chkconfig kudzu on" at boot:

Dec 23 08:55:28 pclin02 kernel: eth1: Transmit error, Tx status
register d0.
Dec 23 08:55:28 pclin02 kernel:   Flags; bus-master 1, dirty 1(1)
current 1(1)
Dec 23 08:55:28 pclin02 kernel:   Transmit list 00000000 vs. dddea240.
Dec 23 08:55:28 pclin02 kernel:   0: @dddea200  length 8000002a status
8000002a
Dec 23 08:55:28 pclin02 kernel:   1: @dddea240  length 00000000 status
00000000
Dec 23 08:55:28 pclin02 kernel:   2: @dddea280  length 00000000 status
00000000
Dec 23 08:55:28 pclin02 kernel:   3: @dddea2c0  length 00000000 status
00000000
Dec 23 08:55:28 pclin02 kernel:   4: @dddea300  length 00000000 status
00000000
Dec 23 08:55:28 pclin02 kernel:   5: @dddea340  length 00000000 status
00000000
Dec 23 08:55:28 pclin02 kernel:   6: @dddea380  length 00000000 status
00000000
Dec 23 08:55:28 pclin02 kernel:   7: @dddea3c0  length 00000000 status
00000000
Dec 23 08:55:28 pclin02 kernel:   8: @dddea400  length 00000000 status
00000000
Dec 23 08:55:28 pclin02 kernel:   9: @dddea440  length 00000000 status
00000000
Dec 23 08:55:28 pclin02 kernel:   10: @dddea480  length 00000000
status 00000000
Dec 23 08:55:28 pclin02 kernel:   11: @dddea4c0  length 00000000
status 00000000
Dec 23 08:55:29 pclin02 kernel:   12: @dddea500  length 00000000
status 00000000
Dec 23 08:55:29 pclin02 kernel:   13: @dddea540  length 00000000
status 00000000
Dec 23 08:55:29 pclin02 kernel:   14: @dddea580  length 00000000
status 00000000
Dec 23 08:55:29 pclin02 kernel:   15: @dddea5c0  length 00000000
status 00000000

Same than my test with kernel- 2.4.21-25 .EL, see issue tracker 35612.
See also #133388.
This errata do not fix the problem with Boomerang card and "chkconfig
kudzu on" at boot time.

Please refer to comment 40 -- this bug no longer represents the
"Transmit error, Tx status register d0." problem.  That is corrected
by bug 133388 in the U5 release.