2.3.51 tulip broken

[Jeff Garzik]

On Tue, 14 Mar 2000, Andrzej Krzysztofowicz wrote:

> > i am having trouble with my tulip card.  it's a 21041 but the driver
> > sends it through a 21143 pathway.  i don't know if the 21041
> > is similar to the 21143 but it sure isn't working for me.
> 
> Current tulip version does not work with 21041 :(
> This is the reason why Alan put two tulip drivers into 2.2.15pre.
>  
> > Linux Tulip driver version 0.9.4 (Feb 28, 2000)
> > eth0: Digital DS21140 Tulip rev 18 at 0xfc00, 00:00:F8:03:71:09, IRQ 10.
> > eth0:  EEPROM default media type Autosense.
> > eth0:  Index #0 - Media 10baseT (#0) described by a 21140 non-MII (0) block.
> > eth0:  Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block.
> > eth0:  Index #2 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block
> > .
> > eth0:  Index #3 - Media 10baseT-FD (#4) described by a 21140 non-MII (0) block.
> > eth1: Digital DC21041 Tulip rev 17 at 0xf080, 00:00:F8:05:BE:2F, IRQ 15.
> > eth1: 21041 Media table, default media 0000 (10baseT).
> > eth1:  21041 media #0, 10baseT.
> > eth1:  21041 media #4, 10baseT-FD.
> > eth1: 21143 10baseT link beat good.
> >       ^^^^^
> >       WTF??
> 
> IMHO, the problem is not here. The driver goes for both cards (21041/21143)
> through the same code but number is hardcoded here.
> 
> The following patch helps me (partially) to get 21041 work with new tulip:
> ***********************************************************************
> --- drivers/net/tulip/tulip_core.c.old	Tue Mar 14 18:12:18 2000
> +++ drivers/net/tulip/tulip_core.c	Tue Mar 14 18:13:36 2000
> @@ -175,8 +175,8 @@
>  u8 t21040_csr13[] = {2,0x0C,8,4,  4,0,0,0, 0,0,0,0, 4,0,0,0};
>  
>  /* 21041 transceiver register settings: 10-T, 10-2, AUI, 10-T, 10T-FD*/
> -u16 t21041_csr13[] = { 0xEF01, 0xEF09, 0xEF09, 0xEF01, 0xEF09, };
> -u16 t21041_csr14[] = { 0xFFFF, 0xF7FD, 0xF7FD, 0x7F3F, 0x7F3D, };
> +u16 t21041_csr13[] = { 0xEF05, 0xEF09, 0xEF09, 0xEF01, 0xEF09, };
> +u16 t21041_csr14[] = { 0x7F3F, 0xF7FD, 0xF7FD, 0x7F3F, 0x7F3D, };
>  u16 t21041_csr15[] = { 0x0008, 0x0006, 0x000E, 0x0008, 0x0008, };

This sort of code (not your patch, but the code itself) pisses me off --
these are magic numbers and I cannot evaluate their correctness at all
without having the spec in one hand.

I would __REALLY__ like to see someone grab a spec and define symbolic
constants for the various bits being set here.

The code above, IMNSHO, the THE REASON why there is so much randomness
and brokenness in all the tulip drivers right now.


> I was trying to debug the problem (but I have no time to do it now) and
> found that tulip problems are probably related to media autodetection 
> code. Unfortunately, Donald Becker's drivers generally do not allow
> setting media manually and disabling autodetection totally :(((

Yes, this is another problem.  The plan is to port the Sparc64 'ethtool'
and interface to be generally available.  This will allow users a
generic way to set/correct ther media settings.


> Maybe because Jeff Garzik have no 21041 based tulip card :->

Anybody wanna send me one?


> Jeff, what do you think of putting two tulip drivers into 2.3/2.4 ?
> Or do you believe that problems with 21041 will be fixed before 2.4 ?

I strongly dislike having two drivers, and want to get everything
working with the new driver.  The biggest obstacle to this task is the
above -- someone needs to go through the Tulip spec(s), and replace
magic numbers with constants.

Does anyone have a 21041 spec (or URL), too?  I can only find the spec
for the new 21143...

	Jeff




-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org