Subject: Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

From: Ondrej Zary <[email-masked]>
Date: Mon, 18 Feb 2008 17:40:42 +0100

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

-- 
Ondrej Zary