Compex FreedomLine 32 PnP-PCI2 broken with de2104x

PATCH Applied Ondrej Zary 3 participants 16 messages Jan 26, 2008 – Mar 26, 2008

Subsystems (2)

Networking Network drivers

lore

Share & tools

lore

Ondrej Zary

author

2008-01-26 20:58 UTC #0 lore raw

Hello,
I was having problems with these FreedomLine cards with Linux before but tested it thoroughly today. This card uses DEC 21041 chip and has TP and BNC connectors:

00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] [1011:0014] (rev 21)

de2104x driver was loaded automatically by udev and card seemed to work. Until I disconnected the TP cable and putting it back after a while. The driver then switched to (non-existing) AUI port and remained there. I tried to set media to TP using ethtool - and the whole kernel crashed because of

        BUG_ON(de_is_running(de));

in de_set_media(). Seems that the driver is unable to stop the DMA in de_stop_rxtx().

I commented out AUI detection in the driver - this time it switched to BNC after unplugging the cable and remained there. I also attempted to reset the chip when de_stop_rxtx failed but failed to do it.

Then I found that there's de4x5 driver which supports the same cards as de2104x (and some other too) - and this one works fine! I can plug and unplug the cable and even change between TP and BNC ports just by unplugging one and plugging the other cable in. Unfortunately, this driver is blacklisted by default - at least in Slackware and Debian.

The question is: why does de2104x exist? Does it work better with some hardware?

BTW. Found that the problem exist at least since 2003:
http://oss.sgi.com/archives/netdev/2003-08/msg00951.html

Signature · 1 line

Ondrej Zary

Ondrej Zary

author

2008-01-30 20:23 UTC #1 lore raw

Quoted 27 lines · On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:

Hello,
I was having problems with these FreedomLine cards with Linux before but tested it thoroughly today. This card uses DEC 21041 chip and has TP and BNC connectors:
00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] [1011:0014] (rev 21)
de2104x driver was loaded automatically by udev and card seemed to work. Until I disconnected the TP cable and putting it back after a while. The driver then switched to (non-existing) AUI port and remained there. I tried to set media to TP using ethtool - and the whole kernel crashed because of BUG_ON(de_is_running(de));
in de_set_media(). Seems that the driver is unable to stop the DMA in de_stop_rxtx().
I commented out AUI detection in the driver - this time it switched to BNC after unplugging the cable and remained there. I also attempted to reset the chip when de_stop_rxtx failed but failed to do it.
Then I found that there's de4x5 driver which supports the same cards as de2104x (and some other too) - and this one works fine! I can plug and unplug the cable and even change between TP and BNC ports just by unplugging one and plugging the other cable in. Unfortunately, this driver is blacklisted by default - at least in Slackware and Debian.

Quoted 5 lines

The question is: why does de2104x exist? Does it work better with some hardware?
BTW. Found that the problem exist at least since 2003:
http://oss.sgi.com/archives/netdev/2003-08/msg00951.html

Does the de2104x driver work correctly for anyone?

Signature · 1 line

Ondrej Zary

Grant Grundler

2008-02-18 03:21 UTC #2 lore raw

Quoted 10 lines · Ondrej Zary

Quoted 9 lines · On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
Hello,
I was having problems with these FreedomLine cards with Linux before but tested it thoroughly today. This card uses DEC 21041 chip and has TP and BNC connectors:
00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] [1011:0014] (rev 21)

Quoted 7 lines

Quoted 7 lines
de2104x driver was loaded automatically by udev and card seemed to work. Until I disconnected the TP cable and putting it back after a while. The driver then switched to (non-existing) AUI port and remained there. I tried to set media to TP using ethtool - and the whole kernel crashed because of BUG_ON(de_is_running(de));
in de_set_media(). Seems that the driver is unable to stop the DMA in de_stop_rxtx().

