Compex FreedomLine 32 PnP-PCI2 broken with de2104x

Compex FreedomLine 32 PnP-PCI2 broken with de2104x

[Ondrej Zary]

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

-- 
Ondrej Zary

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

[Ondrej Zary]

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.
>
> 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?

-- 
Ondrej Zary

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

[Grant Grundler]

On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote:
> 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().

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().


> > 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.

> > 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.

> > 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.

> > 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

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

[Ondrej Zary]

On Monday 18 February 2008 04:21:11 Grant Grundler wrote:
> On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote:
> > 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().
>
> 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.

> 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().
>
> > > 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.

> > > 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.

>
> > > 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.

>
> > > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Ondrej Zary

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

[Grant Grundler]

On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote:
> On Monday 18 February 2008 04:21:11 Grant Grundler wrote:
> > On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote:
> > > 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().
> >
> > 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.

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.

> > > > 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.
> 
> >
> > > > 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.

> 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

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

[Jeff Garzik]

Grant Grundler wrote:
> On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote:
>> 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

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

[Grant Grundler]

On Mon, Feb 25, 2008 at 02:30:00AM -0500, Jeff Garzik wrote:
> Grant Grundler wrote:
>> On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote:
>>> 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

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.

>     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.

> 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

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

[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 <linux@rainbow-software.org>

--- 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
@@ -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);


-- 
Ondrej Zary

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

[Jeff Garzik]

Ondrej Zary wrote:
> 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 <linux@rainbow-software.org>
> 
> --- 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
> @@ -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...

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

[Grant Grundler]

On Mon, Feb 25, 2008 at 12:52:17PM -0500, Jeff Garzik wrote:
> Ondrej Zary wrote:
>> 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 <linux@rainbow-software.org>
>> --- 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
>> @@ -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...

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

--- 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)
 {
 	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);

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

[Ondrej Zary]

On Monday 24 March 2008 03:45:14 Grant Grundler wrote:
> On Mon, Feb 25, 2008 at 12:52:17PM -0500, Jeff Garzik wrote:
> > Ondrej Zary wrote:
> >> 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 <linux@rainbow-software.org>
> >> --- 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
> >> @@ -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...
>
> 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.


>
> 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)
>  {
>  	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

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

[Grant Grundler]

On Tue, Mar 25, 2008 at 12:02:19AM +0100, Ondrej Zary wrote:
....
> > 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.

> 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

> 
> 
> >
> > 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)
> >  {
> >  	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

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

[Ondrej Zary]

On Wednesday 26 March 2008 16:59:57 Grant Grundler wrote:
> On Tue, Mar 25, 2008 at 12:02:19AM +0100, Ondrej Zary wrote:
> ....
>
> > > 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.

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

>
> > 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
>
> > > 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)
> > >  {
> > >  	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



-- 
Ondrej Zary

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

[Jeff Garzik]

applied

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

[Jeff Garzik]

Grant Grundler wrote:
> 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.


> 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

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

[Ondrej Zary]

On Monday 25 February 2008 08:28:14 Jeff Garzik wrote:
> Grant Grundler wrote:
> > 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.

>
> > 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.

-- 
Ondrej Zary