Bug 102685 - (IT_28829_32937_39133) RHEL3_U4 (NET 3C59X) 3c905B, 3c905 does not work correct on 10 MB HUB
RHEL3_U4 (NET 3C59X) 3c905B, 3c905 does not work correct on 10 MB HUB
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
high Severity high
: ---
: ---
Assigned To: John W. Linville
:
Depends On:
Blocks: 123574
  Show dependency treegraph
 
Reported: 2003-08-19 16:37 EDT by Uwe Beck
Modified: 2008-03-19 06:00 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-23 09:39:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
3Com messages and config files (7.23 KB, text/plain)
2003-11-06 13:25 EST, Uwe Beck
no flags Details
Service Request Number 283194, output lspci -vv (1.81 KB, text/plain)
2004-01-27 10:06 EST, Uwe Beck
no flags Details
lspci -vv (8.41 KB, text/plain)
2004-02-24 14:13 EST, Tom Diehl
no flags Details
patch to correct mii-tool behavior on 3c59x boomerang cards (2.64 KB, text/plain)
2004-03-08 12:16 EST, Neil Horman
no flags Details
3c59x-backport.patch (7.05 KB, patch)
2004-09-17 13:15 EDT, John W. Linville
no flags Details | Diff

  None (edit)
Description Uwe Beck 2003-08-19 16:37:21 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [de] (X11; U; Linux 2.4.21-1.1931.2.393.ent i686)

Description of problem:
I uses the 3c905B and 3c905 cards. If this cards are connected to a 10 MB HUB
the performence over the network is very slow, especially extrem for tcp
conections. Here is an example for ftp:

ftp pclin01 (pclin01 can be a RS6000 with AIX4.3.3 or AIX51L)
Connected to pclin01.
220 pclin01 FTP server (Version 4.1 Sat Sep 7 14:31:53 CDT 2002) ready.
ftp> put openssh-3.6.1p2.tar.gz
local: openssh-3.6.1p2.tar.gz remote: openssh-3.6.1p2.tar.gz
227 Entering Passive Mode (128,0,5,9,128,30)
150 Opening data connection for openssh-3.6.1p2.tar.gz.
226 Transfer complete.
879629 bytes sent in 13 seconds (67 Kbytes/s)
ftp> get openssh-3.6.1p2.tar.gz openssh-3.6.1p2.tar.gz.
local: openssh-3.6.1p2.tar.gz. remote: openssh-3.6.1p2.tar.gz
227 Entering Passive Mode (128,0,5,9,128,31)
150 Opening data connection for openssh-3.6.1p2.tar.gz (879629 bytes).
netin: Connection reset by peer
421 Service not available, remote server has closed connection
ftp>

FTP get breaks. It looks like a missing or false autonegotiation problem.

# mii-tool
eth0: 10 Mbit, full duplex, link ok
  No MII transceiver present!.

# 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!.

The 10MB HUB only knows half duplex! mii-tool -v means, that the 3c59x module
does not knows 10 MB modes.

If the 3c905B, 3c905 cards connected to a 10/100 MB switch then tcp works fine.
But #mii-tool means also
# mii-tool
eth0: 10 Mbit, full duplex, link ok
  No MII transceiver present!.

# 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!.

#lspci
02:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev
24)
02:0c.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]

#lspci -v
02:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev
24)
        Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
        Flags: bus master, medium devsel, latency 32, IRQ 10
        I/O ports at a000 [size=128]
        Memory at d5000000 (32-bit, non-prefetchable) [size=128]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [dc] Power Management version 1

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]

I am not able to change the mode to 10baseT-HD with mii-tool.

I see the same problem in "severn"
No Red Hat version before have this problem. Here are the mii-tool output from
Red Hat 9:

# mii-tool
eth0: no autonegotiation, 10baseT-HD, link ok
eth1: no autonegotiation, 10baseT-HD, link ok
# mii-tool -v
eth0: no autonegotiation, 10baseT-HD, link ok
  product info: vendor 00:00:00, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  link partner: 10baseT-HD
