Bug 107389 - (3c59x-vs-kudzu) (3C59X) 3c59x + kudzu == boom
(3C59X) 3c59x + kudzu == boom
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
:
: 98832 107998 109547 109548 109703 110337 113804 114171 116095 118715 121299 122091 122220 122928 131749 147079 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-17 13:19 EDT by Dave Botsch
Modified: 2014-01-21 17:48 EST (History)
44 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-28 22:00:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
3c59x.o requires special parameters in Fedora Core 1 (128 bytes, text/plain)
2004-01-21 13:04 EST, Ivan Mirisola
no flags Details

  None (edit)
Description Dave Botsch 2003-10-17 13:19:02 EDT
Description of problem:
First off, this problem also existed in kernel-2.4.22-1.2061.

The following messages show up in /var/log/messages:

Oct 16 15:41:42 wirepub kernel: eth0: Transmit error, Tx status register 82.
Oct 16 15:41:42 wirepub kernel: Probably a duplex mismatch.  See
Documentation/networking/vortex.txt
Oct 16 15:41:42 wirepub kernel:   Flags; bus-master 1, dirty 21452(12) current
21453(13)
Oct 16 15:41:42 wirepub kernel:   Transmit list 00000000 vs. cb2cc500.
Oct 16 15:41:42 wirepub kernel: <gth 800005c6 status 000105c6
Oct 16 15:41:42 wirepub kernel:   2: @cb2cc280  length 800005c6 status 000105c6
Oct 16 15:41:42 wirepub kernel:   3: @cb2cc2c0  length 800005c6 status 000105c6
Oct 16 15:41:42 wirepub kernel:   4: @cb2cc300  length 800005c6 status 000105c6
Oct 16 15:41:43 wirepub kernel:   5: @cb2cc340  length 800005c6 status 000105c6
Oct 16 15:41:43 wirepub kernel:   6: @cb2cc380  length 800005c6 status 000105c6
Oct 16 15:41:43 wirepub kernel:   7: @cb2cc3c0  length 800005c6 status 000105c6
Oct 16 15:41:43 wirepub kernel:   8: @cb2cc400  length 800005c6 status 000105c6
Oct 16 15:41:43 wirepub kernel:   9: @cb2cc440  length 800005c6 status 000105c6
Oct 16 15:41:43 wirepub kernel:   10: @cb2cc480  length 800005c6 status 800005c6
Oct 16 15:41:43 wirepub kernel:   11: @cb2cc4c0  length 800005c6 status 000105c6
Oct 16 15:41:43 wirepub kernel:   12: @cb2cc500  length 800005c6 status 000105c6
Oct 16 15:41:43 wirepub kernel:   13: @cb2cc540  length 800005c6 status 000105c6
Oct 16 15:41:43 wirepub kernel:   14: @cb2cc580  length 800005c6 status 000105c6
Oct 16 15:41:43 wirepub kernel:   15: @cb2cc5c0  length 800005c6 status 000105c6


The HP switch port on our procurve 4108gl to which this computer is directly
connected shows the following errors:

W 10/17/03 11:58:02 FFI: port B11-Excessive CRC/alignment errors. See help.
W 10/17/03 11:58:23 FFI: port B11-Excessive CRC/alignment errors. See help.
W 10/17/03 11:58:44 FFI: port B11-Excessive CRC/alignment errors. See help.
W 10/17/03 12:04:52 FFI: port B11-Excessive undersized/giant packets. See help.
W 10/17/03 12:08:11 FFI: port B11-Excessive undersized/giant packets. See help.
W 10/17/03 12:47:13 FFI: port B11-Excessive undersized/giant packets. See help.
W 10/17/03 13:08:14 FFI: port B11-Excessive CRC/alignment errors. See help.
W 10/17/03 13:09:48 FFI: port B11-Excessive CRC/alignment errors. See help.


the hp switch port is running at 100FDx and set to auto-negotiate.

Compiling and using the 3c59x module from Donald Beckers' net-drivers package
fixes the problem.

Version-Release number of selected component (if applicable):

kernel-2.4.22-1.2088.nptl

How reproducible:
 Always

Steps to Reproduce:
1.Reinstall this computer with Fedora Core 3.
2.Do some network transfers
3.Watch the logs.

Actual results:
Erros as detailed above

Expected results:
No network errors.

Additional info:
# cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 7
model name      : Pentium III (Katmai)
stepping        : 3
cpu MHz         : 547.186
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse
bogomips        : 1091.17


lspci -v :

00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
	Subsystem: Dell Computer Corporation: Unknown device 0080
	Flags: bus master, medium devsel, latency 64
	Memory at ec000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [a0] AGP version 1.0

00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
(prog-if 00 [Normal decode])
	Flags: bus master, 66Mhz, medium devsel, latency 64
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	Memory behind bridge: fc000000-fdffffff
	Prefetchable memory behind bridge: f2000000-f5ffffff

00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
	Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80
[Master])
	Flags: bus master, medium devsel, latency 64
	I/O ports at ffa0 [size=16]

00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00
[UHCI])
	Flags: bus master, medium devsel, latency 64, IRQ 14
	I/O ports at dce0 [size=32]

00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
	Flags: medium devsel, IRQ 9

00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
	Subsystem: Dell Computer Corporation 3C905B Fast Etherlink XL 10/100
	Flags: bus master, medium devsel, latency 64, IRQ 14
	I/O ports at dc00 [size=128]
	Memory at fe000000 (32-bit, non-prefetchable) [size=128]
	Expansion ROM at f9000000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 1

00:13.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03)
(prog-if 00 [Normal decode])
	Flags: bus master, medium devsel, latency 64
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
	I/O behind bridge: 0000e000-0000efff
	Memory behind bridge: fa000000-fbffffff
	Prefetchable memory behind bridge: 00000000f1000000-00000000f1f00000
	Capabilities: [dc] Power Management version 1

01:00.0 VGA compatible controller: nVidia Corporation NV5 [RIVA TNT2/TNT2 Pro]
(rev 11) (prog-if 00 [VGA])
	Subsystem: Diamond Multimedia Systems RIVA TNT2/TNT2 Pro
	Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
	Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
	Memory at f4000000 (32-bit, prefetchable) [size=32M]
	Expansion ROM at 80000000 [disabled] [size=64K]
	Capabilities: [60] Power Management version 1
	Capabilities: [44] AGP version 2.0

02:0a.0 SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891/7890
	Subsystem: Dell Computer Corporation: Unknown device 0080
	Flags: bus master, medium devsel, latency 64, IRQ 10
	BIST result: 00
	I/O ports at ec00 [disabled] [size=256]
	Memory at fafff000 (64-bit, non-prefetchable) [size=4K]
	Expansion ROM at fb000000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 1

02:0e.0 SCSI storage controller: Adaptec AIC-7880U (rev 01)
	Subsystem: Adaptec AIC-7880P Ultra/Ultra Wide SCSI Chipset
	Flags: bus master, medium devsel, latency 64, IRQ 10
	I/O ports at e800 [disabled] [size=256]
	Memory at faffe000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at fb000000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 1