The BUG_ON() is probably fine normally. But the media selection sounds broken. It's possible to select the wrong media type with 21040 chip but shouldn't be possible with 21041. For 21040 support, see de21040_get_media_info(). But de21041_get_srom_info() is expected to determine which media
types are supported from SEPROM "media blocks". My guess is that code
is broken since it seems to work with de405 driver. If you care to work the difference, I'd be happy to make a patch to fix that up.

Also, from code review, DE2104X driver still has a few places with potential PCI MMIO Write posting issues. Specifically, I was looking in de_stop_hw() and de_set_media(). Several other bits of code correctly flush MMIO writes: e.g. tulip_read_eeprom().

Quoted 3 lines

Quoted 3 lines
I commented out AUI detection in the driver - this time it switched to BNC after unplugging the cable and remained there. I also attempted to reset the chip when de_stop_rxtx failed but failed to do it.

You'd have to basically hardcode only one media type and it's corresponding parameters.

Quoted 5 lines

Quoted 5 lines
Then I found that there's de4x5 driver which supports the same cards as de2104x (and some other too) - and this one works fine! I can plug and unplug the cable and even change between TP and BNC ports just by unplugging one and plugging the other cable in. Unfortunately, this driver is blacklisted by default - at least in Slackware and Debian.

ISTR there was a time when tulip would compete with de4x5 for devices. tulip is the preferred driver. That's clearly no longer the case and perhaps both distro's need to revisit this.

Quoted 2 lines

Quoted 2 lines
The question is: why does de2104x exist? Does it work better with some hardware?

de2104x is a "work in progress".
That's why it's marked "EXPERIMENTAL" in the Kconfig file.

Quoted 4 lines

Quoted 2 lines
BTW. Found that the problem exist at least since 2003:
http://oss.sgi.com/archives/netdev/2003-08/msg00951.html
Does the de2104x driver work correctly for anyone?

No idea. I've only used tulip driver.

thanks for the bug report,
grant

Ondrej Zary

author

2008-02-18 16:40 UTC #3 lore raw

Quoted 19 lines · On Monday 18 February 2008 04:21:11 Grant Grundler wrote:

Quoted 10 lines · Ondrej Zary
Quoted 9 lines · On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
Hello,
I was having problems with these FreedomLine cards with Linux before but tested it thoroughly today. This card uses DEC 21041 chip and has TP and BNC connectors:
00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] [1011:0014] (rev 21)
Quoted 7 lines
Quoted 7 lines
de2104x driver was loaded automatically by udev and card seemed to work. Until I disconnected the TP cable and putting it back after a while. The driver then switched to (non-existing) AUI port and remained there. I tried to set media to TP using ethtool - and the whole kernel crashed because of BUG_ON(de_is_running(de));
in de_set_media(). Seems that the driver is unable to stop the DMA in de_stop_rxtx().

Quoted 8 lines

The BUG_ON() is probably fine normally. But the media selection sounds broken. It's possible to select the wrong media type with 21040 chip but shouldn't be possible with 21041. For 21040 support, see de21040_get_media_info(). But de21041_get_srom_info() is expected to determine which media
types are supported from SEPROM "media blocks". My guess is that code
is broken since it seems to work with de405 driver. If you care to work the difference, I'd be happy to make a patch to fix that up.

I don't think that BUG_ON() should be there. It should probably printk a warning but certainly not crash the whole machine.

Quoted 11 lines

Also, from code review, DE2104X driver still has a few places with potential PCI MMIO Write posting issues. Specifically, I was looking in de_stop_hw() and de_set_media(). Several other bits of code correctly flush MMIO writes: e.g. tulip_read_eeprom().
Quoted 3 lines
Quoted 3 lines
I commented out AUI detection in the driver - this time it switched to BNC after unplugging the cable and remained there. I also attempted to reset the chip when de_stop_rxtx failed but failed to do it.
You'd have to basically hardcode only one media type and it's corresponding parameters.

That's bad. It just works with de4x5 with any cable at any time.

Quoted 9 lines

