Bug 44158

Summary:	tulip driver in RC1 quite broken
Product:	[Retired] Red Hat Linux	Reporter:	Michal Jaegermann <michal>
Component:	kernel	Assignee:	Phil Copeland <copeland>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Brock Organ <borgan>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.3
Target Milestone:	---
Target Release:	---
Hardware:	alpha
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-09-05 02:24:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michal Jaegermann 2001-06-11 22:11:23 UTC

(This is possibly like 40394 but more information is included)

With a kernel 2.4.3-7 from RC1 for Alpha tulip driver refuses to work
with my card. An interface is loaded but is stopped.  This is
"Linux Tulip driver version 0.9.14 (February 20, 2001)".  So far
with my Tulip card, which works with no problems with all variants
of a tulip driver included in 2.2.x kernels, I have distinct problems
with drivers distributed with 2.4.x versions.  This one:
"Linux Tulip driver version 0.9.14d (April 3, 2001)" works without
any troubles.  All from "0.9.15-pre..." series behave like 0.9.14.

Here are relevant fragments of dmesg output for a boot of a distribution
kernel:

  got res[8800:887f] for resource 0 of Digital Equipment Corporation
DECchip 21142/43
....
  got res[62000000:6203ffff] for resource 6 of Digital Equipment
Corporation DECchip 21142/43
....
  got res[62055000:620553ff] for resource 1 of Digital Equipment
Corporation DECchip 21142/43
....
PCI enable device: (Digital Equipment Corporation DECchip 21142/43)
  cmd reg 0x7
....
Linux Tulip driver version 0.9.14 (February 20, 2001)
eth0: Digital DS21143 Tulip rev 65 at 0x8800, 00:00:F0:51:00:72, IRQ 11.
eth0:  EEPROM default media type Autosense.
eth0:  Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2)
block.
eth0:  Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2)
block.
eth0:  Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4)
block.
eth0:  Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM PHY (4)
block.

and differences with a working one:

--- tulip.dmesg.dist	Mon Jun 11 15:33:42 2001
+++ tulip.dmesg.working	Mon Jun 11 15:33:39 2001
@@ -1,16 +1,17 @@
   got res[8800:887f] for resource 0 of Digital Equipment Corporation
DECchip 21142/43
 ....
-  got res[62000000:6203ffff] for resource 6 of Digital Equipment
Corporation DECchip 21142/43
+  got res[7f000000:7f03ffff] for resource 6 of Digital Equipment
Corporation DECchip 21142/43
 ....
-  got res[62055000:620553ff] for resource 1 of Digital Equipment
Corporation DECchip 21142/43
+  got res[7f055000:7f0553ff] for resource 1 of Digital Equipment
Corporation DECchip 21142/43
 ....
 PCI enable device: (Digital Equipment Corporation DECchip 21142/43)
   cmd reg 0x7
 ....
-Linux Tulip driver version 0.9.14 (February 20, 2001)
+Linux Tulip driver version 0.9.14d (April 3, 2001)
 eth0: Digital DS21143 Tulip rev 65 at 0x8800, 00:00:F0:51:00:72, IRQ 11.
 eth0:  EEPROM default media type Autosense.
 eth0:  Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2)
block.
-eth0:  Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY
(2) block.
+eth0:  Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY
(2) block.
 eth0:  Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4)
block.
-eth0:  Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM PHY (4)
block.
+eth0:  Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY
(4) block.
+

The working one is actually used with 2.4.5-ac8 kernel and differences in
resource assignments are not likely to be relevant.  'lspci -vv' gives
the same assignments to a working 0.9.14d and broken 0.9.15-pre3.

This is what a 'tulip-diag -aa -ee -mm -f' has to say for a tulip
driver from RC1:

tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker)
 http://www.scyld.com/diag/index.html
Index #1: Found a Digital DS21143 Tulip adapter at 0x8800.
Digital DS21143 Tulip chip registers at 0x8800:
 0x00: f8a0e000 ffffffff ffffffff 0ec46000 0ec46200 f0660000 b2422002
fbfffbff
 0x40: e0000000 ffffcbf8 ffffffff 00000000 000010c6 ffff0001 fff8ffff
8ff50008
 Port selection is 10mpbs-serial, half-duplex.
 Transmit started, Receive started, half-duplex.
  The Rx process state is 'Waiting for packets'.
  The Tx process state is 'Idle'.
  The transmit threshold is 72.
  The NWay status register is 000010c6.