eth1: no autonegotiation, 10baseT-HD, link ok
  product info: National DP83840A rev 1
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  link partner: 10baseT-HD

In both cases I use the same hardware.
HUB types: CentreCOM MR820TR and/or 3Com SuperStack II PS Hub 40.


Version-Release number of selected component (if applicable):
kernel-2.4.21-1.1931.2.393.ent and older

How reproducible:
Always

Steps to Reproduce:
1. Connect 3c905B or 3c905 to a 10 MB HUB
2. Use TCP
3.
    

Actual Results:  unable to use TCP-connections because very slow or breaks

Expected Results:  full performance/speed for 10 MB and 100 MB connections

Additional info:
Comment 1 Uwe Beck 2003-08-24 17:19:13 EDT
The same problem with kernel-2.4.21-1.1931.2.399.ent.
Comment 2 Uwe Beck 2003-08-29 07:41:25 EDT
The same problem with kernel-2.4.21-1.1931.2.411.ent.
Comment 3 Eric Hagberg 2003-09-08 14:05:26 EDT
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.
Comment 4 Uwe Beck 2003-09-22 17:47:02 EDT
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
Comment 5 Uwe Beck 2003-10-26 17:45:23 EST
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.
Comment 6 Uwe Beck 2003-10-26 17:50:08 EST
This bug was not fixed with the currentrelease of RHEL 3.0 ES.
Comment 7 Uwe Beck 2003-11-06 13:25:01 EST
Created attachment 95768 [details]
3Com messages and config files
Comment 8 Uwe Beck 2003-11-06 13:42:24 EST
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!
Comment 9 Dan Gennidakis 2003-11-11 23:55:31 EST
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.
Comment 10 Uwe Beck 2003-11-12 04:49:21 EST
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.
Comment 11 Larry Fahnoe 2003-11-19 13:34:01 EST
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
Comment 12 Uwe Beck 2004-01-27 10:06:20 EST
Created attachment 97278 [details]
Service Request Number 283194, output lspci -vv

See Service Request Number 283194
Comment 13 Tom Diehl 2004-02-24 14:10:02 EST
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. 
Comment 14 Tom Diehl 2004-02-24 14:13:57 EST
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.
Comment 15 Neil Horman 2004-03-08 12:16:47 EST
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.
Comment 16 Tom Diehl 2004-03-08 13:29:24 EST
Is a recompiled kernel/module available for testing anywhere? I am
willing to test this if it needs testing.
Comment 17 Neil Horman 2004-03-08 14:47:25 EST
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.  
Comment 18 Peter E. Popovich 2004-03-09 14:35:36 EST
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
Comment 19 Neil Horman 2004-03-09 14:41:06 EST
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.
Comment 20 Tom Diehl 2004-03-16 23:04:46 EST
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.
Comment 21 Neil Horman 2004-03-29 07:23:48 EST
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.
Comment 26 Andreas J. Bathe 2004-05-24 06:51:17 EDT
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)
Comment 27 Bhaskar Roy 2004-06-21 09:37:21 EDT
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?
Comment 28 Richard Pijnenburg 2004-07-29 06:33:26 EDT
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-
Comment 34 John W. Linville 2004-09-17 13:15:42 EDT
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... :-)
Comment 40 John W. Linville 2004-09-23 13:51:50 EDT
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.
Comment 41 Ernie Petrides 2004-09-28 04:48:15 EDT
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).
Comment 42 Ernie Petrides 2004-09-28 04:50:31 EDT
(Sorry, by "final part" in the last comment, I meant "mii-tool part".)
Comment 46 Ernie Petrides 2004-09-29 06:35:37 EDT
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.
Comment 47 John Flanagan 2004-12-20 15:54:41 EST
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
Comment 48 Uwe Beck 2004-12-23 03:34:34 EST
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.

Comment 49 John W. Linville 2004-12-23 09:39:18 EST
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.

Note You need to log in before you can comment on or make changes to this bug.