Quoted 5 lines
Quoted 5 lines
Then I found that there's de4x5 driver which supports the same cards as de2104x (and some other too) - and this one works fine! I can plug and unplug the cable and even change between TP and BNC ports just by unplugging one and plugging the other cable in. Unfortunately, this driver is blacklisted by default - at least in Slackware and Debian.
ISTR there was a time when tulip would compete with de4x5 for devices. tulip is the preferred driver. That's clearly no longer the case and perhaps both distro's need to revisit this.

de4x5 has no MODULE_DEVICE_TABLE for PCI devices anymore, so no conflicts. That's probably good for cards that work with tulip driver but bad for mine card and also probably for some other cards that (should) work with de2104x.

Quoted 6 lines

Quoted 3 lines
Quoted 3 lines
The question is: why does de2104x exist? Does it work better with some hardware?
de2104x is a "work in progress".
That's why it's marked "EXPERIMENTAL" in the Kconfig file.

Great, it looks to be 6 years old and it's still experimental. Probably because it never worked properly.

I think that de2104x driver should be removed (or at least its MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI IDs added to de4x5.

I can send a patch if this is acceptable.

Quoted 15 lines

Quoted 5 lines
Quoted 3 lines
BTW. Found that the problem exist at least since 2003:
http://oss.sgi.com/archives/netdev/2003-08/msg00951.html
Does the de2104x driver work correctly for anyone?
No idea. I've only used tulip driver.
thanks for the bug report,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 1 line

Ondrej Zary

Grant Grundler

2008-02-25 07:15 UTC #4 lore raw

Quoted 29 lines · Ondrej Zary

Quoted 19 lines · On Monday 18 February 2008 04:21:11 Grant Grundler wrote:
Quoted 10 lines · Ondrej Zary
Quoted 9 lines · On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
Hello,
I was having problems with these FreedomLine cards with Linux before but tested it thoroughly today. This card uses DEC 21041 chip and has TP and BNC connectors:
00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] [1011:0014] (rev 21)
Quoted 7 lines
Quoted 7 lines
de2104x driver was loaded automatically by udev and card seemed to work. Until I disconnected the TP cable and putting it back after a while. The driver then switched to (non-existing) AUI port and remained there. I tried to set media to TP using ethtool - and the whole kernel crashed because of BUG_ON(de_is_running(de));
in de_set_media(). Seems that the driver is unable to stop the DMA in de_stop_rxtx().
Quoted 8 lines
The BUG_ON() is probably fine normally. But the media selection sounds broken. It's possible to select the wrong media type with 21040 chip but shouldn't be possible with 21041. For 21040 support, see de21040_get_media_info(). But de21041_get_srom_info() is expected to determine which media
types are supported from SEPROM "media blocks". My guess is that code
is broken since it seems to work with de405 driver. If you care to work the difference, I'd be happy to make a patch to fix that up.

Quoted 2 lines

I don't think that BUG_ON() should be there. It should probably printk a warning but certainly not crash the whole machine.

Ah ok - I agree. I'll see if we can fail more gracfully there. If you have an idea already, please send me a patch.

Quoted 15 lines

Quoted 9 lines
Quoted 5 lines
Quoted 5 lines
Then I found that there's de4x5 driver which supports the same cards as de2104x (and some other too) - and this one works fine! I can plug and unplug the cable and even change between TP and BNC ports just by unplugging one and plugging the other cable in. Unfortunately, this driver is blacklisted by default - at least in Slackware and Debian.
ISTR there was a time when tulip would compete with de4x5 for devices. tulip is the preferred driver. That's clearly no longer the case and perhaps both distro's need to revisit this.
de4x5 has no MODULE_DEVICE_TABLE for PCI devices anymore, so no conflicts. That's probably good for cards that work with tulip driver but bad for mine card and also probably for some other cards that (should) work with de2104x.
Quoted 1 line

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
The question is: why does de2104x exist? Does it work better with some hardware?
de2104x is a "work in progress".
That's why it's marked "EXPERIMENTAL" in the Kconfig file.
Great, it looks to be 6 years old and it's still experimental. Probably because it never worked properly.

Yeah, probably.

Quoted 5 lines

