Will pay for help w/tulip.c media detection

[B. James Phillippe]

Hello,

	I've burned the last several days trying to fix (find?) a bug in
tulip.c:v0.89H/I but have had no luck.  Can anyone with ethernet smarts
help me out?  This is a really urgent project for me and I have permission
to pay real money for a solution...a good solution is worth about $1000
bucks. :)
	The problem is that media detection is not working properly on my
21143 card.  I think my card is fine because I have several and they all work
fine with the de4x5 driver, and not with the tulip driver.
	Why not just use the de4x5 driver?  Long story.  Suffice it to say
that it's currently a more expensive option than to pay someone for a tulip
fix. :)
	The scenario is that on powerup w/10bT link active, 10bT works
fine.  Then I switch the cable for a 100bTX one, and media detection fails,
but the driver does some magic and then 100Tx works.  But it's forever
after locked in at 100Tx.  t21142_lnk_change knows when I pull the 100Tx
cable, but t21142_timer only tries 100Tx, so I can never get out of it.
Here is a log sample with tulip_debug = 2 illustrating the problem:

13:25:59 tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov
13:25:59 eth0: Digital DS21142/3 Tulip at 0xfc00, 00 90 7f 00 00 2d, IRQ 11.
13:25:59 read_eeprom:
13:25:59 0000 0000 0000 0000 0000 0000 0000 0000
13:25:59 0000 0104 9000 007f 2d00 1e00 0000 0800
13:25:59 8604 0002 08af 00a5 0286 af04 a508 8800
13:25:59 0304 08af 00a5 8061 0488 af05 a508 6100
13:25:59 0080 0000 0000 0000 0000 0000 0000 0000
13:25:59 0000 0000 0000 0000 0000 0000 0000 0000
13:25:59 0000 0000 0000 0000 0000 0000 0000 0000
13:25:59 0000 0000 0000 0000 0000 0000 0000 9d48
13:25:59 eth0:  EEPROM default media type Autosense.
13:25:59 eth0:  Index #0 - Media 10baseT (#0) described by a 21142 Serial
PHY (2) block.
13:25:59 eth0:  Index #1 - Media 10baseT-FD (#4) described by a 21142
Serial PHY (2) block.
13:25:59 eth0:  Index #2 - Media 100baseTx (#3) described by a 21143 SYM
PHY (4) block.
13:25:59 eth0:  Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM
PHY (4) block.
13:25:59   PCI latency timer (CFLT) is 0xa5,  PCI command is 0017.

Okay, let's run ifconfig..

13:26:05 eth0: tulip_open() irq 11.
13:26:08 eth0: 21142 link change, CSR5 = f0668010.
13:26:08 eth0: 21142 link status interrupt 000050ca, CSR5 f0660000.
13:26:10 eth0: 21142 negotiation status 000052ca, 10baseT.

Here we've ifconfig'd up in 10bT while connected to 10bT.  Lookin' good.

13:26:36 eth0: 21142 link change, CSR5 = f0669000.
13:26:36 eth0: 21142 link status interrupt 000012ce, CSR5 f0660000.

Oops, switched the cable for 100bTX!

13:27:10 eth0: 21142 negotiation status 000022c6, 10baseT.
13:27:10 eth0: 21142 negotiation failed, status 000022c6.
13:27:10 eth0: Testing new 21142 media 100baseTx.
13:27:10 eth0: The transmitter stopped!  CSR5 is f0678006, CSR6 b3862002.
13:27:10 eth0: 21142 link change, CSR5 = f8668000.
13:27:10 eth0: 21142 link status interrupt 000000cc, CSR5 f8668000.
13:27:10 eth0: 21142 100baseTx link beat good.

Whoa.. autonegotiate failed.  CSR12 had no 10bT link, so we pick 100Mbps
and see if there's link.  At the same time, t21142_lnk_change() gets called
(interrupt) and hey, CSR12 says 100Mbps link is good!

13:27:39 eth0: 21142 link change, CSR5 = f8668000.
13:27:39 eth0: 21142 link status interrupt 000000ce, CSR5 f8668000.

Sneaky devil, swapped the 10bT cable back in.

13:28:10 eth0: 21142 negotiation status 000000ce, 10baseT.
13:28:10 eth0: 21142 negotiation failed, status 000000ce.
13:28:10 eth0: Testing new 21142 media 100baseTx.
13:29:10 eth0: 21142 negotiation status 000000c6, 100baseTx.
13:29:10 eth0: The transmitter stopped!  CSR5 is f0008102, CSR6 b2420200.
13:29:25 eth0: Shutting down ethercard, status was f0360000.

We're hurting now.  It's been a while and we're still lost in 100Mbps mode.
My poor little 10bT hub doesn't like this torture!  It's odd, because where
negotiation fails, the 10b and 100b link fail bits in CSR12 are both set.
I've tried several things to fix this, but to no avail.  The closest I came
was with a forced software reset after an autonegotiation failure (but
there I never got any link back.  Oops).  I'm a capable C programmer and am
(becoming) dimly aware of how the CSR's work, from reading the databook and
the driver source.  But I could really use some help.

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