Skip to contentSkip to conversation

quad tulip now not functional in 2.4.20

parisc-linux Ed Schaller 4 participants 13 messages Dec 16, 2002 – Jan 7, 2003 Network drivers

lore
Share & tools
lore
#0 lore raw

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.

Quoted 1 line
Quoted 1 line
Quoted 1 line

------>

--

+-------------+-----------------------+---------------+
| Ed Schaller | Dark Mist Networking  | psuedoshroom  |
+-------------+-----------------------+---------------+
#1 lore raw
Quoted 6 lines · Ed Schaller

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.

Quoted 3 lines

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.

Quoted 1 line

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

Quoted 49 lines

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.

Quoted 1 line
Quoted 1 line
Quoted 1 line

------>

--

+-------------+-----------------------+---------------+
| Ed Schaller | Dark Mist Networking  | psuedoshroom  |
+-------------+-----------------------+---------------+
#2 lore raw
Quoted 6 lines

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 <[email protected]>
+
+ 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 <[email protected]>

* 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&[email protected]&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

drivers/net/tulip/ChangeLog +11 -0
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/ChangeLog linux-2.4.20-pa14/drivers/net/tulip/ChangeLog
@@ -1,3 +1,14 @@
+2002-09-18  Ryan Bradetich  <[email protected]>
+
+	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  <[email protected]>
 
 	* 21142.c (t21142_lnk_change): Revert earlier patch
drivers/net/tulip/eeprom.c +1 -1
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/eeprom.c linux-2.4.20-pa14/drivers/net/tulip/eeprom.c
@@ -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];
drivers/net/tulip/tulip.h +2 -1
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/tulip.h linux-2.4.20-pa14/drivers/net/tulip/tulip.h
@@ -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,
 };
 
 
drivers/net/tulip/tulip_core.c +20 -5
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
@@ -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) {
#3 lore raw
Quoted 1 line · On Tue, Dec 17, 2002 at 08:12:03AM +0100, [email protected] wrote:

Just to avoid you loose time here is a diff:

...

Quoted 3 lines
(quoted diff) +1 -1
-	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

#4 lore raw
Quoted 3 lines

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!

Quoted 1 line
Quoted 1 line
Quoted 1 line

------>

--

+-------------+-----------------------+---------------+
| Ed Schaller | Dark Mist Networking  | psuedoshroom  |
+-------------+-----------------------+---------------+
#5 lore raw
In reply to Grant Grundler

Hi Grant,

Quoted 6 lines · On Tue, Dec 17, 2002 at 08:12:03AM +0100, [email protected] wrote:
Quoted 1 line

Just to avoid you loose time here is a diff:

...

Review

Quoted 2 lines
(quoted diff) +1 -1
-	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

Quoted 7 lines
Quoted 1 line

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

#6 lore raw
In reply to Grant Grundler
Quoted 5 lines

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

Quoted 1 line

In the following dmesg out takes for 2.4.20-pa13 and 2.4.19-32 (debian=

),

Quoted 12 lines
Quoted 2 lines

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.

Quoted 1 line

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

#7 lore raw

Hello Grant,

Quoted 5 lines
Quoted 5 lines

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

Quoted 1 line

In the following dmesg out takes for 2.4.20-pa13 and 2.4.19-32 (debia=

n),

Quoted 12 lines
Quoted 12 lines
Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 7 lines

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

#8 lore raw
Quoted 3 lines · On Tue, Dec 17, 2002 at 04:14:10PM +0100, [email protected] wrote:
Quoted 1 line

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

#9 lore raw

Hi Grant,

Quoted 6 lines · On Tue, Dec 17, 2002 at 04:14:10PM +0100, [email protected] wrote:
Quoted 3 lines
Quoted 1 line

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 ?

Quoted 8 lines

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

#10 lore raw
Quoted 2 lines · On Wed, Dec 18, 2002 at 07:30:40AM +0100, [email protected] wrote:

In eeprom.c I also suspect:
line 193: if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) {

...

Quoted 1 line

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

#11 lore raw
In reply to [email protected]

Joel,

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

Thanks,

- Ryan

Quoted 34 lines · On Tue, 2002-12-17 at 23:30, [email protected] wrote:

Hi Grant,

Quoted 6 lines · On Tue, Dec 17, 2002 at 04:14:10PM +0100, [email protected] wrote:
Quoted 3 lines
Quoted 1 line

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 ?

Quoted 8 lines

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

#12 lore raw
In reply to [email protected]

Hello Grant,

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines

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

Quoted 1 line

In the following dmesg out takes for 2.4.20-pa13 and 2.4.19-32 (debi=

an),

Quoted 17 lines
Quoted 17 lines
Quoted 12 lines
Quoted 2 lines

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.

Quoted 1 line

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)

Quoted 5 lines
Quoted 2 lines

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