I think that de2104x driver should be removed (or at least its MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI IDs added to de4x5.
I can send a patch if this is acceptable.

It's acceptable to me. Jeff? (jgarzik)

thanks,
grant

Jeff Garzik

NAK

2008-02-25 07:30 UTC #5 lore raw

Quoted 6 lines · Grant Grundler

Quoted 3 lines · Ondrej Zary
I think that de2104x driver should be removed (or at least its MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI IDs added to de4x5.
I can send a patch if this is acceptable.
It's acceptable to me. Jeff? (jgarzik)

NAK, sorry, for two reasons:

1) we don't delete otherwise clean, working drivers simply because of a bug triggered by unplugging a cable.

2) de4x5 needs to go away.

Jeff

Grant Grundler

2008-02-26 07:48 UTC #6 lore raw

Quoted 6 lines · Jeff Garzik

Quoted 5 lines · Grant Grundler
Quoted 4 lines · Ondrej Zary
I think that de2104x driver should be removed (or at least its MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI IDs added to de4x5.

Quoted 6 lines

Quoted 2 lines
Quoted 1 line
I can send a patch if this is acceptable.
It's acceptable to me. Jeff? (jgarzik)
NAK, sorry, for two reasons:
1) we don't delete otherwise clean, working drivers

Just to be clear - he's not trying to remove the driver.
He's just interested in making de4x5 the "default" for this set of boards by doctoring with the pci device ids each driver will claim.

Quoted 1 line

simply because of a bug triggered by unplugging a cable.

Ondrej would be happy to test any patches sent. Tracking this sort of bug down usually isn't trivial as the statement above implies.

Quoted 1 line

2) de4x5 needs to go away.

Ok. I'd prefer to wait until someone demonstrates de2104x driver is a fully functional alternative for all the PCI Ids it claims.

thanks,
grant

Ondrej Zary

author

2008-02-25 17:46 UTC #7 lore raw

PATCH 1/1 de2104x: remove BUG_ON() when changing media type

In reply to Grant Grundler

When the chip dies (probably because of a bug somewhere in the driver), de_stop_rxtx() fails and changing the media type crashes the whole machine. Replace BUG_ON() in de_set_media() with a warning.

Signed-off-by Ondrej Zary <[email protected]>

drivers/net/tulip/de2104x.c +2 -1

@@ -910,7 +910,8 @@
 	unsigned media = de->media_type;
 	u32 macmode = dr32(MacMode);
 
-	BUG_ON(de_is_running(de));
+	if (de_is_running(de))
+		printk(KERN_WARNING "%s: chip is running while changing media!\n", de->dev->name);
 
 	if (de->de21040)
 		dw32(CSR11, FULL_DUPLEX_MAGIC);

Signature · 1 line

Ondrej Zary

Jeff Garzik

2008-02-25 17:52 UTC #8 lore raw

Re: [PATCH] de2104x: remove BUG_ON() when changing media type

drivers/net/tulip/de2104x.c line 914

Quoted 13 lines · Ondrej Zary

When the chip dies (probably because of a bug somewhere in the driver), de_stop_rxtx() fails and changing the media type crashes the whole machine. Replace BUG_ON() in de_set_media() with a warning.
Signed-off-by Ondrej Zary <[email protected]>
drivers/net/tulip/de2104x.c +2 -1
@@ -910,7 +910,8 @@
 	unsigned media = de->media_type;
 	u32 macmode = dr32(MacMode);
 
-	BUG_ON(de_is_running(de));
+	if (de_is_running(de))
+		printk(KERN_WARNING "%s: chip is running while changing media!\n", de->dev->name);

Certainly a sane improvement...

Grant Grundler

2008-03-24 02:45 UTC #9 lore raw

Re: [PATCH] de2104x: remove BUG_ON() when changing media type

Quoted 10 lines · Jeff Garzik

