Re: forcedeth ?

[Kay Sievers]

On Tue, 2007-07-31 at 01:10 +0200, Sasa Ostrouska wrote:
> On 7/31/07, Kay Sievers <kay.sievers@xxxxxxxx> wrote:
> >
> > On Tue, 2007-07-31 at 00:19 +0200, Gabriel C wrote:
> > > Kay Sievers wrote:
> > > > On 7/31/07, Sasa Ostrouska <casaxa@xxxxxxxxx> wrote:
> > > >> On 7/31/07, Gabriel C <nix.or.die@xxxxxxxxxxxxxx> wrote:
> > > >>> Sasa Ostrouska wrote:
> > > >>>> On 7/30/07, Avuton Olrich <avuton@xxxxxxxxx> wrote:
> > > >>>>> On 7/30/07, Sasa Ostrouska <casaxa@xxxxxxxxx> 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. :)
> > >
> > > Yes but the rules are based on the MAC address no ?
> >
> > The automatic rule creator, uses MAC addresses by default, yes. There
> > have been extensions for S/390 support recently, to create other sorts
> > of matching rules.
> >
> > The rules that rename the interface, are not limited in any way, and can
> > match on any property of the device, they are just not created
> > automatically today, but can be specified manually.
> >
> > Maybe the network susbsytem should let us know in the event environment,
> > that a random MAC was created, so we can automatically create rules that
> > uses the path to the hardware as a match instead.
> >
> > Thanks,
> > Kay
> >
> And why not just use the PCI ID instead of the MAC address ?

PCI ID's? And when you have multiple identical cards like every other
server has?

You could use the slot number and such, but _usually_ the MAC address is
what you want because it is unique by itself. The MAC is just the best
default in most cases, because it usually identifies the connector where
the cable goes in ...

Udev computes the path to the device, like used in
the /dev/disk/by-path/ links, that could be used as a stable identifier,
but still, to use that automatically, the kernel would need to let us
know, that we shouldn't use the random MAC.

Kay

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/