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

Does the de2104x driver work correctly for anyone?

-- 
Ondrej Zary
--

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

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

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

de2104x is a "work in progress".

No idea. I've only used tulip driver.

thanks for the bug report,
grant
--

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 

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


--

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 

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

I don't think that BUG_ON() should be there. It should probably printk a 


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 

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.




-- 
Ondrej Zary
--

Ah ok - I agree. I'll see if we can fail more gracfully there.


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

thanks,
grant
--

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

applied


--

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

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 



-- 
Ondrej Zary
--

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

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

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

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


--

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

Ondrej would be happy to test any patches sent. Tracking this sort

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