Quoted 9 lines · Ondrej Zary
When the chip dies (probably because of a bug somewhere in the driver), de_stop_rxtx() fails and changing the media type crashes the whole machine. Replace BUG_ON() in de_set_media() with a warning.
Signed-off-by Ondrej Zary <[email protected]>
--- linux-2.6.24-orig/drivers/net/tulip/de2104x.c 2008-02-25
18:27:34.000000000 +0100
+++ linux-2.6.24-pentium/drivers/net/tulip/de2104x.c 2008-02-25
18:34:56.000000000 +0100
(quoted diff) +0 -0
@@ -910,7 +910,8 @@

Quoted 8 lines

Review line 915

Quoted 6 lines

(quoted diff) +2 -0

 	unsigned media = de->media_type;
 	u32 macmode = dr32(MacMode);
 -	BUG_ON(de_is_running(de));
+	if (de_is_running(de))
+		printk(KERN_WARNING "%s: chip is running while changing media!\n", 
 de->dev->name);

Certainly a sane improvement...

Jeff,
The above patch was applied and fixes the 'panic' part of the problme. Can you take a look at this patch to fix the "chip is still running" part of this bug?

BTW, I inherited a bug report for the same symptom:

    http://bugzilla.kernel.org/show_bug.cgi?id=3156

thanks,
grant

Signed-off-by Grant Grundler

drivers/net/tulip/de2104x.c-ggg renamed from drivers/net/tulip/de2104x.c +7 -3