Comment 1 Ed Hill 2003-10-17 19:45:21 EDT
Hi, I'm seeing something that seems to be very similar.  I'm not able to 
get network communication to work and /var/log/messages is filled with:

Oct 17 15:45:11 eddy kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct 17 15:45:11 eddy kernel: eth0: transmit timed out, tx_status 00 status e000.
Oct 17 15:45:11 eddy kernel:   diagnostics: net 0cc0 media 8802 dma 00000000.
Oct 17 15:45:11 eddy kernel:   Flags; bus-master 1, dirty 1(1) current 17(1)
Oct 17 15:45:11 eddy kernel:   Transmit list 00000000 vs. c46dc240.
Oct 17 15:45:11 eddy kernel:   0: @c46dc200  length 8000002a status 8000002a
Oct 17 15:45:11 eddy kernel:   1: @c46dc240  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   2: @c46dc280  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   3: @c46dc2c0  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   4: @c46dc300  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   5: @c46dc340  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   6: @c46dc380  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   7: @c46dc3c0  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   8: @c46dc400  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   9: @c46dc440  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   10: @c46dc480  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   11: @c46dc4c0  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   12: @c46dc500  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   13: @c46dc540  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   14: @c46dc580  length 8000002a status 0000002a
Oct 17 15:45:11 eddy kernel:   15: @c46dc5c0  length 8000002a status 8000002a

The hardware is a Dell Dimension XPS D333 with the following:

00:00.0 Host bridge: Intel Corp. 440LX/EX - 82443LX/EX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corp. 440LX/EX - 82443LX/EX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 01)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:0d.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
00:0e.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 14)
00:0e.1 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 14)
01:00.0 Display controller: Texas Instruments TVP4020 [Permedia 2] (rev 01)

running a freshly installed fedora core:

  Fedora Core release 0.95 (Severn)

  kernel-2.4.22-1.2088.nptl
  kernel-utils-2.4-8.31

Is something fishy with the 3c9xx driver(s)?  I'll grab a spare NIC and 
see if I can at least get the networking up.  Please feel free to contact 
me if you'd like more hardware details.

Ed ==> eh3 at mit dot edu
Comment 2 Ed Hill 2003-10-18 11:14:07 EDT
I installed RH 9 on the same system and the 3c905 works without a hitch, 
so it seems likely that theres something wrong with the driver in Fedora 
Core release 0.95 (Severn).

I have a spare partition on the machine and will re-install Fedora Core 
as soon as the next update is available.
Comment 3 Ed Hill 2003-10-18 15:27:29 EDT
Hi again!

I now have the above Dell machine dual-booting RH9 and the latest Fedora Core 
with the upgraded kernel (kernel-2.4.22-1.2097.nptl.i686.rpm).  DHCP networking 
is just fine with RH 9.  Fedora Core fails to get the identical, simple DHCP 
networking running and returns:

  Determining IP information for eth0... failed.

with the following in /var/log/messages:

Oct 18 07:34:21 localhost login(pam_unix)[1916]: session opened for user root by
LOGIN(u
id=0)
Oct 18 07:34:22 localhost  -- root[1916]: ROOT LOGIN ON tty1
Oct 18 07:35:05 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port
67 inte
rval 3
Oct 18 07:35:05 localhost kernel: eth0: Transmit error, Tx status register d0.
Oct 18 07:35:05 localhost kernel:   Flags; bus-master 1, dirty 1(1) current 1(1)
Oct 18 07:35:05 localhost kernel:   Transmit list 00000000 vs. c48fd240.
Oct 18 07:35:05 localhost kernel:   0: @c48fd200  length 80000156 status 80000156
Oct 18 07:35:05 localhost kernel:   1: @c48fd240  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   2: @c48fd280  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   3: @c48fd2c0  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   4: @c48fd300  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   5: @c48fd340  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   6: @c48fd380  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   7: @c48fd3c0  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   8: @c48fd400  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   9: @c48fd440  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   10: @c48fd480  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   11: @c48fd4c0  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   12: @c48fd500  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   13: @c48fd540  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   14: @c48fd580  length 00000000 status 00000000
Oct 18 07:35:05 localhost kernel:   15: @c48fd5c0  length 00000000 status 00000000
Oct 18 07:35:08 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port
67 inte
rval 8
Oct 18 07:35:16 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port
67 inte
rval 12
Oct 18 07:38:35 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port
67 inte
rval 5
Oct 18 07:38:35 localhost kernel: eth0: Transmit error, Tx status register d0.
Oct 18 07:38:35 localhost kernel:   Flags; bus-master 1, dirty 1(1) current 1(1)
Oct 18 07:38:35 localhost kernel:   Transmit list 00000000 vs. c48fd240.
Oct 18 07:38:35 localhost kernel:   0: @c48fd200  length 80000156 status 80000156
Oct 18 07:38:35 localhost kernel:   1: @c48fd240  length 80000156 status 00000156
Oct 18 07:38:35 localhost kernel:   2: @c48fd280  length 80000156 status 80000156
Oct 18 07:38:35 localhost kernel:   3: @c48fd2c0  length 00000000 status 00000000
Oct 18 07:38:35 localhost kernel:   4: @c48fd300  length 00000000 status 00000000
Oct 18 07:38:35 localhost kernel:   5: @c48fd340  length 00000000 status 00000000
...

Oct 18 07:38:40 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port
67 inte
rval 9
...
Oct 18 07:41:23 localhost dhclient: No DHCPOFFERS received.


Both RH 9 and Fedora Core report the hardware as:

00:00.0 Host bridge: Intel Corp. 440LX/EX - 82443LX/EX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corp. 440LX/EX - 82443LX/EX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 01)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:0e.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 14)
00:10.1 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 14)
01:00.0 VGA compatible controller: Texas Instruments TVP4020 [Permedia 2] (rev 01)

Both RH 9 and Fedora Core are using the "3c59x.o" module.

Please don't hesitate to contact me if you'd like further info.
Comment 4 Miloš Komarčević 2003-10-18 16:01:21 EDT
I've had some (similar) problems with a PCMCIA 3c575 (also uses 3c59x.o module)
- see my bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106838

Problems also started with Severn, it worked flawlessly with 9 and before.
It also works for me without rhgb.

I haven't pinpointed the source of the problem yet (seems to be rhgb+kernel
related), but restarting the pcmcia service seems to bring the card back to life.

Can you try removing the 3c59x module and loading it again after the
system has booted up?
Comment 5 Stephen Drye 2003-10-20 11:50:13 EDT
I had the same problem.  The weird thing is that it went away when I disabled
the kudzu service.  I did nothing else.

It seems that something kudzu does during its probing makes a 3c905 very unhappy.

