linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <willy@w.ods.org>
To: Stephan von Krawczynski <skraw@ithnet.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	netdev@oss.sgi.com, linux-net@vger.kernel.org
Subject: Re: Problem with 2.4.24 e1000 and keepalived
Date: Wed, 7 Jan 2004 22:02:55 +0100	[thread overview]
Message-ID: <20040107210255.GA545@alpha.home.local> (raw)
In-Reply-To: <20040107200556.0d553c40.skraw@ithnet.com>

Hi Stephan,

On Wed, Jan 07, 2004 at 08:05:56PM +0100, Stephan von Krawczynski wrote:
> Setup is a simple pair of routers with 2 nics each, all e1000. If you start a
> vrrp setup with keepalived and interface state is down during keepalived
> startup, then the failover does not work. If the nics are UP during startup
> everything works well. Now the kernel part of the story: the exact same setup
> works with tulip cards.
> Is there a difference regarding UP/DOWN state handling/events in e1000 and
> tulip. e100 and eepro100 show the same problem btw.

I noticed the exact same problem about 1 year ago with the early 2.4
bonding code and eepro100. At this time, I attributed this to a yet
undiscovered but in the bonding state machine, and could not investigate
much since it was on a remote production machine. Someone went there and
rebooted it and everything went OK. Before the reboot, the switch alredy
detected an UP link, while the bonding code saw it down (using MII at this
time, not ethtool). I recently read one report (here or on keepalived list)
about someone who got the same problem with another eepro100. I wonder
whether there would not be a bug either in the driver or in the chip itself.

What I noticed is that if you load the driver while the cable is unplugged,
and then plug it, the MII status says the link is still down. Unfortunately,
the only e100 I have access to are in prod at a customer's and I really
cannot make tests there.

Cheers,
Willy


  reply	other threads:[~2004-01-07 21:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-07 19:05 Problem with 2.4.24 e1000 and keepalived Stephan von Krawczynski
2004-01-07 21:02 ` Willy Tarreau [this message]
2004-01-08  2:45   ` Ben Greear
2004-01-08  5:20     ` Willy Tarreau
2004-01-08  8:07       ` Ben Greear
2004-01-08  8:46         ` Willy Tarreau
2004-01-08  8:14     ` Stephan von Krawczynski
2004-01-08  8:47       ` Willy Tarreau
2004-01-08 17:49         ` Jonathan Lundell
2004-01-09  0:45           ` Willy Tarreau
2004-01-09  1:00             ` Jonathan Lundell
2004-01-09 12:18               ` Stephan von Krawczynski
2004-01-09 18:43                 ` Jonathan Lundell
2004-01-09 23:56                   ` Stephan von Krawczynski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040107210255.GA545@alpha.home.local \
    --to=willy@w.ods.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-net@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    --cc=skraw@ithnet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).