@@ -842,7 +842,7 @@
 static void de_stop_rxtx (struct de_private *de)
 {
 	u32 macmode;
-	unsigned int work = 1000;
+	unsigned int i = 1300/100;
 
 	macmode = dr32(MacMode);
 	if (macmode & RxTx) {

@@ -850,10 +850,14 @@
 		dr32(MacMode);
 	}
 
-	while (--work > 0) {
+	/* wait until in-flight frame completes.
+	 * Max time @ 10BT: 1500*8b/10Mbps == 1200us (+ 100us margin)
+	 * Typically expect this loop to end in < 50 us on 100BT.
+	 */
+	while (--i) {
 		if (!de_is_running(de))
 			return;
-		cpu_relax();
+		udelay(100);
 	}
 
 	printk(KERN_WARNING "%s: timeout expired stopping DMA\n", de->dev->name);

Ondrej Zary

author

2008-03-24 23:02 UTC #10 lore raw

Re: [PATCH] de2104x: remove BUG_ON() when changing media type

Quoted 20 lines · On Monday 24 March 2008 03:45:14 Grant Grundler wrote:

Quoted 10 lines · Jeff Garzik
Quoted 9 lines · Ondrej Zary
When the chip dies (probably because of a bug somewhere in the driver), de_stop_rxtx() fails and changing the media type crashes the whole machine. Replace BUG_ON() in de_set_media() with a warning.
Signed-off-by Ondrej Zary <[email protected]>
--- linux-2.6.24-orig/drivers/net/tulip/de2104x.c 2008-02-25
18:27:34.000000000 +0100
+++ linux-2.6.24-pentium/drivers/net/tulip/de2104x.c 2008-02-25
18:34:56.000000000 +0100
(quoted diff) +0 -0
@@ -910,7 +910,8 @@
Quoted 8 lines
Review line 915
Quoted 6 lines
(quoted diff) +2 -0
 	unsigned media = de->media_type;
 	u32 macmode = dr32(MacMode);
 -	BUG_ON(de_is_running(de));
+	if (de_is_running(de))
+		printk(KERN_WARNING "%s: chip is running while changing media!\n",
 de->dev->name);
Certainly a sane improvement...

Quoted 4 lines

Jeff,
The above patch was applied and fixes the 'panic' part of the problme. Can you take a look at this patch to fix the "chip is still running" part of this bug?

I'll test it but I doubt that it fixes the problem. IIRC, I tried something like that. Even tried resetting the chip multiple times when this problem appears but everything failed.

Quoted 37 lines

BTW, I inherited a bug report for the same symptom:
    http://bugzilla.kernel.org/show_bug.cgi?id=3156
thanks,
grant
Signed-off-by Grant Grundler
--- linux-2.6.23/drivers/net/tulip/de2104x.c 2007-10-09 13:31:38.000000000
-0700 +++ linux-2.6.23/drivers/net/tulip/de2104x.c-ggg 2007-11-02
23:24:46.000000000 -0700 @@ -842,7 +842,7 @@
static void de_stop_rxtx (struct de_private *de)
{
drivers/net/tulip/de2104x.c-ggg renamed from drivers/net/tulip/de2104x.c +7 -3
 	u32 macmode;
-	unsigned int work = 1000;
+	unsigned int i = 1300/100;
 
 	macmode = dr32(MacMode);
 	if (macmode & RxTx) {
@@ -850,10 +850,14 @@
 		dr32(MacMode);
 	}
 
-	while (--work > 0) {
+	/* wait until in-flight frame completes.
+	 * Max time @ 10BT: 1500*8b/10Mbps == 1200us (+ 100us margin)
+	 * Typically expect this loop to end in < 50 us on 100BT.
+	 */
+	while (--i) {
 		if (!de_is_running(de))
 			return;
-		cpu_relax();
+		udelay(100);
 	}
 
 	printk(KERN_WARNING "%s: timeout expired stopping DMA\n", de->dev->name);

Signature · 1 line

Ondrej Zary

Grant Grundler

2008-03-26 16:00 UTC #11 lore raw

Re: [PATCH] de2104x: remove BUG_ON() when changing media type

On Tue, Mar 25, 2008 at 12:02:19AM +0100, Ondrej Zary wrote:
....

Quoted 7 lines

Quoted 4 lines
Jeff,
The above patch was applied and fixes the 'panic' part of the problme. Can you take a look at this patch to fix the "chip is still running" part of this bug?
I'll test it but I doubt that it fixes the problem. IIRC, I tried something like that.

Thanks (in advance) for testing!

This patch fixed the same symptom for tulip driver many years ago. It's been validated already and should be applied to de2104x driver too.

If it doesn't fix the problem, that just means something else is going wrong as well.

Quoted 2 lines

Even tried resetting the chip multiple times when this problem appears but everything failed.

Can you print the last value from dr32(MacStatus)? (just append the output to the "stopping DMA" printk)

If resetting the chip isn't working, my guess is the PCI bus is out to lunch. Getting ~0 back on the MMIO read would be evidence of that. But resetting the chip isn't trivial and all sorts of things could go wrong with that.

thanks,
grant

Quoted 44 lines

Quoted 39 lines
BTW, I inherited a bug report for the same symptom:
    http://bugzilla.kernel.org/show_bug.cgi?id=3156
thanks,
grant
Signed-off-by Grant Grundler
--- linux-2.6.23/drivers/net/tulip/de2104x.c 2007-10-09 13:31:38.000000000
-0700 +++ linux-2.6.23/drivers/net/tulip/de2104x.c-ggg 2007-11-02
23:24:46.000000000 -0700 @@ -842,7 +842,7 @@
static void de_stop_rxtx (struct de_private *de)
{
drivers/net/tulip/de2104x.c-ggg renamed from drivers/net/tulip/de2104x.c +7 -3
 	u32 macmode;
-	unsigned int work = 1000;
+	unsigned int i = 1300/100;
 
 	macmode = dr32(MacMode);
 	if (macmode & RxTx) {
@@ -850,10 +850,14 @@
 		dr32(MacMode);
 	}
 
-	while (--work > 0) {
+	/* wait until in-flight frame completes.
+	 * Max time @ 10BT: 1500*8b/10Mbps == 1200us (+ 100us margin)
+	 * Typically expect this loop to end in < 50 us on 100BT.
+	 */
+	while (--i) {
 		if (!de_is_running(de))
 			return;
-		cpu_relax();
+		udelay(100);
 	}
 
 	printk(KERN_WARNING "%s: timeout expired stopping DMA\n", de->dev->name);
Signature · 1 line
Ondrej Zary

Ondrej Zary

author

2008-03-26 18:30 UTC #12 lore raw

Re: [PATCH] de2104x: remove BUG_ON() when changing media type

Quoted 11 lines · On Wednesday 26 March 2008 16:59:57 Grant Grundler wrote:

On Tue, Mar 25, 2008 at 12:02:19AM +0100, Ondrej Zary wrote:
....
Quoted 7 lines
Quoted 4 lines
Jeff,
The above patch was applied and fixes the 'panic' part of the problme. Can you take a look at this patch to fix the "chip is still running" part of this bug?
I'll test it but I doubt that it fixes the problem. IIRC, I tried something like that.

Quoted 7 lines

Thanks (in advance) for testing!
This patch fixed the same symptom for tulip driver many years ago. It's been validated already and should be applied to de2104x driver too.
If it doesn't fix the problem, that just means something else is going wrong as well.

As I expected, it did not fix the problem. This time, I used only BNC cable. Let ping run, disconnect the cable, change the media type a couple of times and it dies. When "timeout expired stopping DMA" appears, the card is dead until the module is reloaded.

de2104x PCI Ethernet driver v0.7 (Mar 17, 2004)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11

de0: SROM leaf offset 30, default media 10baseT auto
de0:   media block #0: BNC
de0:   media block #1: AUI
de0:   media block #2: 10baseT-FD
de0:   media block #3: 10baseT-HD
eth1: 21041 at 0xd1084000, 00:80:48:ea:eb:0a, IRQ 11
eth1: enabling interface
eth1: set link 10baseT auto
eth1:    mode 0x7ffc0040, sia 0x10c4,0xffffef01,0xffffffff,0xffff0008
eth1:    set mode 0x7ffc0040, set sia 0xef01,0xffff,0x8
eth1: set link AUI
eth1:    mode 0x7ffc0000, sia 0x10c4,0xffffef09,0xfffff7fd,0xffff000e
eth1:    set mode 0x7ffc0000, set sia 0xef09,0xf7fd,0xe
eth1: link up, media AUI
eth1: link down
eth1: set link 10baseT auto
eth1:    mode 0x7ffc0000, sia 0x10c4,0xffffef01,0xffffffff,0xffff0008
eth1:    set mode 0x7ffc0000, set sia 0xef01,0xffff,0x8
eth1: set link AUI
eth1:    mode 0x7ffc0000, sia 0x10c4,0xffffef09,0xfffff7fd,0xffff000e
eth1:    set mode 0x7ffc0000, set sia 0xef09,0xf7fd,0xe
eth1: link up, media AUI
eth1: link down
eth1: timeout expired stopping DMA
eth1: chip is running while changing media!
eth1: set link 10baseT auto
eth1:    mode 0x7ffc0000, sia 0x10c4,0xffffef01,0xffffffff,0xffff0008
eth1:    set mode 0x7ffc0000, set sia 0xef01,0xffff,0x8
eth1: timeout expired stopping DMA
eth1: chip is running while changing media!
eth1: set link AUI
eth1:    mode 0x7ffc0000, sia 0x11c4,0xffffef09,0xfffff7fd,0xffff000e
eth1:    set mode 0x7ffc0000, set sia 0xef09,0xf7fd,0xe
eth1: set link BNC
eth1:    mode 0x7ffc0000, sia 0x10c4,0xffffef09,0xfffff7fd,0xffff0006
eth1:    set mode 0x7ffc0000, set sia 0xef09,0xf7fd,0x6
eth1: link up, media BNC
eth1: link down
eth1: set link AUI
eth1:    mode 0x7ffc0000, sia 0x10c4,0xffffef09,0xfffff7fd,0xffff000e
eth1:    set mode 0x7ffc0000, set sia 0xef09,0xf7fd,0xe

Quoted 56 lines

Quoted 3 lines
Even tried resetting the chip multiple times when this problem appears but everything failed.
Can you print the last value from dr32(MacStatus)? (just append the output to the "stopping DMA" printk)
If resetting the chip isn't working, my guess is the PCI bus is out to lunch. Getting ~0 back on the MMIO read would be evidence of that. But resetting the chip isn't trivial and all sorts of things could go wrong with that.
thanks,
grant
Quoted 41 lines
Quoted 37 lines
BTW, I inherited a bug report for the same symptom:
    http://bugzilla.kernel.org/show_bug.cgi?id=3156
thanks,
grant
Signed-off-by Grant Grundler
--- linux-2.6.23/drivers/net/tulip/de2104x.c 2007-10-09
13:31:38.000000000 -0700 +++
linux-2.6.23/drivers/net/tulip/de2104x.c-ggg 2007-11-02
23:24:46.000000000 -0700 @@ -842,7 +842,7 @@
static void de_stop_rxtx (struct de_private *de)
{
drivers/net/tulip/de2104x.c-ggg renamed from drivers/net/tulip/de2104x.c +7 -3
 	u32 macmode;
-	unsigned int work = 1000;
+	unsigned int i = 1300/100;
 
 	macmode = dr32(MacMode);
 	if (macmode & RxTx) {
@@ -850,10 +850,14 @@
 		dr32(MacMode);
 	}
 
-	while (--work > 0) {
+	/* wait until in-flight frame completes.
+	 * Max time @ 10BT: 1500*8b/10Mbps == 1200us (+ 100us margin)
+	 * Typically expect this loop to end in < 50 us on 100BT.
+	 */
+	while (--i) {
 		if (!de_is_running(de))
 			return;
-		cpu_relax();
+		udelay(100);
 	}
 
 	printk(KERN_WARNING "%s: timeout expired stopping DMA\n",
Quoted 1 line
de->dev->name);
--
Ondrej Zary

Signature · 1 line

Ondrej Zary

Jeff Garzik

Applied

2008-03-05 11:28 UTC #13 lore raw

Re: [PATCH] de2104x: remove BUG_ON() when changing media type

In reply to Ondrej Zary

applied

Jeff Garzik

2008-02-25 07:28 UTC #14 lore raw

In reply to Grant Grundler

Quoted 3 lines · Grant Grundler

ISTR there was a time when tulip would compete with de4x5 for devices. tulip is the preferred driver. That's clearly no longer the case and perhaps both distro's need to revisit this.

The only reason why de4x5 still exists is that the /tulip/ driver fails to work on a few chips like the 21142 (43?) shipped in various alpha boxen.

de4x5 needs to go away, it's been unmaintained for ages, doesn't support any of the new hotplug APIs.

Quoted 2 lines

de2104x is a "work in progress".
That's why it's marked "EXPERIMENTAL" in the Kconfig file.

It's not a work in progress, it works just fine for most people (the few that are left).

Last I heard, there was a problem with non-twisted-pair stuff, but that's about it.

'experimental' is generally a poorly maintained marker.

Jeff

Ondrej Zary

author

2008-02-25 21:31 UTC #15 lore raw

Quoted 10 lines · On Monday 25 February 2008 08:28:14 Jeff Garzik wrote:

Quoted 3 lines · Grant Grundler
ISTR there was a time when tulip would compete with de4x5 for devices. tulip is the preferred driver. That's clearly no longer the case and perhaps both distro's need to revisit this.
The only reason why de4x5 still exists is that the /tulip/ driver fails to work on a few chips like the 21142 (43?) shipped in various alpha boxen.
de4x5 needs to go away, it's been unmaintained for ages, doesn't support any of the new hotplug APIs.

But has extensive port auto-detection which seems to work great (at least on my card). I don't feel like porting that code to de2104x - the code looks complex.

Quoted 11 lines

Quoted 3 lines
de2104x is a "work in progress".
That's why it's marked "EXPERIMENTAL" in the Kconfig file.
It's not a work in progress, it works just fine for most people (the few that are left).
Last I heard, there was a problem with non-twisted-pair stuff, but that's about it.
'experimental' is generally a poorly maintained marker.

So we have two unmaintained drivers - one that works fine (and is production quality - or at least seems to be) but does not support hotplug APIs and one that was never finished (the TP-unplug problem is present at least since 2003).
Perhaps de4x5 could be ported to new API(s)? I think that it's much easier than fixing obscure hardware-related problems like cable auto-detection.

Signature · 1 line

Ondrej Zary