From: Ben Greear <greearb@candelatech.com>
To: Willy Tarreau <willy@w.ods.org>
Cc: Stephan von Krawczynski <skraw@ithnet.com>,
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, 07 Jan 2004 18:45:04 -0800 [thread overview]
Message-ID: <3FFCC430.4060804@candelatech.com> (raw)
In-Reply-To: <20040107210255.GA545@alpha.home.local>
Willy Tarreau wrote:
> 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.
You have to bring the interface 'UP' before it will detect link,
with something like: ifconfig eth2 up
Could that be the problem?
Ben
>
> Cheers,
> Willy
>
> -
> 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/
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2004-01-08 2:45 UTC|newest]
Thread overview: 8+ 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
2004-01-08 2:45 ` Ben Greear [this message]
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
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=3FFCC430.4060804@candelatech.com \
--to=greearb@candelatech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=skraw@ithnet.com \
--cc=willy@w.ods.org \
/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).