mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: david@lang.hm
Cc: Sasa Ostrouska <casaxa@gmail.com>,
	Gabriel C <nix.or.die@googlemail.com>,
	Avuton Olrich <avuton@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: forcedeth ?
Date: Tue, 31 Jul 2007 00:32:31 +0200	[thread overview]
Message-ID: <1185834751.1911.57.camel@lov.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0707301522340.12232@asgard.lang.hm>


On Mon, 2007-07-30 at 15:24 -0700, david@lang.hm wrote:
> On Tue, 31 Jul 2007, Kay Sievers wrote:
> 
> > On 7/31/07, Sasa Ostrouska <casaxa@gmail.com> wrote:
> >> On 7/31/07, Gabriel C <nix.or.die@googlemail.com> wrote:
> >>> Sasa Ostrouska wrote:
> >>>> On 7/30/07, Avuton Olrich <avuton@gmail.com> wrote:
> >>>>> On 7/30/07, Sasa Ostrouska <casaxa@gmail.com> wrote:
> >>>>>> Hi people,
> >>>>>>
> >>>>>> I'm using this on a x86-64 amd machine. During boot of the last
> >>>>>> 2.6.22.1 kernel I get this error:
> >>>>> Somewhat unrelated, but I had a similar forcedeth problem, I took the
> >>>>> latest git forcedeth.c and put it into 2.6.22.1 and it worked for me.
> >>>>>
> >>>>> Good luck!
> >>>>> --
> >>>>> avuton
> >>>>
> >>>> Ok, maybe I can try that. In any case I noticed another strange thing.
> >>>> I have 2 nics in that machine.
> >>>> One is a nvidia MPC61 using the forcedeth.c the other one is a Realtec
> >>>> RTL8029 using the
> >>>> ne2k_pci.
> >>>> Now, whenever I compile them both as modules each reboot the cards get
> >>>> inversed eth assignement. Suppose first boot, the forcedeth is eth0 ,
> >>>> the next boot it is eth1 , this is very anoying as one cant make only
> >>>> one boot, probably this is someway related to the bios.
> >>>> Now I configured them one in the kernel and the other as a module so
> >>>> they get each time assigned the same name. But when powerloss happens
> >>>> (unplug the cable) the next boot they do not work. I see them assigned
> >>>> the correct name, ifconfig shows the IP's but ping results in a
> >>>> destination unreachable.
> >>>>
> >>>> Any ideas ?
> >>>
> >>> Udev rules ?
> >>>
> >> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
> >> to check that, thx for the tip.
> >
> > Udev does that already, it automatically creates rules and assigns
> > persistent names to newly discovered network hardware. The names will
> > be stable across reboots, regardless of module loading order or
> > anything else. But sure, that's only on distros who take these issues
> > serious. :)
> 
> what do I need to do to disable this 'feature' having a box with 
> interfaces eth0, eth9, eth10 becouse the box once had a couple of quad 
> cards in it is annoying.

Edit the created rules file and change the entries to the names you
like. 

If you don't like the renaming at all, remove the rules files that
maintain the persistent rules file. But then you have the same problem
if some hardware, or probing order changes.

Kay


  reply	other threads:[~2007-07-30 22:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-30 20:01 Sasa Ostrouska
2007-07-30 20:37 ` Avuton Olrich
2007-07-30 21:26   ` Sasa Ostrouska
2007-07-30 22:03     ` Gabriel C
2007-07-30 22:10       ` Sasa Ostrouska
2007-07-30 22:17         ` Gabriel C
2007-07-31  0:27           ` Krzysztof Halasa
2007-07-31  1:36           ` Carl-Daniel Hailfinger
2007-07-31  1:52             ` Kay Sievers
2007-08-02 11:33               ` Kay Sievers
2007-08-03 16:04                 ` Carl-Daniel Hailfinger
2007-07-30 22:22         ` Kay Sievers
2007-07-30 22:19           ` Gabriel C
2007-07-30 22:40             ` Kay Sievers
2007-07-30 23:10               ` Sasa Ostrouska
2007-07-30 23:36                 ` Kay Sievers
2007-07-30 22:24           ` david
2007-07-30 22:32             ` Kay Sievers [this message]
2007-07-30 22:00 ` Gabriel C

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=1185834751.1911.57.camel@lov.localdomain \
    --to=kay.sievers@vrfy.org \
    --cc=avuton@gmail.com \
    --cc=casaxa@gmail.com \
    --cc=david@lang.hm \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nix.or.die@googlemail.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

all inboxes | Powered by JetHome®