VIA Rhine ethernet driver bug (reprise...)

VIA Rhine ethernet driver bug (reprise...)

[Udo van den Heuvel]

Hello,

It appears that the VIA Rhine chipset has some sort of bug which shows
up in both the standard Linux VIA-Rhine driver and the Rhinefet driver
that VIA itself provides.

The difference is that the connection is dropped in case of the standard
Linux driver for VIA Rhine but that the connection remains OK with the
Rhinefet driver provided by VIA
(http://www.viaarena.com/downloads/Source/rhinefet.tgz and other places
on viaarena.com...).
So VIA Rhinefet driver consumes more CPU but is also more stable.

I wrote about this issue before: http://lkml.org/lkml/2005/8/7/82 &
http://lkml.org/lkml/2005/1/15/47 etc.
I opened a bugzilla case: http://bugzilla.kernel.org/show_bug.cgi?id=5030

Who could find out why the standard Linux driver chokes and the Rhinefet
driver doesn't? Who could fix this bug?


Kind regards,
Udo

Re: VIA Rhine ethernet driver bug (reprise...)

[Denis Vlasenko]

[CCing maintaner]

On Monday 22 August 2005 20:29, Udo van den Heuvel wrote:
> Hello,
> 
> It appears that the VIA Rhine chipset has some sort of bug which shows
> up in both the standard Linux VIA-Rhine driver and the Rhinefet driver
> that VIA itself provides.
> 
> The difference is that the connection is dropped in case of the standard
> Linux driver for VIA Rhine but that the connection remains OK with the
> Rhinefet driver provided by VIA
> (http://www.viaarena.com/downloads/Source/rhinefet.tgz and other places
> on viaarena.com...).
> So VIA Rhinefet driver consumes more CPU but is also more stable.
> 
> I wrote about this issue before: http://lkml.org/lkml/2005/8/7/82 &
> http://lkml.org/lkml/2005/1/15/47 etc.
> I opened a bugzilla case: http://bugzilla.kernel.org/show_bug.cgi?id=5030
> 
> Who could find out why the standard Linux driver chokes and the Rhinefet
> driver doesn't? Who could fix this bug?

My suggestion was, and still is:

>Since it happens less than once a day, why not just add a code
>to reset the NIC completely in this case, like it is
>typically done in tx_timeout handlers of many NICs, and forget about it?

Do you see any problems in this approach?
--
vda

Re: VIA Rhine ethernet driver bug (reprise...)

[Lee Revell]

On Tue, 2005-08-23 at 12:21 +0300, Denis Vlasenko wrote:
> My suggestion was, and still is:
> 
> >Since it happens less than once a day, why not just add a code
> >to reset the NIC completely in this case, like it is
> >typically done in tx_timeout handlers of many NICs, and forget about
> it?
> 
> Do you see any problems in this approach? 

Yes, hacks like that often causes a long non-preemptible section because
code that was only intended to run on boot now gets hung off a timer and
can run in the middle of real work.

I have an EPIA 6000 with a via Rhine and I've never seen this bug, so it
must be something specific to your network.  Better to find the bug and
fix it rather than add stupid hacks.

Lee

Re: VIA Rhine ethernet driver bug (reprise...)

[Lee Revell]

On Wed, 2005-08-24 at 11:50 -0400, Lee Revell wrote:
> On Tue, 2005-08-23 at 12:21 +0300, Denis Vlasenko wrote:
> > My suggestion was, and still is:


Never mind, I misread the original post.  This workaround is probably OK
if you only do the reset when this error condition arises.

Lee

Re: VIA Rhine ethernet driver bug (reprise...)

[Denis Vlasenko]

On Friday 26 August 2005 06:43, Patrick Draper wrote:
> On 8/23/05, Denis Vlasenko <vda@ilport.com.ua> wrote:
> > >Since it happens less than once a day, why not just add a code
> > >to reset the NIC completely in this case, like it is
> > >typically done in tx_timeout handlers of many NICs, and forget about it?
> >
> > Do you see any problems in this approach?
>
> I've refrained from posting here because my hardware is currently in the
> closet, so I can't help too much. I had problems with Rhine on my ME6000
> (VIA Mini-ITX) board. I tried to reset the NIC by unloading kernel modules
> and reloading them, and reinitializing the network, and that didn't work
> for me. The problem was triggered by merely unplugging the ethernet cable.
> When it was plugged back in, the network was gone and only a reboot would
> bring it back.
>
> Sorry I can't file a better bug report, but I won't be able to until
> November at the earliest. But I thought you should know that at least one
> person can't use the approach of resetting the NIC.

May be a known problem. A buglet in MII common code.
Via-rhine maintainer knows about it, as does Jeff.
--
vda

Re: VIA Rhine ethernet driver bug (reprise...)

[Jeff Garzik]

Denis Vlasenko wrote:
> May be a known problem. A buglet in MII common code.
> Via-rhine maintainer knows about it, as does Jeff.

You don't speak for me, sir.

I know of no such problem.  Please submit a report and/or patch.

	Jeff

Re: VIA Rhine ethernet driver bug (reprise...)

[Roger Luethi]

On Fri, 26 Aug 2005 03:49:25 -0400, Jeff Garzik wrote:
> Denis Vlasenko wrote:
> >May be a known problem. A buglet in MII common code.
> >Via-rhine maintainer knows about it, as does Jeff.
> 
> You don't speak for me, sir.
> 
> I know of no such problem.  Please submit a report and/or patch.

I believe vda may have been referring to this. I can send you the
original thread if it's not in your mail archive.

Roger

