[parisc-linux] quad tulip now not functional in 2.4.20

[parisc-linux] quad tulip now not functional in 2.4.20

[Ed Schaller]

[-- Attachment #1: Type: text/plain, Size: 3412 bytes --]

I have a B180 that I have been using as a firewall/router for some time
now. Along with the built in tulip ethernet card, I also have a Adaptec
quad ethernet card that is also tulip based. This has worked fine in
2.4.17-2.4.19 but no longer works in 2.4.20-pa13. Although I can
ifconfig up the interfaces, no traffic goes through and mii-tool reports
that the interfaces do not exist (except for the built in one).

In the following dmesg out takes for 2.4.20-pa13 and 2.4.19-32 (debian),
it seems that the older kernel is finding the transceiver and
successfully auto-negotiating the link while the newer is not.

Any ideas how to solve this? Any help would be greatly appreciated.

Linux version 2.4.20-pa13 (root@landmine) (gcc version 3.0.4) #3 Tue Dec 10 01:35:34 MST 2002
...
Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
tulip0: no phy info, aborting mtable build
tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
eth0: Digital DS21143 Tulip rev 48 at 0xf0fff000, 00:60:B0:C4:5E:7B, IRQ 96.
eth1: Digital DS21140 Tulip rev 34 at 0xf0efc000, 00:00:D1:1B:C8:90, IRQ 98.
eth2: Digital DS21140 Tulip rev 34 at 0xf0efd000, 00:00:D1:1B:C8:B5, IRQ 99.
eth3: Digital DS21140 Tulip rev 34 at 0xf0efe000, 00:00:D1:1B:C8:95, IRQ 96.
eth4: Digital DS21140 Tulip rev 34 at 0xf0eff000, 00:00:D1:1B:70:33, IRQ 97.
...until ifconfig eth0-eth4
eth0: Setting full-duplex based on MII#1 link partner capability of 45e1.

Linux version 2.4.19-32 (root@j5k) (gcc version 3.0.4) #1 Fri Nov 22 23:27:00 MST 2002
...
Linux Tulip driver version 0.9.15-pre11 (May 11, 2002)
tulip0: no phy info, aborting mtable build
tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
eth0: Digital DS21143 Tulip rev 48 at 0xff00, 00:60:B0:C4:5E:7B, IRQ 96.
tulip1:  EEPROM default media type Autosense.
tulip1:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
tulip1:  MII transceiver #1 config 3100 status 7849 advertising 01e1.
eth1: Digital DS21140 Tulip rev 34 at 0xec00, 00:00:D1:1B:C8:90, IRQ 98.
tulip2:  EEPROM default media type Autosense.
tulip2:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
tulip2:  MII transceiver #1 config 3100 status 7849 advertising 01e1.
eth2: Digital DS21140 Tulip rev 34 at 0xed00, 00:00:D1:1B:C8:B5, IRQ 99.
tulip3:  EEPROM default media type Autosense.
tulip3:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
tulip3:  MII transceiver #1 config 3100 status 7849 advertising 01e1.
eth3: Digital DS21140 Tulip rev 34 at 0xee00, 00:00:D1:1B:C8:95, IRQ 96.
tulip4:  EEPROM default media type Autosense.
tulip4:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
tulip4:  MII transceiver #1 config 3100 status 7849 advertising 01e1.
eth4: Digital DS21140 Tulip rev 34 at 0xef00, 00:00:D1:1B:70:33, IRQ 97.
...until ifconfig eth0-eth4
eth0: Setting full-duplex based on MII#1 link partner capability of 45e1.
eth1: Setting full-duplex based on MII#1 link partner capability of 45e1.
eth2: Setting full-duplex based on MII#1 link partner capability of 45e1.
eth3: Setting full-duplex based on MII#1 link partner capability of 41e1.
eth4: Setting full-duplex based on MII#1 link partner capability of 41e1.

>>>------>

--

+-------------+-----------------------+---------------+
| Ed Schaller | Dark Mist Networking  | psuedoshroom  |
+-------------+-----------------------+---------------+

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Grant Grundler]

On Sun, Dec 15, 2002 at 11:45:12PM -0700, Ed Schaller wrote:
> I have a B180 that I have been using as a firewall/router for some time
> now. Along with the built in tulip ethernet card, I also have a Adaptec
> quad ethernet card that is also tulip based. This has worked fine in
> 2.4.17-2.4.19 but no longer works in 2.4.20-pa13. Although I can
> ifconfig up the interfaces, no traffic goes through and mii-tool reports
> that the interfaces do not exist (except for the built in one).

I've looked a bit at the same problem on A500 with
a regular (single port) HP tulip card.

> In the following dmesg out takes for 2.4.20-pa13 and 2.4.19-32 (debian),
> it seems that the older kernel is finding the transceiver and
> successfully auto-negotiating the link while the newer is not.