My setup is a Athlon XP 1900+, VIA KT333Pro (Asus A7V333 motherboard) with a PCI
3c905.
Comment 6 Tino Meinen 2003-10-25 00:27:54 EDT
I have a 3com 3c900B card requiring the 3c59x module.
I was not able to setup networking  (in FCtest3) untill I disabled the kudzu
service on bootup.
(I didn't use any updates from rawhide or elsewhere)
I still use the graphical bootup.
Everything works now wich is great.
Comment 7 Max Kanat-Alexander 2003-10-25 22:46:37 EDT
I had a somewhat similar problem, on my 3c905 Cyclone with kernel-2.4-20-20.9
and some rawhide upgrades. (My problem was probably kudzu, similar to the above
comment).

Replacing the normal network drivers with the latest netdrivers at
http://www.scyld.com/network/ fixed the problem for me without updating my
kernel or removing kudzu.

It's possible that my problem wasn't the same, but it's also possible that newer
netdrivers will fix this problem as well.

-M
Comment 8 Peter van Egdom 2003-10-27 11:48:00 EST
Just a 'me too' report.

On my Linux machine (a HP Vectra with a 3Com 3c905 onboard) I experience the
same problem as described here (problems with the 3c59x module). The PC is
running Fedora Core release 0.95 (Severn) without any updates from Rawhide.

Starting an X application (eg. Mozilla) on that machine on the display of
another PC (with 'export DISPLAY') takes a _long_ time before the output of
Mozilla displays.

Because communication (100 Mbit) on that network is realised with a hub, I
checked the network card speed with the command "mii-tool". It seems that the
3Com card in the PC with the troubles has 'auto-negotiated' itself on 10 Mbit.
Strange, because it is on a 100 MBit hub.

Then I, as suggested in comment #5, disabled kudzu in all runlevels and rebooted.

After the reboot "mii-tool" reported that it was running on 100 Mbit - as it should.

So, also for me the fix was in disabling Kudzu.
It seems Kudzu screws with the network card configuration somewhere.

If needed I can attach some specs and information about the machine with the
problem.
Comment 9 Torrey Hoffman 2003-10-31 13:22:38 EST
Another "me too" report.  System is a dual P3-800 with a 3Com Corporation 3c905
100BaseTX [Boomerang].  Running the latest Fedora Test kernel
(2.4.22-1.2111.nptlsmp) networking dies and the kernel log fills up with:
eth0: Transmit error, Tx status register 90.
  Flags; bus-master 1, dirty 1(1) current 17(1)
  Transmit list 1a8df280 vs. da8df240.
  0: @da8df200  length 8000002a status 8000002a
  1: @da8df240  length 8000002a status 0000002a
  2: @da8df280  length 8000002a status 0000002a
  3: @da8df2c0  length 8000002a status 0000002a
  4: @da8df300  length 8000002a status 0000002a
...

Running an unpatched 2.6.0-test9 kernel works perfectly.
Comment 10 Torrey Hoffman 2003-10-31 19:36:43 EST
This is still broken with 2.4.22-1.2115.nptlsmp...
Comment 11 Dan Gennidakis 2003-11-06 17:07:42 EST
Same problems with Fedora Core 1 release (yarrow). Using 2.4.22-
1.2115.nptl. I have to turn off Kudzu at the boot runlevel in order 
for my 3c905 to initialize properly. This is on an Asus P2b a very 
solid 440BX based board that worked without a hitch in Redhat 7.0-
9.0 and has no problem with other Distros. I will try a 2.6 series 
kernel and see what happens as well.
Comment 12 Dan Gennidakis 2003-11-06 17:38:03 EST
Using 2.6.0-0.test9.1.70 I can boot the system with Kudzu on at the
given runlevel (5) and eth0 (3c905) initializes and the network works
properly. One weird thing however when the system booted Kudzu started
 detected a hardware change and asked me to remove the config for eth0
which I did not (I optioned to keep the existing configuration).
Comment 13 Dan Gennidakis 2003-11-06 23:11:47 EST
I downgraded kudzu to the 0.99 version rpm from Redhat 9 with Fedora 
(yarrow) rebooted with kudzu on and eth0 initializes ok and the 
network works. As soon as I updated kudzu to the latest version from 
Fedora the 3c905 just hangs again when kudzu is on at the runlevel. 
the mii-tool also fails and outputs no MII found. When kudzu is off 
at boot time mii-tool shows that the 3c905 has negotiated 
100Mbitfull-duplex and the nic works.
Comment 14 John Buswell 2003-11-07 16:22:34 EST
*** Bug 107998 has been marked as a duplicate of this bug. ***
Comment 15 Bill Nottingham 2003-11-08 00:12:56 EST
Two things to try:

- run with kudzu enabled and the Red Hat Linux 9 errata kernel instead
 of the Fedora Core kernel

- boot without loading the driver. Turn off hotplug so the interface
doesn't automatically come up. Then load the module, run 'ethool -i
<interface>', run 'ifconfig', and then bring up the interface.
Comment 16 Jordan Russell 2003-11-09 15:51:42 EST
Bill: Downgrading to RHL9's 2.4.20-8 errata kernel had no effect for 
me. Still have no network connectivity as long as kudzu is enabled. 
(I'm getting the same errors as Ed Hill.)

I'd also like to add that this problem occurs independently of 
whether a Red Hat kernel is used. I experience the same problem when 
running an unpatched 2.4.22 kernel.

My config: Athlon, VIA KT133 chipset, 3C905-TX NIC
Comment 17 Jordan Russell 2003-11-09 16:03:29 EST
Also, I tried replacing the 3C905-TX card with a 3C980C-TXM card, and 
it works fine with kudzu (1.1.36-1) enabled. Both models use the same 
3c59x driver.
Comment 18 Bill Nottingham 2003-11-10 11:59:42 EST
*** Bug 109547 has been marked as a duplicate of this bug. ***
Comment 19 Bill Nottingham 2003-11-10 11:59:57 EST
*** Bug 109548 has been marked as a duplicate of this bug. ***
Comment 20 Bill Nottingham 2003-11-11 10:43:39 EST
*** Bug 109703 has been marked as a duplicate of this bug. ***
Comment 21 Andriy Rozeluk 2003-11-11 15:40:49 EST
Another "Me too"

I have an HP Vectra VE 6/350 with a 3c905 card and it experiences
exactly the same issue.

Fortunately the trick of disabling Kudzu solved the issue for me.
Comment 22 Keni Matsuda 2003-11-16 15:36:01 EST
An another workaround I discovered in Enterprise Linux 3.0 (Bug 107998
as a duplicate of this bug) is to explicitly insert 3c59x module
before kudzu.  I made a 'dirty' change in rc.sysinit to add
insmod 3c59x.  It fixed this problem as well.
Comment 23 Need Real Name 2003-11-17 11:46:37 EST
"An another workaround I discovered in Enterprise Linux 3.0 (Bug 107998
as a duplicate of this bug) is to explicitly insert 3c59x module
before kudzu.  I made a 'dirty' change in rc.sysinit to add
insmod 3c59x.  It fixed this problem as well."
can you explain this?
i don't understand what you mean...
Comment 24 Jim Cornette 2003-11-18 18:26:43 EST
Using a PCI version of the Vortex Boomerang NIC. I get a cable
unplugged error on bootup. This error started with Severn1 and I
assume that it is still a problem.
In my case, I could run dhclient from a root terminal and get a IP
address. There were then a lot of problems with mozzila, GNOME and
other problems.
I changed the NIC with a 3com Tornado and it works without problems.
I believe that the card was detected as a hurricane, instead of a
vortex Boomerang, like it should be identified as.
I have a bug that I entered previously with the cable unplugged
problem that I encountered, I could not locate it on Bugzilla though.
Comment 25 Andrew Gormanly 2003-11-19 11:05:43 EST
With a PCMCIA 3c575 (module 3c59x) in an old laptop I had no network,
and was getting these same error messages, but disabling rhgb as Milos
suggested above cured it for me.
Comment 26 Ulrich Seidl 2003-11-23 06:18:24 EST
Running 3c905B with the default settings (100MBit) it has a througput
of about 10k/s. I've encountered a very high carrier count. Whenn
running the card at 10MBit i get ~600k/s. Additionally when enabling
debug information (options 3c59x debug=3) in /etc/modules.conf I get
lots of:
eth0: vortex_error(), status=0xe081 (at 100MBit and at 10MBit). The
Card was running fine on RH 8.0.
Disabling Kudzu at startup does not solve the problem.
Comment 27 Max Kanat-Alexander 2003-11-23 18:07:04 EST
Is it possible that this has something to do with bug 75062 or bug
75813, both of which are still unresolved? Granted, one is for 8.0,
and another for 7.x, but it's possible that a change in FC1 exposed
these problems in a more significant fashion.

Also - does anybody know the exact version of kudzu at which this
starts happening? We know that it doesn't happen with 0.99, and that
it DOES happen with the most recent release, 1.1.36-1. Can we get any
more accurate than that?

-M
Comment 28 Jim Cornette 2003-11-23 21:50:57 EST
Some other bug that deals with a pci devices bug mentioned to change
the below. Ths comment was from the fedora mailing list for the
distribution.

Try changing the line to say the below.

Excerpt:
Could be the PCI bug they've been struggling with. Try setting
/etc/sysconfig/init line "GRAPHICAL=no" and rebooting.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100920
Comment 29 Bill Nottingham 2003-11-23 23:09:12 EST
Max K-A; it almost certainly started when kudzu started using ethtool.
Comment 30 Bill Nottingham 2003-11-23 23:10:19 EST
*** Bug 110678 has been marked as a duplicate of this bug. ***
Comment 31 James Lemke 2003-11-25 08:54:15 EST
Another data point.
I have an HP Vectra VL, P2-450, 128M, 10G with this problem.
If there is a cable plugged into the 3c905b card, the machine locks up. 
Only a power cycle brings it back.
Comment 32 James Beal 2003-12-14 15:49:01 EST
Another datapoint,

Fedora core-1 machine

eth0: Transmit error, Tx status register 82.
Probably a duplex mismatch.  See Documentation/networking/vortex.txt
  Flags; bus-master 1, dirty 2514184(8) current 2514184(8)
  Transmit list 00000000 vs. db805400.
  0: @db805200  length 800005ea status 000105ea
  1: @db805240  length 800005ea status 000105ea
  2: @db805280  length 800005ea status 000105ea
  3: @db8052c0  length 800005ea status 000105ea
  4: @db805300  length 800005ea status 000105ea
  5: @db805340  length 800005ea status 000105ea
  6: @db805380  length 800005ea status 000105ea
  7: @db8053c0  length 800005ea status 800105ea
  8: @db805400  length 800005ea status 000105ea
  9: @db805440  length 800005ea status 000105ea
  10: @db805480  length 800005ea status 000105ea
  11: @db8054c0  length 800005ea status 000105ea
  12: @db805500  length 800005ea status 000105ea
  13: @db805540  length 800005ea status 000105ea
  14: @db805580  length 800005ea status 000105ea
  15: @db8055c0  length 800005ea status 000105ea
[root@kiki james_]# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 1
cpu MHz         : 696.418
cache size      : 256 KB
physical id     : 0
siblings        : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat pse36 mmx fxsr sse
runqueue        : 0

bogomips        : 1389.36

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 3
cpu MHz         : 696.418
cache size      : 256 KB
physical id     : 0
siblings        : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat pse36 mmx fxsr sse
runqueue        : 1

bogomips        : 1392.64


[root@kiki james_]# /sbin/lspci  -v
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host
bridge (rev 03
)
        Subsystem: Dell Computer Corporation: Unknown device 0080
        Flags: bus master, medium devsel, latency 64
        Memory at f0000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [a0] AGP version 1.0

00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge
(rev 03)
(prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, medium devsel, latency 64
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        Memory behind bridge: fc000000-fdffffff
        Prefetchable memory behind bridge: e0000000-efffffff

00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
        Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
(prog-if 80
[Master])
        Flags: bus master, medium devsel, latency 64
        I/O ports at 1000 [size=16]

00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
(prog-if 00
 [UHCI])
        Flags: bus master, medium devsel, latency 64, IRQ 19
        I/O ports at ece0 [size=32]

00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
        Flags: medium devsel, IRQ 9

00:0e.0 FireWire (IEEE 1394): Lucent Microelectronics FW323 (rev 04)
(prog-if 10
 [OHCI])
        Subsystem: Lucent Microelectronics FW323
        Flags: bus master, medium devsel, latency 64, IRQ 17
        Memory at fe001000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2

00:10.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)
        Subsystem: Adaptec 29160N Ultra160 SCSI Controller
        Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 19
        BIST result: 00
        I/O ports at e800 [disabled] [size=256]
        Memory at fe000000 (64-bit, non-prefetchable) [size=4K]
        Expansion ROM at f9000000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2

00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
        Subsystem: Dell Computer Corporation 3C905B Fast Etherlink XL
10/100
        Flags: bus master, medium devsel, latency 64, IRQ 19
        I/O ports at ec00 [size=128]
        Memory at fe002000 (32-bit, non-prefetchable) [size=128]
        Expansion ROM at f9000000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 1

00:13.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev
03) (prog-i
f 00 [Normal decode])
        Flags: bus master, medium devsel, latency 64
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
        I/O behind bridge: 0000f000-0000ffff
        Memory behind bridge: fa000000-fbffffff
        Prefetchable memory behind bridge:
00000000f5000000-00000000f5f00000
        Capabilities: [dc] Power Management version 1

01:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3
Ti 200] (re
v a3) (prog-if 00 [VGA])
        Subsystem: Micro-Star International Co., Ltd.: Unknown device 8503
        Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 16
        Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
        Memory at e8000000 (32-bit, prefetchable) [size=128M]
        Memory at e7f80000 (32-bit, prefetchable) [size=512K]
        Expansion ROM at 80000000 [disabled] [size=64K]
        Capabilities: [60] Power Management version 2
        Capabilities: [44] AGP version 2.0

02:0a.0 SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891/7890
        Subsystem: Dell Computer Corporation: Unknown device 0080
        Flags: bus master, medium devsel, latency 64, IRQ 18
        BIST result: 00
        I/O ports at fc00 [disabled] [size=256]
        Memory at fafff000 (64-bit, non-prefetchable) [size=4K]
        Expansion ROM at fb000000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 1

02:0e.0 SCSI storage controller: Adaptec AIC-7880U (rev 01)
        Subsystem: Adaptec AIC-7880P Ultra/Ultra Wide SCSI Chipset
        Flags: bus master, medium devsel, latency 64, IRQ 18
        I/O ports at f800 [disabled] [size=256]
        Memory at faffe000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at fb000000 [disabled] [size=64K]
        Capabilities: [dc] Power Management version 1