EEPROM 64 words, 6 address bits.
PCI Subsystem IDs, vendor 1011, device 500b.
CardBus Information Structure at offset 00000000.
Ethernet MAC Station Address 00:00:F0:51:00:72.
EEPROM transceiver/media description table.
Leaf node at offset 65, default media type 0800 (Autosense).
 4 transceiver description blocks:
  Media 10baseT, block type 2, length 6.
   Serial transceiver for 10baseT (media type 0).
    GP pin direction 08af  GP pin data 0005.
  Media 10baseT-Full Duplex, block type 2, length 6.
   Serial transceiver for 10baseT-Full Duplex (media type 4).
    GP pin direction 08af  GP pin data 0005.
  Media 100baseTx, block type 4, length 8.
   SYM transceiver for 100baseTx (media type 3).
    GP pin direction 08af  GP pin data 0005.
    No media detection indication (command 80 61).
  Media 100baseTx Full Duplex, block type 4, length 8.
   SYM transceiver for 100baseTx Full Duplex (media type 5).
    GP pin direction 08af  GP pin data 0005.
    No media detection indication (command 80 61).
EEPROM contents (64 words):
0x00:  1011 500b 0000 0000 0000 0000 0000 0000
0x08:  00d4 0103 0000 51f0 7200 4100 4400 3545
0x10:  3030 422d 2241 0081 0000 0000 0000 0000
0x18:  ac00 00ac 0000 0000 0000 0000 0000 0000
0x20:  0000 0408 0286 af00 0508 8600 0402 08af
0x28:  0005 0488 af03 0508 6100 8880 0504 08af
0x30:  0005 8061 0000 0000 0000 0000 0000 0000
0x38:  0000 0000 0000 0000 0000 0000 0000 f2ea
 ID block CRC 0xd4 (vs. 0xd4).
  Full contents CRC 0xf2ea (read as 0xf2ea).
   No MII transceivers found!
  Internal autonegotiation state is 'Transmit disabled'.

and here are differences with a working one:

--- tulip.diag.dist	Mon Jun 11 15:16:21 2001
+++ tulip.diag.working	Mon Jun 11 15:35:47 2001
@@ -2,14 +2,14 @@
  http://www.scyld.com/diag/index.html
 Index #1: Found a Digital DS21143 Tulip adapter at 0x8800.
 Digital DS21143 Tulip chip registers at 0x8800:
- 0x00: f8a0e000 ffffffff ffffffff 0ec46000 0ec46200 f0660000 b2422002
fbfffbff
- 0x40: e0000000 ffffcbf8 ffffffff 00000000 000010c6 ffff0001 fff8ffff
8ff50008
+ 0x00: f8a0e000 ffffffff ffffffff 0ebd2000 0ebd2200 f0660000 b2422002
fbfffbff
+ 0x40: e0000000 fff483ff ffffffff 00000000 000052ca ffff0001 fffbffff
8ffd0008
  Port selection is 10mpbs-serial, half-duplex.
  Transmit started, Receive started, half-duplex.
   The Rx process state is 'Waiting for packets'.
   The Tx process state is 'Idle'.
   The transmit threshold is 72.
-  The NWay status register is 000010c6.
+  The NWay status register is 000052ca.
 EEPROM 64 words, 6 address bits.
 PCI Subsystem IDs, vendor 1011, device 500b.
 CardBus Information Structure at offset 00000000.
@@ -43,4 +43,4 @@
  ID block CRC 0xd4 (vs. 0xd4).
   Full contents CRC 0xf2ea (read as 0xf2ea).
    No MII transceivers found!
-  Internal autonegotiation state is 'Transmit disabled'.
+  Internal autonegotiation state is 'Negotiation complete'.

BTW - tulip-1.1.7 from sourceforge refuses to pass a single packet as well.

    Michal
    michal

Comment 1 Michal Jaegermann 2001-06-11 22:27:37 UTC

Oops - a typo at the very top.  I meant 43904 and not 40394.

Comment 2 Michal Jaegermann 2001-09-05 01:51:19 UTC

The tulip driver is still dead as cucumber in RC2.  For a change, after
replacing the broken modules with de4x5, I see this:

# ifup eth0
RTNETLINK answers: Illegal seek

which is a new development.  Despite of that de4x5 does work on my connection
but it always had assorted issues and I have no idea what was resolved.

Comment 3 Michal Jaegermann 2001-09-05 02:24:19 UTC

Oops - make the above a comment to #46291.  I failed to notice that this
one is for Alpha.  But the other one is for x86 and the breakage is
just the same. (I will put a note in #46291 as well).

Comment 4 Phil Copeland 2002-08-12 19:15:40 UTC

Fixed in RH 7.2 (so I'm told)

Phil
=--=