------------------------------ cut here ------------------------------
From: Roger Luethi <rl@hellgate.ch>
Subject: Re: via-rhine + link loss + autoneg off == trouble
To: Denis Vlasenko <vda@ilport.com.ua>, Jeff Garzik <jgarzik@pobox.com>
Cc: "David S. Miller" <davem@davemloft.net>, linux-net@vger.kernel.org,
        linux-kernel@vger.kernel.org
Date: Sat, 13 Aug 2005 20:34:21 +0200
User-Agent: Mutt/1.5.8i

Jeff, can you tune in for a moment?

First of all, many thanks to vda for tracking this down, and to everyone
else who helped with it.

I had a look at my code and at 8139cp (which is one of only a handful
of drivers that have been converted to use the generic MII stuff).

Turns out 8139cp doesn't seem to do anything to address the problem
vda described, either, so it is equally affected. Is this something we
should fix in mii.c, or is mii_check_media working as designed? Btw,
I'd be thrilled if someone wrote a few lines per function in mii.c:
purpose, preconditions, side effects, something along these lines.

Roger
------------------------------ cut here ------------------------------

Re: VIA Rhine ethernet driver bug (reprise...)

[Jeff Garzik]

Ah, ok.

The central problem is that the 'forced_media' attribute is intended in 
all respects to force the media into the specified mode. 
Auto-negotiation is disabled, and link is always assumed to be up.

	Jeff

Re: VIA Rhine ethernet driver bug (reprise...)

[Denis Vlasenko]

On Friday 26 August 2005 10:49, Jeff Garzik wrote:
> Denis Vlasenko wrote:
> > May be a known problem. A buglet in MII common code.
> > Via-rhine maintainer knows about it, as does Jeff.
>
> You don't speak for me, sir.
>
> I know of no such problem.  Please submit a report and/or patch.

From: Denis Vlasenko <vda@ilport.com.ua>
To: rl@hellgate.ch,
 "David S. Miller" <davem@davemloft.net>,
 Jeff Garzik <jgarzik@pobox.com>
Subject: via-rhine + link loss + autoneg off == trouble
Date: Thu, 11 Aug 2005 13:50:42 +0300
Cc: linux-net@vger.kernel.org,
 linux-kernel@vger.kernel.org
Message-Id: <200508111350.42435.vda@ilport.com.ua>

I think I finally know what's going on.

Again, the recipe:
* have via-rhine NIC
* unplug network cable
* reboot box
* force HDX (I do in with ethtool -s if autoneg off duplex half)
* plug cable back
* kernel still thinks that carrier is off despite "ethtool if"
  saying that link is detected.

Why:

...
        if (intr_status & IntrLinkChange)
                rhine_check_media(dev, 0);
...

static void rhine_check_media(struct net_device *dev, unsigned int init_media)
{
        struct rhine_private *rp = netdev_priv(dev);
        void __iomem *ioaddr = rp->base;

        mii_check_media(&rp->mii_if, debug, init_media);
...

unsigned int mii_check_media (struct mii_if_info *mii,
                              unsigned int ok_to_print,
                              unsigned int init_media)
{
        unsigned int old_carrier, new_carrier;
        int advertise, lpa, media, duplex;
        int lpa2 = 0;

        /* if forced media, go no further */
        if (mii->force_media)   <============================ HERE
                return 0; /* duplex did not change */

        /* check current and old link status */
        old_carrier = netif_carrier_ok(mii->dev) ? 1 : 0;
        new_carrier = (unsigned int) mii_link_ok(mii);

        /* if carrier state did not change, this is a "bounce",
         * just exit as everything is already set correctly
         */
        if ((!init_media) && (old_carrier == new_carrier))
                return 0; /* duplex did not change */

        /* no carrier, nothing much to do */
        if (!new_carrier) {
                netif_carrier_off(mii->dev);
                if (ok_to_print)
                        printk(KERN_INFO "%s: link down\n", mii->dev->name);
                return 0; /* duplex did not change */
        }

        /*
         * we have carrier, see who's on the other end
         */
        netif_carrier_on(mii->dev);
...

We can never reach netif_carrier_on if mii->force_media == TRUE!

If I disable that "if(...) return 0;" it works.
Instrumented log:

17:54:20.07751 kern.info: qdisc_restart: start, q->dequeue=c03e86c6 <== 
noop_dequeue
17:54:21.07736 kern.info: qdisc_restart: start, q->dequeue=c03e86c6
17:54:23.14445 kern.info: rhine_check_media(init_media:0)
17:54:23.14454 kern.info: mii_check_media
17:54:23.14457 kern.info: mii_check_media: mii->force_media == TRUE, bailing 
DISABLED --vda
17:54:23.14462 kern.info: mii_check_media: old_carrier:0 new_carrier:1
17:54:23.14466 kern.info: mii_check_media: netif_carrier_on
17:54:23.14469 kern.info: if: link up, 10Mbps, half-duplex, lpa 0x0000
17:54:23.14474 kern.info: dev_activate(if);
17:54:23.14477 kern.info: dev_activate(): dev->qdisc = dev->qdisc_sleeping
17:54:24.64489 kern.info: pfifo_fast_enqueue returns 0
17:54:24.64496 kern.info: pfifo_fast_dequeue returns a skb
17:54:24.64499 kern.info: pfifo_fast_dequeue returns NULL
17:54:24.64584 kern.info: pfifo_fast_enqueue returns 0
17:54:24.64588 kern.info: qdisc_restart: start, q->dequeue=c03e87b6 <== 
pfifo_fast_dequeue
17:54:24.64597 kern.info: pfifo_fast_dequeue returns a skb
17:54:24.64601 kern.info: qdisc_restart: skb!=NULL
--
vda