Networking works but is not fast ..

Plugged in to a cisco 501
Comment 33 Jim Cornette 2003-12-27 14:40:10 EST
I reinstalled the boomerang into the machine and tried it out with
both the 2.6 kernel and the 2.4 kernel.

The first output is from the working tornado NIC with the latest
Fedora 2.4 kernel. The later is output from the boomerang which gives
me a check cable with the 2.4 and does not seem to be present for the
2.6 kernel.

I pinged both cards from another machine and there were no packages
dropped.

The same situation exists. I can run dhclient and get an IP address
from the boomerang 3com NIC. Both cards are setup for dhcp.

ifconfig initially states the below before running dhclient.
ifconfig
eth0      Link encap:Ethernet  HWaddr 00:01:02:FA:69:F3
          inet addr:192.168.1.102  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:39400 errors:0 dropped:0 overruns:0 frame:0
          TX packets:37287 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:55112354 (52.5 Mb)  TX bytes:2635316 (2.5 Mb)
          Interrupt:11 Base address:0xd880
 
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3246 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3246 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2713992 (2.5 Mb)  TX bytes:2713992 (2.5 Mb)

It later shows this output, after running dhclient. Kudzu is enabled
and no changes were done manually to any file. (Such as return 1 to
trick the card into thinking the NIC did not error with check cable)

after dhclient:
 ifconfig
eth0      Link encap:Ethernet  HWaddr 00:01:02:FA:69:F3
          inet addr:192.168.1.102  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:41911 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39705 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:58690820 (55.9 Mb)  TX bytes:2804420 (2.6 Mb)
          Interrupt:11 Base address:0xd880
(boomerang below))
eth1      Link encap:Ethernet  HWaddr 00:10:5A:14:8D:EE
          inet addr:192.168.1.103  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:1 txqueuelen:1000
          RX bytes:2882 (2.8 Kb)  TX bytes:684 (684.0 b)
          Interrupt:10 Base address:0xdc00
 
lo        Link encap:Local Loopback
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3248 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3248 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2714648 (2.5 Mb)  TX bytes:2714648 (2.5 Mb)


I hope this helps. I can also post 2.6 messages if needed.

Jim

PCI: Found IRQ 11 for device 01:00.0
PCI: Sharing IRQ 11 with 00:02.0
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
01:00.0: 3Com PCI 3c905C Tornado at 0xd880. Vers LK1.1.18-ac
 00:01:02:fa:69:f3, IRQ 11
  product code 4552 rev 00.13 date 12-01-00
  Internal config register is 1800000, transceivers 0xa.
  8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
  MII transceiver found at address 24, status 782d.
  Enabling bus-master transmits and whole-frame receives.
01:00.0: scatter/gather enabled. h/w checksums enabled
divert: allocating divert_blk for eth0
PCI: Found IRQ 10 for device 01:01.0
PCI: Sharing IRQ 10 with 00:1f.3
PCI: Sharing IRQ 10 with 00:1f.5
See Documentation/networking/vortex.txt
01:01.0: 3Com PCI 3c900 Cyclone 10Mbps TPO at 0xdc00. Vers LK1.1.18-ac
 00:10:5a:14:8d:ee, IRQ 10
  product code 504e rev 00.4 date 08-02-98
  Internal config register is 1800000, transceivers 0x8.
  8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
  MII transceiver found at address 24, status 182d.
  Enabling bus-master transmits and whole-frame receives.
01:01.0: scatter/gather enabled. h/w checksums enabled
divert: allocating divert_blk for eth1
divert: freeing divert_blk for eth0
divert: freeing divert_blk for eth1
ip_tables: (C) 2000-2002 Netfilter core team
ip_conntrack version 2.1 (4087 buckets, 32696 max) - 292 bytes per
conntrack
PCI: Found IRQ 11 for device 01:00.0
PCI: Sharing IRQ 11 with 00:02.0
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
01:00.0: 3Com PCI 3c905C Tornado at 0xd880. Vers LK1.1.18-ac
 00:01:02:fa:69:f3, IRQ 11
  product code 4552 rev 00.13 date 12-01-00
  Internal config register is 1800000, transceivers 0xa.
  8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
  MII transceiver found at address 24, status 782d.
  Enabling bus-master transmits and whole-frame receives.
01:00.0: scatter/gather enabled. h/w checksums enabled
divert: allocating divert_blk for eth0
PCI: Found IRQ 10 for device 01:01.0
PCI: Sharing IRQ 10 with 00:1f.3
PCI: Sharing IRQ 10 with 00:1f.5
See Documentation/networking/vortex.txt
01:01.0: 3Com PCI 3c900 Cyclone 10Mbps TPO at 0xdc00. Vers LK1.1.18-ac
 00:10:5a:14:8d:ee, IRQ 10
  product code 504e rev 00.4 date 08-02-98
  Internal config register is 1000000, transceivers 0x8.
  8K byte-wide RAM 5:3 Rx:Tx split, autoselect/10baseT interface.
  Enabling bus-master transmits and whole-frame receives.
01:01.0: scatter/gather enabled. h/w checksums enabled
Comment 34 Dan Ross 2003-12-30 13:03:21 EST
I am a Red Hat 6.x, 7.x sysadm, Fedora newbie, working on my first 
install (I picked "Custom"):
# rpm -qa|grep kernel
kernel-2.4.22-1.2115.nptl
kernel-pcmcia-cs-3.1.31-13
kernel-utils-2.4-9.1.101.fedora

Networking seems to function fine (ping, ssh), but when I browse to 
default welcome page, I encounter on system console:
eth0: Transmit error, Tx status register 82.
Probably a duplex mismatch.  See Documentation/networking/vortex.txt
  Flags; ...
  Transmit list ...
  0: @c6b86200  length 8000005e ...
  ...

In addition, /var/log/messages shows (my system time was off at this 
point):
Dec 30 16:24:33 fedora kernel: eth0: Transmit error, Tx status 
register 82.