yeah - same symptom that I saw.

> Any ideas how to solve this? Any help would be greatly appreciated.

I suspect it's a tulip driver bug.
I haven't had a chance to diff the 2.4.19 vs 2.4.20 tulip driver.
One idea might be to "forward port" the 2.4.19 drivers/net/tulip code
into 2.4.20.

thanks for the report,
grant

> Linux version 2.4.20-pa13 (root@landmine) (gcc version 3.0.4) #3 Tue Dec 10 01:35:34 MST 2002
> ...
> Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
> tulip0: no phy info, aborting mtable build
> tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
> eth0: Digital DS21143 Tulip rev 48 at 0xf0fff000, 00:60:B0:C4:5E:7B, IRQ 96.
> eth1: Digital DS21140 Tulip rev 34 at 0xf0efc000, 00:00:D1:1B:C8:90, IRQ 98.
> eth2: Digital DS21140 Tulip rev 34 at 0xf0efd000, 00:00:D1:1B:C8:B5, IRQ 99.
> eth3: Digital DS21140 Tulip rev 34 at 0xf0efe000, 00:00:D1:1B:C8:95, IRQ 96.
> eth4: Digital DS21140 Tulip rev 34 at 0xf0eff000, 00:00:D1:1B:70:33, IRQ 97.
> ...until ifconfig eth0-eth4
> eth0: Setting full-duplex based on MII#1 link partner capability of 45e1.
> 
> Linux version 2.4.19-32 (root@j5k) (gcc version 3.0.4) #1 Fri Nov 22 23:27:00 MST 2002
> ...
> Linux Tulip driver version 0.9.15-pre11 (May 11, 2002)
> tulip0: no phy info, aborting mtable build
> tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
> eth0: Digital DS21143 Tulip rev 48 at 0xff00, 00:60:B0:C4:5E:7B, IRQ 96.
> tulip1:  EEPROM default media type Autosense.
> tulip1:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
> tulip1:  MII transceiver #1 config 3100 status 7849 advertising 01e1.
> eth1: Digital DS21140 Tulip rev 34 at 0xec00, 00:00:D1:1B:C8:90, IRQ 98.
> tulip2:  EEPROM default media type Autosense.
> tulip2:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
> tulip2:  MII transceiver #1 config 3100 status 7849 advertising 01e1.
> eth2: Digital DS21140 Tulip rev 34 at 0xed00, 00:00:D1:1B:C8:B5, IRQ 99.
> tulip3:  EEPROM default media type Autosense.
> tulip3:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
> tulip3:  MII transceiver #1 config 3100 status 7849 advertising 01e1.
> eth3: Digital DS21140 Tulip rev 34 at 0xee00, 00:00:D1:1B:C8:95, IRQ 96.
> tulip4:  EEPROM default media type Autosense.
> tulip4:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
> tulip4:  MII transceiver #1 config 3100 status 7849 advertising 01e1.
> eth4: Digital DS21140 Tulip rev 34 at 0xef00, 00:00:D1:1B:70:33, IRQ 97.
> ...until ifconfig eth0-eth4
> eth0: Setting full-duplex based on MII#1 link partner capability of 45e1.
> eth1: Setting full-duplex based on MII#1 link partner capability of 45e1.
> eth2: Setting full-duplex based on MII#1 link partner capability of 45e1.
> eth3: Setting full-duplex based on MII#1 link partner capability of 41e1.
> eth4: Setting full-duplex based on MII#1 link partner capability of 41e1.
> 
> >>>------>
> 
> --
> 
> +-------------+-----------------------+---------------+
> | Ed Schaller | Dark Mist Networking  | psuedoshroom  |
> +-------------+-----------------------+---------------+

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[jsoe0708]

[-- Attachment #1: Type: text/plain, Size: 6008 bytes --]

>
>I suspect it's a tulip driver bug.
>I haven't had a chance to diff the 2.4.19 vs 2.4.20 tulip driver.
>One idea might be to "forward port" the 2.4.19 drivers/net/tulip code
>into 2.4.20.
>
Just to avoid you loose time here is a diff:
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/ChangeLog linux-2.4.20-pa14/drivers/net/tulip/ChangeLog
--- linux-2.4.19-pa24/drivers/net/tulip/ChangeLog	2002-08-03 02:39:44.000000000
+0200
+++ linux-2.4.20-pa14/drivers/net/tulip/ChangeLog	2002-11-18 09:09:41.000000000
+0100
@@ -1,3 +1,14 @@
+2002-09-18  Ryan Bradetich  <rbradetich@uswest.net>
+
+	tulip hppa support:
+	* eeprom.c (tulip_build_fake_mediatable): new function
+	(tulip_parse_eeprom): call it, when no media table
+	* interrupt.c (phy_interrupt): new function
+	(tulip_interrupt): call it, before checking for no-irq-work
+	* tulip.c: add HAS_PHY_IRQ chip feature flag.
+	add csr12_shadow to tulip_private struct, only for hppa currently.
+	* tulip_core (tulip_init_one): support hppa wonky eeproms
+
 2002-05-11  Juan Quintela  <quintela@mandrakesoft.com>

 	* 21142.c (t21142_lnk_change): Revert earlier patch
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/eeprom.c linux-2.4.20-pa14/drivers/net/tulip/eeprom.c
--- linux-2.4.19-pa24/drivers/net/tulip/eeprom.c	2002-11-28 12:41:36.000000000
+0100
+++ linux-2.4.20-pa14/drivers/net/tulip/eeprom.c	2002-11-18 09:09:41.000000000
+0100
@@ -190,7 +190,7 @@
 	}
 subsequent_board:

-	if (ee_data[27] == 0) {		/* No valid media table. */
+	if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) {  /* No valid media
table. */
 		tulip_build_fake_mediatable(tp);
 	} else if (tp->chip_id == DC21041) {
 		unsigned char *p = (void *)ee_data + ee_data[27 + controller_index*3];
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/tulip.h linux-2.4.20-pa14/drivers/net/tulip/tulip.h
--- linux-2.4.19-pa24/drivers/net/tulip/tulip.h	2002-11-28 12:41:36.000000000
+0100
+++ linux-2.4.20-pa14/drivers/net/tulip/tulip.h	2002-11-18 09:09:41.000000000
+0100
@@ -63,7 +63,7 @@
 	HAS_8023X		= 0x0400,
 	COMET_MAC_ADDR		= 0x0800,
 	HAS_PCI_MWI		= 0x1000,
-        HAS_PHY_IRQ             = 0x2000,
+	HAS_PHY_IRQ		= 0x2000,
 };


@@ -85,6 +85,7 @@
 	COMPEX9881,
 	I21145,
 	DM910X,
+	CONEXANT,
 };


diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/tulip_core.c linux-2.4.20-pa14/drivers/net/tulip/tulip_core.c
--- linux-2.4.19-pa24/drivers/net/tulip/tulip_core.c	2002-11-28 12:41:36.000000000
+0100
+++ linux-2.4.20-pa14/drivers/net/tulip/tulip_core.c	2002-11-18 09:09:41.000000000
+0100
@@ -15,8 +15,8 @@
 */

 #define DRV_NAME	"tulip"
-#define DRV_VERSION	"0.9.15-pre11"
-#define DRV_RELDATE	"May 11, 2002"
+#define DRV_VERSION	"0.9.15-pre12"
+#define DRV_RELDATE	"Aug 9, 2002"

 #include <linux/config.h>
 #include <linux/module.h>
@@ -191,6 +191,10 @@
   { "Davicom DM9102/DM9102A", 128, 0x0001ebef,
 	HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI,
 	tulip_timer },
+
+  /* CONEXANT */
+  {	"Conexant LANfinity", 256, 0x0001ebef,
+	HAS_MII, tulip_timer },
 };


