Media detection problem in 89H ?

B. James Phillippe bryan@terran.org
Wed Jul 22 22:50:48 1998


Greetings,

	Donald, I think this one's best suited for your appraisal. :)  I
have a 21143 card (same one from the 128-byte scenario) that I'm having
some problems with.  The symptoms:

Card detected properly.
When started at 10bT, detects 10bT and works properly.
When started at 100bTX, detects 100bTX and works properly.
When switching from 10bT to 100bTX, switches up and works properly (after
	long delay and reported autonegotiate failure)
When switching from 100bTX to 10bT, never switches down.  Reports
	autonegotiation failure and continually retries with 100bTX.

The same card when used with de4x5.c v0.535:

Card detected properly.
When started at 10bT, detects 10bT and works properly (note: I can see the
	10bT hub flashing madly until locking in at 10bT, which takes only
	a second.  This is not like tulip.c, which comes up solidly at
	10bT)
When started at 100bTX, detecs 100bTX and works properly.
When switching from 10bT to 100bTX, switches up and works properly
	(only after two tries!  On first try, it erroneously detects 10bT
	again; after reinserting the 100bTX cable it works)
When switching from 100bTX to 10bT, switches down and works properly
	(after a short delay)

Here is some diagnostic output from TULIP_DEBUG=2.  The sequence starts
with insmod tulip while connected at 10bT.  Then we switch to 100bTX, and
then back to 10bT:

18:27:25 kernel: tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov
18:27:25 kernel: eth0: Digital DS21142/3 Tulip at 0xfc00, 00 90 7f 00 00
2d, IRQ 11.
18:27:25 kernel: read_eeprom:
18:27:25 kernel: 0000 0000 0000 0000 0000 0000 0000 0000
18:27:25 kernel: 0000 0104 9000 007f 2d00 1e00 0000 0800
18:27:25 kernel: 8604 0002 08af 00a5 0286 af04 a508 8800
18:27:25 kernel: 0304 08af 00a5 8061 0488 af05 a508 6100
18:27:25 kernel: 0080 0000 0000 0000 0000 0000 0000 0000
18:27:25 kernel: 0000 0000 0000 0000 0000 0000 0000 0000
18:27:25 kernel: 0000 0000 0000 0000 0000 0000 0000 0000
18:27:25 kernel: 0000 0000 0000 0000 0000 0000 0000 9d48
18:27:25 kernel: eth0:  EEPROM default media type Autosense.
18:27:25 kernel: eth0:  Index #0 - Media 10baseT (#0) described by a 21142
Serial PHY (2) block.
18:27:25 kernel: eth0:  Index #1 - Media 10baseT-FD (#4) described by a
21142 Serial PHY (2) block.
18:27:25 kernel: eth0:  Index #2 - Media 100baseTx (#3) described by a
21143 SYM PHY (4) block.
18:27:25 kernel: eth0:  Index #3 - Media 100baseTx-FD (#5) described by a
21143 SYM PHY (4) block.
18:27:25 kernel:   PCI latency timer (CFLT) is 0xa5,  PCI command is 0017.
18:28:04 kernel: eth0: tulip_open() irq 11.
18:28:07 kernel: eth0: 21142 link change, CSR5 = f0668010.
18:28:07 kernel: eth0: 21142 link status interrupt 000050ca, CSR5 f0660000.
18:28:09 kernel: eth0: 21142 negotiation status 000052ca, 10baseT.
18:29:09 kernel: eth0: 21142 negotiation status 000052ca, 10baseT.
18:29:26 root: 10bT looks good; now trying 100bTX-FDX
18:29:33 kernel: eth0: 21142 link change, CSR5 = f0669000.
18:29:33 kernel: eth0: 21142 link status interrupt 000012ce, CSR5 f0660000.
18:30:09 kernel: eth0: 21142 negotiation status 000092ce, 10baseT.
18:30:09 kernel: eth0: 21142 negotiation failed, status 000092ce.
18:30:09 kernel: eth0: Testing new 21142 media 100baseTx.
18:30:09 kernel: eth0: The transmitter stopped!  CSR5 is f0678006, CSR6
b3862002.
18:30:09 kernel: eth0: 21142 link change, CSR5 = f8668000.
18:30:09 kernel: eth0: 21142 link status interrupt 000000cc, CSR5 f8668000.
18:30:09 kernel: eth0: 21142 100baseTx link beat good.
18:31:09 kernel: eth0: 21142 negotiation status 000000cc, 100baseTx.
18:31:20 root: 100bTX took 30+ seconds, but working; going back to 10bT
18:31:27 kernel: eth0: 21142 link change, CSR5 = f8668000.
18:31:27 kernel: eth0: 21142 link status interrupt 000000ce, CSR5 f8668000.
18:32:09 kernel: eth0: 21142 negotiation status 000000ce, 10baseT.
18:32:09 kernel: eth0: 21142 negotiation failed, status 000000ce.
18:32:09 kernel: eth0: Testing new 21142 media 100baseTx.
18:32:33 root: Nope, stuck in 100Mb forever.  Must rmmod tulip
18:32:37 kernel: eth0: Shutting down ethercard, status was f0160000.

I've been looking carefully through both tulip.c and de4x5.c, taking notes
and cross-referencing the 21143 databook to understand the problem.  It
looks like de4x5 has some much more complicated code to deal with
media-switching.  In particular, a lot of fiddling with CSR6 and a single
read from CSR8.

Can you offer any advice on how to improve the media-detection algorithm of
tulip.c?  I'd also like to speed-up detection.  It currently looks like we
immediately get an interrupt for losing link, but rely on the t21142_timer
on the timer list to expire before we can re-establish it.  Is this
correct?

-bp
--
B. James Phillippe <bryan@terran.org>
Linux Software Engineer, WGT Inc.
http://earth.terran.org/~bryan