I also noticed in ssl_error_log:
[Tue Dec 30 11:23:05 2003] [warn] RSA server certificate CommonName 
(CN) `localhost.localdomain' does NOT match server name!?


I found this bugzilla page and wanted to share my findings.  I hope 
this helps.

I tried the change
/etc/sysconfig/init: GRAPHICAL=no
(and reboot) with no effect.

It seems like I have managed to get the error to go away with:

* I commented out all of /etc/httpd/conf.d/welcome.conf

* Corrected /etc/hosts FROM:
127.0.0.1  fedora localhost.localdomain localhost
TO:
127.0.0.1  localhost.localdomain localhost
192.168.1.135  fedora

Comment 35 Dan Ross 2003-12-30 13:32:57 EST
I apologize, the problem is still there.
/var/log/messages:
Dec 30 12:35:07 fedora kernel: eth0: Transmit error, Tx status 
register 82.
Dec 30 12:35:07 fedora kernel: Probably a duplex mismatch.  See 
Documentation/networking/vortex.txt
Dec 30 12:35:07 fedora kernel:   Flags; bus-master 1, dirty 4121(9) 
current 4121(9)
Dec 30 12:35:07 fedora kernel:   Transmit list 00000000 vs. c6ee5440.
Dec 30 12:35:07 fedora kernel:   0: @c6ee5200  length 800005ea status 
000105ea
Dec 30 12:35:07 fedora kernel:   1: @c6ee5240  length 80000093 status 
00010093
Dec 30 12:35:07 fedora kernel:   2: @c6ee5280  length 80000036 status 
00010036
Dec 30 12:35:07 fedora kernel:   3: @c6ee52c0  length 800005ea status 
000105ea
Dec 30 12:35:07 fedora kernel:   4: @c6ee5300  length 800005ea status 
000105ea
Dec 30 12:35:07 fedora kernel:   5: @c6ee5340  length 800005ea status 
000105ea
Dec 30 12:35:07 fedora kernel:   6: @c6ee5380  length 800005ea status 
000105ea
Dec 30 12:35:07 fedora kernel:   7: @c6ee53c0  length 800005ea status 
000105ea
Dec 30 12:35:07 fedora kernel:   8: @c6ee5400  length 800005ea status 
800105ea
Dec 30 12:35:07 fedora kernel:   9: @c6ee5440  length 8000005e status 
0001005e
Dec 30 12:35:07 fedora kernel:   10: @c6ee5480  length 8000005e 
status 0001005e
Dec 30 12:35:07 fedora kernel:   11: @c6ee54c0  length 8000005e 
status 0001005e
Dec 30 12:35:07 fedora kernel:   12: @c6ee5500  length 800005ea 
status 000105ea
Dec 30 12:35:07 fedora kernel:   13: @c6ee5540  length 800005ea 
status 000105ea
Dec 30 12:35:07 fedora kernel:   14: @c6ee5580  length 800005ea 
status 000105ea
Dec 30 12:35:07 fedora kernel:   15: @c6ee55c0  length 800005ea 
status 000105ea
Comment 36 Paul Kronenwetter 2004-01-05 15:19:49 EST
Installing the 3c59x module in single-user solved the problem for me.
 I'm be interested to see what the final solution will be for this one :)
Comment 37 Jeff Garzik 2004-01-12 14:37:37 EST
*** Bug 108473 has been marked as a duplicate of this bug. ***
Comment 38 Ivan Mirisola 2004-01-21 13:04:15 EST
Created attachment 97149 [details]
3c59x.o requires special parameters in Fedora Core 1

I have had the same problems with a recent upgrade from RH 9 to Fedora Core 1
with kernel-smp-2.4.22-1.2149.nptl.

If I specify the parameters in the modules.conf, the NIC starts perfectly after
reboot:

alias eth1 3c59x debug=6 options=4 full_duplex=1

I am using debug=6 (very verbously) for diagnostics, but it also works with
debug=1 or debug=0

I guess this bug has to do with the fact that the driver is not been able to
auto negotiate the Ethernet Speed.

Hope this helps out.

Best regards,
Ivan
Comment 39 Bill Nottingham 2004-01-23 15:17:40 EST
*** Bug 114171 has been marked as a duplicate of this bug. ***
Comment 40 Jef Spaleta 2004-01-28 14:43:10 EST
*** Bug 110337 has been marked as a duplicate of this bug. ***
Comment 41 Jef Spaleta 2004-01-28 14:43:49 EST
*** Bug 113804 has been marked as a duplicate of this bug. ***
Comment 42 Bill Nottingham 2004-02-04 01:36:08 EST
*** Bug 98832 has been marked as a duplicate of this bug. ***
Comment 43 Paul Eden 2004-03-01 22:58:15 EST
I am having the same problem with Fedora Core 2 Test 1 and the 3Com
3c556B Hurricane CardBus (rev 20) card in my IBM Thinkpad laptop (A21m).
Comment 44 Neil Horman 2004-03-08 19:42:07 EST
Hey, this isn't by any chance a duplicate of BZ 102685 is it?  I saw
the same issues and then some under a boomerang card with the RHEL3
driver, and chased the problem down to a macro that check the device
config register.  It appears that a) it doesn't mask off the right
bits when checking for the phy type on the card, which causes the phy
address data to get improperly populated.  This in turn leads to
strange/random behavior when trying to drive data over the mii
interface, including the transmit problems described above.  I've got
a patch which appears to correct this behavior over in BZ 102685
Comment 45 Bill Nottingham 2004-03-09 13:51:20 EST
It couldn't hurt to try that patch.
Comment 46 Peter E. Popovich 2004-03-09 14:30:04 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 47 Bill Nottingham 2004-03-19 11:10:05 EST
*** Bug 118715 has been marked as a duplicate of this bug. ***
Comment 48 Martti Huttunen 2004-03-22 10:39:50 EST
Not a kernel bug (probably). Tried my old kernel and booted Fedora on 
that.
No difference. I moved the service to be started first, before 
microcode update, iptables and kudzu and whoa! it works. Independent 
of the used kernel. Something else messes the media selection up. 
Both machines worked fine on RH9 (!!!note again: same kernel!!!)

Both machines are Athlons and have 3Com 905B-TX's.
I also noticed that in the other machine it was enough to postpone 
the microcode update (at least so it seemed), but the other one 
wanted to start network first and foremost.
Comment 49 shrek-m 2004-04-11 07:35:20 EDT
my experiences and a working 3c59x within a few minutes,
FC1 out of the box,
3c900 combo boomerang, PCI, 10BaseT

it seems that the 3c59x driver or the 3com-nic is only working if the
module is loaded for the *first* time while booting


why ?
it is always the same behaviour under different kernels and OSs
# modinfo -d 3c59x
"3Com 3c59x/3c9xx ethernet driver LK1.1.18-ac 1 July 2002"
# modinfo -V 3c59x
modinfo (Linux modutils) 2.4.25


try it out.

it is only working
- if you disable kudzu
- if you start the network-service before kudzu or iptables while
booting (Sxxnetwork < Sxxkudzu)


- you can `rmmod 3c59x` but you will not be able to `modprobe 3c59x` a
second time succesfully


- our rhl 7.3 dsl-router (3c59x -> dsl-modem) has similiar problems.
if the dsl-modem is a short time disconnected (1 time per year) the
3c59x is completely confused, rebooting the router is the solution,
kudzu is disabaled.


- under knoppix 3.x this card is working because knoppix is loading
this module while booting and *nothing else*
if you try to rmmod and modprobe 3c59x a second time you will get the
same errors
--snip--
eth0: Transmit error, Tx status register d0.
Flags; bus-master 1, dirty 1(1) current 1(1)
[...]
--snap--
Comment 50 Alan Crosswell 2004-04-11 11:31:44 EDT
Same problem for me under FC1.  Hardware is a Sony VAIO PCG-XG29
laptop with 3C3FEM656C PCMCIA card.

What's worse, under FC2 test2, running kudzu crashes the system with a
blue screen and gibberish on it.  Not even a readable kernel panic.
Comment 51 Gregory Apessos 2004-04-29 15:24:59 EDT
On Red Hat Enterprise WS Linux 3 Update 1 I am experiencing similar
problems.  The system is a Dell Latitude C600, supposedly a certified
laptop.  

On bootup an error appears when trying to configure eth0.  Fine.  From
the console, the following command is run: modprobe 3c59x which
receives the following error:

/lib/modules/2.4.21-9.EL/kernel/drivers/net/3c59x.o: init_module:  No
such drive
  Hint: insmod errors can be caused by incorrect module paramters,
including invalid IO or IRQ parameters.
/lib/modules/2.4.21-9.EL/kernel/drivers/net/3c59x.o: insmod
/lib/modules/2.4.21-9.EL/kernel/drivers/net/3c59x.o failed
/lib/modules/2.4.21-9.EL/kernel/drivers/net/3c59x.o: insmod 3c59x failed

lspci -v returns

Communication controller: 3Com Corporation Mini PCI 56K Winmodem
Subsystem: 3Com Corporation: Unknown device 6137
Flags: medium devsel, IRQ 11

Setting the IRQ with modprobe doesn't work as it returns a warning
about it.

Not even Knoppix recognizes the modem, and it's been able to configure
everything properly so far.  

I tried downloading the 3c59x.c file and compile it but my system
doesn't have the pci-scan.h and kern_compat.h files despite having the
kernel source on the system.  

And that's that.
Comment 52 Orion Poplawski 2004-04-30 14:17:02 EDT
I think I saw the same thing with an Intel PRO 100 card and the e100
driver.  After coming across the same problem with a 3COM 3c905 card
in a newly upgraded FC1 box I swapped in an Intel card.  Never got any
errors logged, but the interface did not work.

Disabled kudzu and now the 3com card works for me.

System is a dual processor Athon MP box, AMD-760/8 chipset.
Comment 53 Doncho N. Gunchev 2004-05-04 04:52:07 EDT
    I have '3Com Corporation 3c590 10BaseT [Vortex]' which works with
all FC1 kernels, but with FC2t3 (have not tested others) I have VERY
strange behaviour...
    When I boot the PC (AMD Athlon(tm) XP 2000+ with ECS K7S5Av1 MB)
when eth1 (this card) is going up I have 20-30 seconds freeze (no
keyboard, no mouse) and then regular freezes every 10-60 seconds for
5-20 seconds. When I shut this card (I have also 8139C as eth0)
everything comes back to normal. If I remove the network cable and
bring it back on - there's no problem even after plugging back the
cable. In all the cases 'tcpdump -n -i eth1' sees nothing. mii-tool
shows '10 Mbit, half duplex, link ok', but no packet travels in or
out. The strangest part for me is that unpluging and pluging back the
cable stops the freezes (but does not make it work)...
    This is really old card, but it always worked like a rock (and
still does with FC1). I have nothing in /var/log/messages indicating
problems. SELinux is running in permissive mode.
Comment 54 Bill Nottingham 2004-05-21 16:19:15 EDT
*** Bug 122928 has been marked as a duplicate of this bug. ***
Comment 55 Doncho N. Gunchev 2004-05-21 20:02:08 EDT
    I think the problem is between 3c59x.ko and ipv6.ko...
    My '3c590 10BaseT [Vortex]' did not work with FC2 too. Unplugging
the cable did not help this time - I had to power off, unplug the
cable and then boot. The installation worked fine (even with the 3c59x
module loaded and the cable plugged in). After a few tests I renamed
'/lib/modules/2.6.5-1.358/kernel/net/ipv6/ipv6.ko' to ipv6.ko.disabled
(this was the only way not to have IPv6 with FC2t3) and after the
reboot I'm filling this comment, so I guess it workes now :) .
Comment 56 Alan Cox 2004-05-22 12:28:03 EDT
Having been over the code there are some questions. Some code paths
seem to stick the chip into D3 (power saving) state when the driver is
loaded. If kudzu then asks for the media status the driver seems to
forget to power the chip back up before asking.

Follow the probe path then the ioctl path.
Comment 57 Alan Cox 2004-05-22 12:29:20 EDT
*** Bug 116095 has been marked as a duplicate of this bug. ***
Comment 58 Alan Cox 2004-05-22 12:32:33 EDT
*** Bug 121299 has been marked as a duplicate of this bug. ***
Comment 59 Alan Cox 2004-05-22 12:33:31 EDT
*** Bug 122091 has been marked as a duplicate of this bug. ***
Comment 60 Alan Cox 2004-05-22 12:34:31 EDT
*** Bug 122220 has been marked as a duplicate of this bug. ***
Comment 61 Paul Black 2004-05-22 13:52:55 EDT
With regards to the observation that 122091 is a duplicate of this
bug, I've never had any problems with my 3com cards on RH9 or FC1;
only FC2 caused trouble.
Comment 62 Walter R. Moore 2004-05-22 15:53:22 EDT
I first experienced this with unupdated FC1 - same symptoms as
subsequent kernel and kudzu versions.
Comment 63 Andreas J. Bathe 2004-05-24 07:14:47 EDT
 please see my comment unter #102685, does it help to reconfigure your
nic with 3c90xcfg.exe and disabling kudzu?
Comment 64 Doncho N. Gunchev 2004-05-24 17:03:44 EDT
    I was wrong, disabling ipv6 had nothing to do with this problem.
Disabling kudzu however did really help.
Comment 65 Kevin Hanser 2004-05-27 18:04:34 EDT
Following someone else's instructions, I was able to get the card to
work on Fedora Core 2 by inserting this line at the top of
/etc/rc.sysinit:

insmod /lib/modules/2.6.5-1.358/kernel/drivers/net/3c59x.ko

It gives an error message on bootup, something to the effect of "file
exists", but the card works afterwards.
Comment 66 Roger I Martin PhD 2004-06-01 16:36:10 EDT
We just repeated the work around of Comment #65 and got the same 
successful result! Thanks Kevin! 
Comment 67 Luke Hastie 2004-06-02 05:13:24 EDT
Is it the 3c59x driver or Kudzu that is responsible for this bug?
Comment 68 Bill Nottingham 2004-06-02 12:21:43 EDT
Driver. There's a potential kernel patch that may fix this.
Comment 69 Bill Nottingham 2004-06-02 17:49:58 EDT
You may want to try the FC2 test update kernel... this has the 3c59x
patch integrated.
Comment 70 Maxwell Kanat-Alexander 2004-06-03 03:26:56 EDT
00:0b.0 Ethernet controller: 3Com Corporation 3c900B-TPO Etherlink XL
[Cyclone] (rev 04)

The 2.6.6-1.408 doesn't fix it for me. I might be experiencing bug
119965, though. Actually, I wouldn't be surprised if all 3c59x bugs
were actually that one. :-)
Comment 71 Robert Luken 2004-06-05 15:06:58 EDT
Just tried #65 work around on dual athlon running 2.6.5-1.358smp.
Solved the problem. System had worked fine with RH8 & 9.
Comment 72 Matts Kallioniemi 2004-06-11 04:15:48 EDT
I get this error in FC2. One workaround is to boot into runlevel 2,
which brings up networking without kudzu. Then "init 5" to get the
graphics. At the Grub prompt just type "a" for append and " 2" for
runlevel 2.

I don't know if runlevel 2 is meant to boot without kudzu. It is not
mentioned in /etc/inittab, so perhaps kudzu is left out by mistake?
Comment 73 Kirk Pickering 2004-06-13 20:16:51 EDT
Same bug found when upgrading Dell Optiplex with integrated 3c59x 
card.  Had to add line to /etc/rc.sysinit as specified in comment 
#65.   Bug still appeared with kernel 2.6.6-1.427.  Adding the
line to /etc/rc.sysinit with new kernel version number again
fixed the problem.  Thanks for the help folks.
Comment 74 Jim Cornette 2004-06-13 21:59:06 EDT
Just a comment that in comment #33, my NIC was working for the eth0 in
my comments. Now, I'm getting the check cable error again.

I'm not sure how long the NIC was not functional, but it displays the
same error symptom as my prior rev A card displayed. It appears that
the  degeneration of the driver is increasing.

I haven't tried comment #65 solution because I have a realtech card
that I use to connect to my router, not the 3com rev B card.

After servicing another computer, which required me to unhook the
wiring for this machine, to test the other machine, rehooking up the
computer again brought 3COM card 2 to be broken, but was working
previously. (In FC1)
Comment 75 Jim Cornette 2004-06-17 19:57:31 EDT
I tried getting the 3com to work in rawhide and it came up alright.
With FC2, it seems that the 3com rev b is working. The broken Ethernet
card was the realtech card.

All interfaces work in the current rawhide mix.

Just to correct my misdiagnosis.
Comment 76 Kostas Georgiou 2004-06-23 13:14:53 EDT
Any plans for a RHEL 3 fix as well ? 
Comment 77 Bill Nottingham 2004-09-03 17:53:30 EDT
*** Bug 131749 has been marked as a duplicate of this bug. ***
Comment 78 tony 2004-09-20 18:56:10 EDT
I also found turning kudzu off fixed the problem. My configuration is
an Intel 440BX M'board 400MHz Pentium II with 3C905 NIC. Same logs as
#3. Turning off kudzu fixed the problem. Appreciate the info on this page.
Comment 79 Doncho N. Gunchev 2004-09-27 18:59:51 EDT
I have '3Com Corporation 3c590 10BaseT [Vortex]' and with FC3t2 have
no problems - kernel 2.6.8-1.541 (I gave up with, so I installed FC3t2
now). Time to close this?
Comment 80 Jim Cornette 2004-09-27 19:51:49 EDT
Is kudzu running and no special scripts need editing?
Comment 81 Doncho N. Gunchev 2004-09-28 21:57:27 EDT
    Fresh FC3t2 install (not upgrade) and the network worked just fine
(still working).
    For comment #79 - I wanted to say 'I gave up to use FC2 on my home
PC' (I must have been sleeping).
Comment 82 Bill Nottingham 2004-09-28 22:00:31 EDT
Closing as RAWHIDE, then.
Comment 83 David Juran 2004-09-29 14:42:41 EDT
Does anyone know which package/configuration/whatever it is that make
this magic happen? Because it certainly does not work on my mainly FC2
installation running kernel-smp-2.6.8-1.541 with a 3Com Corporation
3c905 100BaseTX [Boomerang]
Comment 84 Jim Cornette 2004-09-29 20:10:17 EDT
I ditched my Boomerang back when FC1 was in testing phase. Are you
getting the "check cable" error or is it not recognized?

Previously, it worked throughout the release of RHL 5.2 to RHL10,
which ended up as FC1.

You probably ought to open up a new bug regarding the Boomerang being
ill affected. The vortex seems to be fixed.
Comment 85 Jim Cornette 2004-09-29 20:15:31 EDT
One note: I guess the next version is said to work according to the
reporter for the vortex. This means the test version is where the
problem ceases. FC2 still has the problem. FC3T2 seems to work correctly.
Comment 86 David Juran 2004-10-02 07:04:45 EDT
Created bug 134428 for my bomerang problem.
Comment 87 Jim Cornette 2004-10-02 17:49:37 EDT
There seems to be a lot of instances that relate to this bug. Some of
them seem to indicate that the bug is still going strong with the
later builds, like FC32.
I think that bugzilla needs to be able to specify drivers that are
contained within the kernel, in order to narrow down problems specific
to certain hardware.
Comment 88 Jon R. Kibler 2004-12-11 13:40:19 EST
(This appears to be related to more closely Bugzilla report 81422, 
but more relevant info is found in this report, and this report is 
referenced by http://fedorafaq.org/fc2/#3c905 -- "My 3com network card 
doesn't work!")

I have been using RedHat 7.3 on an IBM Thinkpad A21m for several years 
without any issues. I decided it was time to upgrade, so I loaded FC2. 
However, the laptop's NIC appeared to be unsupported.

Here are the specifics:
> lspci -v
> 00:03.0 Ethernet controller: 3Com Corporation 3c556B CardBus 
[Tornado] (rev 20)
>       Subsystem: 3Com Corporation: Unknown device 6356
>       Flags: bus master, medium devsel, latency 64, IRQ 11
>       I/O ports at 1800
>       [virtual] Memory at f4101400 (32-bit, non-prefetchable) 
[size=128]
>       [virtual] Memory at f4101000 (32-bit, non-prefetchable) 
[size=128]
>       Capabilities: [50] Power Management version 2
> 
> 00:03.1 Communication controller: 3Com Corporation Mini PCI 56k 
Winmodem (rev 20)
>       Subsystem: 3Com Corporation: Unknown device 6159
>       Flags: medium devsel, IRQ 11
>       I/O ports at 2000
>       Memory at f4101c00 (32-bit, non-prefetchable) [size=256]
>       Memory at f4101800 (32-bit, non-prefetchable) [size=128]
>       Capabilities: [50] Power Management version 2

> ip -o link show eth0
> 4: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 
1000\    link/ether ff:ff:ff:ff:ff:ff brd
ff:ff:ff:ff:ff:ff


Even with the latest FC2 kernel (2.6.9-1.6_FC2) and patches for the 
3c59x driver, it still did not work. I found and entry on the SuSE 
mailing list that indicated that ACPI appears to be broken on the 
3c556B NIC (and many other 3Com NICs), and that turning off acpi in 
the kernel will fix the problem. I tried this fix on the FC2 kernel bu 
adding "acpi=off" (no quotes) to the kernel entry in grub.conf, 
rebooted, and all now appears to be fat, dumb, and happy.

The bottom line seems to be that a MAC of "ff:ff:ff:ff:ff:ff" on a NIC 
that lspci recognizes is probably a good indication that ACPI is 
probably broken on that NIC, and the fix is to turn off ACPI in the 
kernel. (Perhaps a kludge could be added to the 3c59x driver to turn 
off acpi for that device whenever it detects a MAC of all FFs.
Comment 89 Jon R. Kibler 2004-12-11 13:44:54 EST
I should add to my previous comment that turning off kudzu did nothing 
to fix the problem. The problem was 100% reproducable in single user 
mode when manually configuring and enabling the interface w/o the help 
of kudzu or any other tool/script.

Comment 90 Radek Vokal 2005-02-07 08:11:25 EST
*** Bug 147079 has been marked as a duplicate of this bug. ***

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