@@ -214,6 +218,7 @@
 	{ 0x13D1, 0xAB08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
 	{ 0x104A, 0x0981, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
 	{ 0x104A, 0x2774, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+	{ 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
 	{ 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 },
 	{ 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 },
 	{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
@@ -221,6 +226,10 @@
 	{ 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
 	{ 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 },
 	{ 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+	{ 0x1186, 0x1561, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+	{ 0x1626, 0x8410, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+	{ 0x1737, 0xAB09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+	{ 0x14f1, 0x1803, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CONEXANT },
 	{ } /* terminate list */
 };
 MODULE_DEVICE_TABLE(pci, tulip_pci_tbl);
@@ -453,7 +462,7 @@
 		tp->csr6 = 0x01a80200;
 		outl(0x0f370000 | inw(ioaddr + 0x80), ioaddr + 0x80);
 		outl(0x11000 | inw(ioaddr + 0xa0), ioaddr + 0xa0);
-	} else if (tp->chip_id == COMET) {
+	} else if (tp->chip_id == COMET || tp->chip_id == CONEXANT) {
 		/* Enable automatic Tx underrun recovery. */
 		outl(inl(ioaddr + 0x88) | 1, ioaddr + 0x88);
 		dev->if_port = tp->mii_cnt ? 11 : 0;
@@ -1474,7 +1483,6 @@
 	tp->timer.function = tulip_tbl[tp->chip_id].media_timer;

 	dev->base_addr = ioaddr;
-	dev->irq = irq;

 #ifdef CONFIG_TULIP_MWI
 	if (!force_csr0 && (tp->flags & HAS_PCI_MWI))
@@ -1548,7 +1556,13 @@
 		for (i = 0; i < 8; i ++)
 			if (ee_data[i] != ee_data[16+i])
 				sa_offset = 20;
-		if (ee_data[0] == 0xff  &&  ee_data[1] == 0xff &&  ee_data[2] == 0) {
+		if (chip_idx == CONEXANT) {
+		    /* Check that the tuple type and length is correct. */
+			if (ee_data[0x198] == 0x04  &&  ee_data[0x199] == 6)
+			    sa_offset = 0x19A;
+		}
+		if (ee_data[0] == 0xff && ee_data[1] == 0xff &&
+		    ee_data[2] == 0) {
 			sa_offset = 2;		/* Grrr, damn Matrox boards. */
 			multiport_cnt = 4;
 		}
@@ -1641,6 +1655,7 @@
 	for (i = 0; i < 6; i++)
 		last_phys_addr[i] = dev->dev_addr[i];http://webmail.tiscali.be/mail/MessageReplyAll?sid=DBE10C1646FA3872D205B9CC28640282AD467BC4&userid=jsoe0708@tiscali.be&seq=C&auth=01RVNMIUMKQMZQKW&srcfolder=INBOX&uid=3182&style=frans&abcompose=0
:: options avancées
 	last_irq = irq;
+	dev->irq = irq;

 	/* The lower four bits are the media type. */
 	if (board_idx >= 0  &&  board_idx < MAX_UNITS) {


(I have well a second interface on my b2k but never use it. I will try and
try to revert this diff.)

hph,
    Joel

********************************************************************************
Controlez mieux votre consommation Internet...surfez Tiscali Complete...http://tiscali.complete.be




[-- Attachment #2: Tulip_2.4.19-2.4.20.diff --]
[-- Type: application/octet-stream, Size: 5103 bytes --]

diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/ChangeLog linux-2.4.20-pa14/drivers/net/tulip/ChangeLog
--- linux-2.4.19-pa24/drivers/net/tulip/ChangeLog	2002-08-03 02:39:44.000000000 +0200
+++ linux-2.4.20-pa14/drivers/net/tulip/ChangeLog	2002-11-18 09:09:41.000000000 +0100
@@ -1,3 +1,14 @@
+2002-09-18  Ryan Bradetich  <rbradetich@uswest.net>
+
+	tulip hppa support:
+	* eeprom.c (tulip_build_fake_mediatable): new function
+	(tulip_parse_eeprom): call it, when no media table
+	* interrupt.c (phy_interrupt): new function
+	(tulip_interrupt): call it, before checking for no-irq-work
+	* tulip.c: add HAS_PHY_IRQ chip feature flag.
+	add csr12_shadow to tulip_private struct, only for hppa currently.
+	* tulip_core (tulip_init_one): support hppa wonky eeproms
+
 2002-05-11  Juan Quintela  <quintela@mandrakesoft.com>
 
 	* 21142.c (t21142_lnk_change): Revert earlier patch
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/eeprom.c linux-2.4.20-pa14/drivers/net/tulip/eeprom.c
--- linux-2.4.19-pa24/drivers/net/tulip/eeprom.c	2002-11-28 12:41:36.000000000 +0100
+++ linux-2.4.20-pa14/drivers/net/tulip/eeprom.c	2002-11-18 09:09:41.000000000 +0100
@@ -190,7 +190,7 @@
 	}
 subsequent_board:
 
-	if (ee_data[27] == 0) {		/* No valid media table. */
+	if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) {  /* No valid media table. */
 		tulip_build_fake_mediatable(tp);
 	} else if (tp->chip_id == DC21041) {
 		unsigned char *p = (void *)ee_data + ee_data[27 + controller_index*3];
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/tulip.h linux-2.4.20-pa14/drivers/net/tulip/tulip.h
--- linux-2.4.19-pa24/drivers/net/tulip/tulip.h	2002-11-28 12:41:36.000000000 +0100
+++ linux-2.4.20-pa14/drivers/net/tulip/tulip.h	2002-11-18 09:09:41.000000000 +0100
@@ -63,7 +63,7 @@
 	HAS_8023X		= 0x0400,
 	COMET_MAC_ADDR		= 0x0800,
 	HAS_PCI_MWI		= 0x1000,
-        HAS_PHY_IRQ             = 0x2000,
+	HAS_PHY_IRQ		= 0x2000,
 };
 
 
@@ -85,6 +85,7 @@
 	COMPEX9881,
 	I21145,
 	DM910X,
+	CONEXANT,
 };
 
 
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/tulip_core.c linux-2.4.20-pa14/drivers/net/tulip/tulip_core.c
--- linux-2.4.19-pa24/drivers/net/tulip/tulip_core.c	2002-11-28 12:41:36.000000000 +0100
+++ linux-2.4.20-pa14/drivers/net/tulip/tulip_core.c	2002-11-18 09:09:41.000000000 +0100
@@ -15,8 +15,8 @@
 */
 
 #define DRV_NAME	"tulip"
-#define DRV_VERSION	"0.9.15-pre11"
-#define DRV_RELDATE	"May 11, 2002"
+#define DRV_VERSION	"0.9.15-pre12"
+#define DRV_RELDATE	"Aug 9, 2002"
 
 #include <linux/config.h>
 #include <linux/module.h>
@@ -191,6 +191,10 @@
   { "Davicom DM9102/DM9102A", 128, 0x0001ebef,
 	HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI,
 	tulip_timer },
+
+  /* CONEXANT */
+  {	"Conexant LANfinity", 256, 0x0001ebef,
+	HAS_MII, tulip_timer },
 };
 
 
@@ -214,6 +218,7 @@
 	{ 0x13D1, 0xAB08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
 	{ 0x104A, 0x0981, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
 	{ 0x104A, 0x2774, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+	{ 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
 	{ 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 },
 	{ 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 },
 	{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
@@ -221,6 +226,10 @@
 	{ 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
 	{ 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 },
 	{ 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+	{ 0x1186, 0x1561, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+	{ 0x1626, 0x8410, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+	{ 0x1737, 0xAB09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+	{ 0x14f1, 0x1803, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CONEXANT },
 	{ } /* terminate list */
 };
 MODULE_DEVICE_TABLE(pci, tulip_pci_tbl);
@@ -453,7 +462,7 @@
 		tp->csr6 = 0x01a80200;
 		outl(0x0f370000 | inw(ioaddr + 0x80), ioaddr + 0x80);
 		outl(0x11000 | inw(ioaddr + 0xa0), ioaddr + 0xa0);
-	} else if (tp->chip_id == COMET) {
+	} else if (tp->chip_id == COMET || tp->chip_id == CONEXANT) {
 		/* Enable automatic Tx underrun recovery. */
 		outl(inl(ioaddr + 0x88) | 1, ioaddr + 0x88);
 		dev->if_port = tp->mii_cnt ? 11 : 0;
@@ -1474,7 +1483,6 @@
 	tp->timer.function = tulip_tbl[tp->chip_id].media_timer;
 
 	dev->base_addr = ioaddr;
-	dev->irq = irq;
 
 #ifdef CONFIG_TULIP_MWI
 	if (!force_csr0 && (tp->flags & HAS_PCI_MWI))
@@ -1548,7 +1556,13 @@
 		for (i = 0; i < 8; i ++)
 			if (ee_data[i] != ee_data[16+i])
 				sa_offset = 20;
-		if (ee_data[0] == 0xff  &&  ee_data[1] == 0xff &&  ee_data[2] == 0) {
+		if (chip_idx == CONEXANT) {
+		    /* Check that the tuple type and length is correct. */
+			if (ee_data[0x198] == 0x04  &&  ee_data[0x199] == 6)
+			    sa_offset = 0x19A;
+		}
+		if (ee_data[0] == 0xff && ee_data[1] == 0xff &&
+		    ee_data[2] == 0) {
 			sa_offset = 2;		/* Grrr, damn Matrox boards. */
 			multiport_cnt = 4;
 		}
@@ -1641,6 +1655,7 @@
 	for (i = 0; i < 6; i++)
 		last_phys_addr[i] = dev->dev_addr[i];
 	last_irq = irq;
+	dev->irq = irq;
 
 	/* The lower four bits are the media type. */
 	if (board_idx >= 0  &&  board_idx < MAX_UNITS) {

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Grant Grundler]

On Tue, Dec 17, 2002 at 08:12:03AM +0100, jsoe0708@tiscali.be wrote:
> Just to avoid you loose time here is a diff:
...
> -	if (ee_data[27] == 0) {		/* No valid media table. */
> +	if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) {  /* No valid media
> table. */

Like I suspected, backing out this change made add-on boards work again.
I've reverted that change in 2.4.20-pa15 along with a traps.c change.
Please apply by hand and try the 4-port again.

thanks,
grant

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Ed Schaller]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

> Like I suspected, backing out this change made add-on boards work again.
> I've reverted that change in 2.4.20-pa15 along with a traps.c change.
> Please apply by hand and try the 4-port again.

Seems to work fine. Thanks for all the help!

>>>------>

--

+-------------+-----------------------+---------------+
| Ed Schaller | Dark Mist Networking  | psuedoshroom  |
+-------------+-----------------------+---------------+

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[jsoe0708]

Hi Grant,

>
>On Tue, Dec 17, 2002 at 08:12:03AM +0100, jsoe0708@tiscali.be wrote:
>> Just to avoid you loose time here is a diff:
>...
>> -	if (ee_data[27] =3D=3D 0) {		/* No valid media table. */
>> +	if (ee_data[27] =3D=3D 0 || ee_data[ee_data[27]] =3D=3D 0) {  /* No =
valid media
>> table. */
>
>Like I suspected, backing out this change made add-on boards work again.=

>I've reverted that change in 2.4.20-pa15 along with a traps.c change.
>Please apply by hand and try the 4-port again.
>
Sorry, I was too tired yesterday evening and have not time today :-(.

But I see that Ed successfully tested. Great (I will also test it, ... ne=
xt
year :))

Thanks for all and let me wish you and your families a Merry Christmas an=
d
a Happy New Year,
    Joel



*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[jsoe0708]

>
>I've looked a bit at the same problem on A500 with
>a regular (single port) HP tulip card.
>
>> In the following dmesg out takes for 2.4.20-pa13 and 2.4.19-32 (debian=
),
>> it seems that the older kernel is finding the transceiver and
>> successfully auto-negotiating the link while the newer is not.
>
>yeah - same symptom that I saw.
>
>> Any ideas how to solve this? Any help would be greatly appreciated.
>
>I suspect it's a tulip driver bug.
>I haven't had a chance to diff the 2.4.19 vs 2.4.20 tulip driver.
>One idea might be to "forward port" the 2.4.19 drivers/net/tulip code
>into 2.4.20.
>
Same on B2k with add card.
Hmm I notice strange detail:
2.4.19 : lan heart bit on (even if interface not configure)
2.4.20 (& 21-pre1) : no lan heart bit on (interface configured or not)

I will try to revert tulip driver and advise you.

Cheer,
    Joel


*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[jsoe0708]

Hello Grant,

>>
>>I've looked a bit at the same problem on A500 with
>>a regular (single port) HP tulip card.
>>
>>> In the following dmesg out takes for 2.4.20-pa13 and 2.4.19-32 (debia=
n),
>>> it seems that the older kernel is finding the transceiver and
>>> successfully auto-negotiating the link while the newer is not.
>>
>>yeah - same symptom that I saw.
>>
>>> Any ideas how to solve this? Any help would be greatly appreciated.
>>
>>I suspect it's a tulip driver bug.
>>I haven't had a chance to diff the 2.4.19 vs 2.4.20 tulip driver.
>>One idea might be to "forward port" the 2.4.19 drivers/net/tulip code
>>into 2.4.20.
>>
>Same on B2k with add card.
>Hmm I notice strange detail:
>2.4.19 : lan heart bit on (even if interface not configure)
>2.4.20 (& 21-pre1) : no lan heart bit on (interface configured or not)
>
>I will try to revert tulip driver and advise you.
>
Well I find some minutes to do this reverse and it works.
Still have to find the bug ?

Joel


*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[jsoe0708]

Hello Grant,
>
>>>
>>>I've looked a bit at the same problem on A500 with
>>>a regular (single port) HP tulip card.
>>>
>>>> In the following dmesg out takes for 2.4.20-pa13 and 2.4.19-32 (debi=
an),
>>>> it seems that the older kernel is finding the transceiver and
>>>> successfully auto-negotiating the link while the newer is not.
>>>
>>>yeah - same symptom that I saw.
>>>
>>>> Any ideas how to solve this? Any help would be greatly appreciated.
>>>
>>>I suspect it's a tulip driver bug.
>>>I haven't had a chance to diff the 2.4.19 vs 2.4.20 tulip driver.
>>>One idea might be to "forward port" the 2.4.19 drivers/net/tulip code
>>>into 2.4.20.
>>>
>>Same on B2k with add card.
>>Hmm I notice strange detail:
>>2.4.19 : lan heart bit on (even if interface not configure)
>>2.4.20 (& 21-pre1) : no lan heart bit on (interface configured or not)
>>
>>I will try to revert tulip driver and advise you.
>>
>Well I find some minutes to do this reverse and it works.
>Still have to find the bug ?
>
Hmm I suspecting a test in eeprom.c:
line 193: if (ee_data[27] =3D=3D 0 || ee_data[ee_data[27]] =3D=3D0) {

which i temporarely change by if (ee_data[27] =3D=3D 0) { (as i 2.4.19)
and it works but I have not enough doc to fix this pb.

May be Ryan Bradetich could help us?

Joel


*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Grant Grundler]

On Tue, Dec 17, 2002 at 04:14:10PM +0100, jsoe0708@tiscali.be wrote:
> >I will try to revert tulip driver and advise you.
> Well I find some minutes to do this reverse and it works.
> Still have to find the bug ?

Unfortunately yes.
But since the diff is small, it's alot easier.

I'm most suspicious about the added checks for length field in eeprom.
But I'll review the diff again and tinker with it today or tomorrow.
I added that thinking that code only gets executed when there is no
phy table (eg built-in). But the add-on cards do have a phy table.

grant

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[jsoe0708]

Hi Grant,
>
>On Tue, Dec 17, 2002 at 04:14:10PM +0100, jsoe0708@tiscali.be wrote:
>> >I will try to revert tulip driver and advise you.
>> Well I find some minutes to do this reverse and it works.
>> Still have to find the bug ?
>
>Unfortunately yes.
>But since the diff is small, it's alot easier.
>
>I'm most suspicious about the added checks for length field in eeprom.
>But I'll review the diff again and tinker with it today or tomorrow.
>I added that thinking that code only gets executed when there is no
>phy table (eg built-in). But the add-on cards do have a phy table.
>
(well it seems I do mistake when sent following info)
[also because diff is small]
In eeprom.c I also suspect:
line 193: if (ee_data[27] =3D=3D 0 || ee_data[ee_data[27]] =3D=3D 0) {

which I only reverse into:
if (ee_data[27] =3D=3D 0) {

and it works. Unforunately I do not have enough doc to actulay fix the pb=
.
May be Ryan could still help us?

Joel

*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Grant Grundler]

On Wed, Dec 18, 2002 at 07:30:40AM +0100, jsoe0708@tiscali.be wrote:
> In eeprom.c I also suspect:
> line 193: if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) {
...
> and it works. Unforunately I do not have enough doc to actulay fix the pb.

I don't either. I made that change after reviewing the code and just
botched it. My understanding is jgarzik is rewriting tulip driver anyway.

grant

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Ryan Bradetich]

Joel,

Just a heads up ... I will not even have a chance to look at this for
a week or two.

Thanks,

- Ryan

On Tue, 2002-12-17 at 23:30, jsoe0708@tiscali.be wrote:
> Hi Grant,
> >
> >On Tue, Dec 17, 2002 at 04:14:10PM +0100, jsoe0708@tiscali.be wrote:
> >> >I will try to revert tulip driver and advise you.
> >> Well I find some minutes to do this reverse and it works.
> >> Still have to find the bug ?
> >
> >Unfortunately yes.
> >But since the diff is small, it's alot easier.
> >
> >I'm most suspicious about the added checks for length field in eeprom.
> >But I'll review the diff again and tinker with it today or tomorrow.
> >I added that thinking that code only gets executed when there is no
> >phy table (eg built-in). But the add-on cards do have a phy table.
> >
> (well it seems I do mistake when sent following info)
> [also because diff is small]
> In eeprom.c I also suspect:
> line 193: if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) {
> 
> which I only reverse into:
> if (ee_data[27] == 0) {
> 
> and it works. Unforunately I do not have enough doc to actulay fix the pb.
> May be Ryan could still help us?
> 
> Joel
> 
> ********************************************************************************
> Controlez mieux votre consommation Internet...surfez Tiscali Complete...http://tiscali.complete.be
> 
> 
> 
> 

RE: [parisc-linux] quad tulip now not functional in 2.4.20

["Beerse, Corné"]

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

Why did nobody point to the hardware database: http://hwdb.parisc-linux.org/

There are some users of a D210 reported there:
http://hwdb.parisc-linux.org/view.php3?type=machine&name=D210

They will know some ins and outs.

CBee


--
C. Beerse
mailto:c.beerse@torex-hiscom.nl
talkto:+31(71)5256660


> -----Original Message-----
> From: jsoe0708@tiscali.be [mailto:jsoe0708@tiscali.be]
> Sent: donderdag 19 december 2002 18:38
> To: grundler@dsl2.external.hp.com
> Cc: Ed Schaller; parisc-linux@lists.parisc-linux.org
> Subject: Re: [parisc-linux] quad tulip now not functional in 2.4.20
> 
> 
> Hi Grant,
> 
> >
> >On Tue, Dec 17, 2002 at 08:12:03AM +0100, jsoe0708@tiscali.be wrote:
> >> Just to avoid you loose time here is a diff:
> >...
> >> -	if (ee_data[27] == 0) {		/* No valid media table. */
> >> +	if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) {  
> /* No valid media
> >> table. */
> >
> >Like I suspected, backing out this change made add-on boards 
> work again.
> >I've reverted that change in 2.4.20-pa15 along with a traps.c change.
> >Please apply by hand and try the 4-port again.
> >
> Sorry, I was too tired yesterday evening and have not time today :-(.
> 
> But I see that Ed successfully tested. Great (I will also 
> test it, ... next
> year :))
> 
> Thanks for all and let me wish you and your families a Merry 
> Christmas and
> a Happy New Year,
>     Joel
> 
> 
> 
> **************************************************************
> ******************
> Controlez mieux votre consommation Internet...surfez Tiscali 
> Complete...http://tiscali.complete.be
> 
> 
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> 

[-- Attachment #2: Type: text/html, Size: 4235 bytes --]

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Michael S.Zick]

On Thursday 30 January 2003 04:59 am, Beerse, Corné wrote:
> Why did nobody point to the hardware database:
> http://hwdb.parisc-linux.org/
>
> There are some users of a D210 reported there:
> http://hwdb.parisc-linux.org/view.php3?type=machine&name=D210
>
> They will know some ins and outs.
>
> CBee
Good point...

Perhaps because it is refered to as a "hardware database" ?
Using something called a "hardware database" to find persons
experienced in a certain machine can indeed be very helpful;
but not an obvious use going by its name.

"tweaking" a web page or two to make this usage clear
to the newcomer might help.

Who would be a good contact for such a change?

Mike

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Randolph Chung]

> Who would be a good contact for such a change?

there's an email address on many of the hwdb pages
(hwdb@parisc-linux.org). That'll be a good place to start. I believe it
currently points to Thibaut :)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Michael S.Zick]

Thanks,
Will do.

I posted a separate message to the M-L - just to see
how many:
 "I didn't mean I have the time to answer questions."
sort of responses this idea would raise among the 
M-L members.

Mike

On Thursday 30 January 2003 09:02 am, Randolph Chung wrote:
> > Who would be a good contact for such a change?
>
> there's an email address on many of the hwdb pages
> (hwdb@parisc-linux.org). That'll be a good place to start. I believe it
> currently points to Thibaut :)
>
> randolph

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Thibaut VARENE]

On jeudi, jan 30, 2003, at 16:02 Europe/Paris, Randolph Chung wrote:

>> Who would be a good contact for such a change?
>
> there's an email address on many of the hwdb pages
> (hwdb@parisc-linux.org). That'll be a good place to start. I believe it
> currently points to Thibaut :)
yes.

quoting Michael S.Zick:
> "tweaking" a web page or two to make this usage clear
> to the newcomer might help.
Forget about it. You don't even know what it's all about and don't 
wanna know.
If it ain't broke, don't fix it.
let's eventually add a FAQ/News entry on the main website (which can be 
done by anyone
with CVS access), but i'm not gonna change anything to that hwdb before 
long.

i'm currently under heavy exam pressure and have really many other thing
to do. Even on parisc stuff. HWDB is currently ranked at level 
"abyssal" in my TODO list
priority order.

That being stated to avoid any post to hwdb@parisc-linux.org. :)

HTH,

Thibaut VARENE
The PA/Linux ESIEE Team
http://pateam.esiee.fr/

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Michael S.Zick]

On Thursday 30 January 2003 09:38 am, Thibaut VARENE wrote:
> On jeudi, jan 30, 2003, at 16:02 Europe/Paris, Randolph Chung wrote:
> >> Who would be a good contact for such a change?
> >
> > there's an email address on many of the hwdb pages
> > (hwdb@parisc-linux.org). That'll be a good place to start. I believe it
> > currently points to Thibaut :)
>
> yes.
>
> quoting Michael S.Zick:
> > "tweaking" a web page or two to make this usage clear
> > to the newcomer might help.
>
> Forget about it. You don't even know what it's all about and don't
> wanna know.
Done

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Grant Grundler]

On Thu, Jan 30, 2003 at 08:45:46AM -0600, Michael S. Zick wrote:
> "tweaking" a web page or two to make this usage clear
> to the newcomer might help.

The goal of the HWDB was to survey what HW each model machine has
so we could write proper support in the kernel.
AFAIK, The people submitting entries didn't sign up to do newbie support.

Keep posting questions to the parisc-linux mailing list and let people
who *want* to answer them do so.

If someone is looking for platform specific install notes, I think
ESIEE has such a web page already. Following links to ESIEE
from www.parisc-linux.org.

> Who would be a good contact for such a change?

In general, Thibaut or myself.
Anyone with CVS *write* permission can change the parisc-linux
web page but most don't touch it.

grant

Re: [parisc-linux] quad tulip now not functional in 2.4.20

[Peter Lavender]

> > Who would be a good contact for such a change?
> 
> In general, Thibaut or myself.
> Anyone with CVS *write* permission can change the parisc-linux
> web page but most don't touch it.

I'll admit to actually putting my hand up quite some time back to take
a look at the hwdb stuff.. but time pressures of part time study,
family etc sort meant I didn't get that far with it.

However, if I can find archive sent to me, I'll try to get it at least
installed here before Uni starts again for me and _try_ to make some
contribution....  but no promises.

Any suggestions etc should be noted somewhere, and the archive I guess
is as good as any, and I'll try getting something sorted out.

But again, don't hold your breath... I did volunteer for this a long
time ago, but it didn't come to anything then either... sorry.. :(

Pete
:wq