forcedeth ?

forcedeth ?

[Sasa Ostrouska]

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:

fb0: VESA VGA frame buffer device
Linux agpgart interface v0.102 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
00:0c: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Marvell 88E1101: Registered new driver
Marvell 88E1111: Registered new driver
Marvell 88E1145: Registered new driver
Fixed PHY: Registered new driver
Device 'fixed@100:1' does not have a release() function, it is broken
and must be fixed.
WARNING: at drivers/base/core.c:107 device_release()

Call Trace:
 [<ffffffff802f16c8>] kobject_cleanup+0x52/0x70
 [<ffffffff802f16e6>] kobject_release+0x0/0x9
 [<ffffffff802f237a>] kref_put+0x74/0x82
 [<ffffffff8035c0be>] fixed_mdio_register_device+0x1f3/0x229
 [<ffffffff805884f6>] fixed_init+0x1f/0x35
 [<ffffffff80216e2d>] flat_send_IPI_mask+0x0/0x4c
 [<ffffffff80570910>] kernel_init+0x16f/0x2d5
 [<ffffffff8020a458>] child_rip+0xa/0x12
 [<ffffffff8031763c>] acpi_ds_init_one_object+0x0/0x7f
 [<ffffffff805707a1>] kernel_init+0x0/0x2d5
 [<ffffffff8020a44e>] child_rip+0x0/0x12

Device 'fixed@10:1' does not have a release() function, it is broken
and must be fixed.
WARNING: at drivers/base/core.c:107 device_release()

Call Trace:
 [<ffffffff802f16c8>] kobject_cleanup+0x52/0x70
 [<ffffffff802f16e6>] kobject_release+0x0/0x9
 [<ffffffff802f237a>] kref_put+0x74/0x82
 [<ffffffff8035c0be>] fixed_mdio_register_device+0x1f3/0x229
 [<ffffffff80588507>] fixed_init+0x30/0x35
 [<ffffffff80216e2d>] flat_send_IPI_mask+0x0/0x4c
 [<ffffffff80570910>] kernel_init+0x16f/0x2d5
 [<ffffffff8020a458>] child_rip+0xa/0x12
 [<ffffffff8031763c>] acpi_ds_init_one_object+0x0/0x7f
 [<ffffffff805707a1>] kernel_init+0x0/0x2d5
 [<ffffffff8020a44e>] child_rip+0x0/0x12

forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.60.
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [LMAC] -> GSI 23 (level,
low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:07.0 to 64
forcedeth: using HIGHDMA
eth0: forcedeth.c: subsystem: 01849:03ef bound to 0000:00:07.0
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE-MCP61: IDE controller at PCI slot 0000:00:06.0

If somebody needs some additional info please cc me.

Best Regards
Sasa Ostrouska

Re: forcedeth ?

[Avuton Olrich]

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
--
 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: forcedeth ?

[Sasa Ostrouska]

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 ?

Rgds
Sasa

Re: forcedeth ?

[Gabriel C]

Sasa Ostrouska wrote:
[ added netdev to CC ]
> 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:
> 
> fb0: VESA VGA frame buffer device
> Linux agpgart interface v0.102 (c) Dave Jones
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> 00:0c: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> Marvell 88E1101: Registered new driver
> Marvell 88E1111: Registered new driver
> Marvell 88E1145: Registered new driver
> Fixed PHY: Registered new driver
> Device 'fixed@100:1' does not have a release() function, it is broken
> and must be fixed.
> WARNING: at drivers/base/core.c:107 device_release()
> 
> Call Trace:
>  [<ffffffff802f16c8>] kobject_cleanup+0x52/0x70
>  [<ffffffff802f16e6>] kobject_release+0x0/0x9
>  [<ffffffff802f237a>] kref_put+0x74/0x82
>  [<ffffffff8035c0be>] fixed_mdio_register_device+0x1f3/0x229
>  [<ffffffff805884f6>] fixed_init+0x1f/0x35
>  [<ffffffff80216e2d>] flat_send_IPI_mask+0x0/0x4c
>  [<ffffffff80570910>] kernel_init+0x16f/0x2d5
>  [<ffffffff8020a458>] child_rip+0xa/0x12
>  [<ffffffff8031763c>] acpi_ds_init_one_object+0x0/0x7f
>  [<ffffffff805707a1>] kernel_init+0x0/0x2d5
>  [<ffffffff8020a44e>] child_rip+0x0/0x12
> 
> Device 'fixed@10:1' does not have a release() function, it is broken
> and must be fixed.
> WARNING: at drivers/base/core.c:107 device_release()
> 
> Call Trace:
>  [<ffffffff802f16c8>] kobject_cleanup+0x52/0x70
>  [<ffffffff802f16e6>] kobject_release+0x0/0x9
>  [<ffffffff802f237a>] kref_put+0x74/0x82
>  [<ffffffff8035c0be>] fixed_mdio_register_device+0x1f3/0x229
>  [<ffffffff80588507>] fixed_init+0x30/0x35
>  [<ffffffff80216e2d>] flat_send_IPI_mask+0x0/0x4c
>  [<ffffffff80570910>] kernel_init+0x16f/0x2d5
>  [<ffffffff8020a458>] child_rip+0xa/0x12
>  [<ffffffff8031763c>] acpi_ds_init_one_object+0x0/0x7f
>  [<ffffffff805707a1>] kernel_init+0x0/0x2d5
>  [<ffffffff8020a44e>] child_rip+0x0/0x12
> 
> forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.60.
> ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 23
> ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [LMAC] -> GSI 23 (level,
> low) -> IRQ 23
> PCI: Setting latency timer of device 0000:00:07.0 to 64
> forcedeth: using HIGHDMA
> eth0: forcedeth.c: subsystem: 01849:03ef bound to 0000:00:07.0
> netconsole: not configured, aborting
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> NFORCE-MCP61: IDE controller at PCI slot 0000:00:06.0
> 
> If somebody needs some additional info please cc me.

I got an Oops in 22-git++ with the fixed one but I don't have forcedeth.
There is a patch for it http://lkml.org/lkml/2007/7/18/506.


> 
> Best Regards
> Sasa Ostrouska


Regards,

Gabriel C

Re: forcedeth ?

[Gabriel C]

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 ?

> 
> Rgds
> Sasa

Gabriel

Re: forcedeth ?

[Sasa Ostrouska]

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 ?
>
> >
> > Rgds
> > Sasa
>
> Gabriel
>
Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
to check that, thx for the tip.

Rgds
Sasa

Re: forcedeth ?

[Gabriel C]

Sasa Ostrouska 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.

Yes udev does this based on the MAC address but AFAIK forcedeth is 'special' for some reason 
( which I can really remember now and gets on each boot a new MAC address or alike )

You could try to make your rules based on the pci bus id instead of the MAC address. ( at least I think this should work )

> Rgds
> Sasa
> 

Gabriel

Re: forcedeth ?

[Gabriel C]

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. :)

Yes but the rules are based on the MAC address no ?

> 
> Kay
> 

Gabriel

Re: forcedeth ?

[Kay Sievers]

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. :)

Kay

Re: forcedeth ?

[david]

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.

David Lang

Re: forcedeth ?

[Kay Sievers]

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

Re: forcedeth ?

[Kay Sievers]

On Tue, 2007-07-31 at 00:19 +0200, Gabriel C wrote:
> 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. :)
> 
> 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

Re: forcedeth ?

[Sasa Ostrouska]

On 7/31/07, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> On Tue, 2007-07-31 at 00:19 +0200, Gabriel C wrote:
> > 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. :)
> >
> > 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 ?

Rgds
Sasa

Re: forcedeth ?

[Kay Sievers]

On Tue, 2007-07-31 at 01:10 +0200, Sasa Ostrouska wrote:
> On 7/31/07, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >
> > On Tue, 2007-07-31 at 00:19 +0200, Gabriel C wrote:
> > > 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. :)
> > >
> > > 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

Re: forcedeth ?

[Krzysztof Halasa]

Gabriel C <nix.or.die@googlemail.com> writes:

> Yes udev does this based on the MAC address but AFAIK forcedeth is
> 'special' for some reason 
> ( which I can really remember now and gets on each boot a new MAC
> address or alike )

Must be a bug.
-- 
Krzysztof Halasa

Re: forcedeth ?

[Carl-Daniel Hailfinger]

On 31.07.2007 00:17, Gabriel C wrote:
> Sasa Ostrouska wrote:
>
>> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
>> to check that, thx for the tip.
> 
> Yes udev does this based on the MAC address but AFAIK forcedeth is 'special' for some reason 
> ( which I can really remember now and gets on each boot a new MAC address or alike )

Ah yes, that's a workaround for certain buggy boards to make sure you're
not left without networking even if the MAC address stored on the board
is bogus.

Basically, forcedeth checks if the MAC address supplied by your
mainboard is bogus and autogenerates a random MAC address from a private
range (prefix 00:00:6c) as workaround. However, it will complain loudly
if it has to do that.

Quoting from forcedeth.c:
> if (!is_valid_ether_addr(dev->perm_addr)) {
> 	/*
> 	 * Bad mac address. At least one bios sets the mac address
> 	 * to 01:23:45:67:89:ab
> 	 */
> 	printk(KERN_ERR "%s: Invalid Mac address detected: %02x:%02x:%02x:%02x:%02x:%02x\n",
> 		pci_name(pci_dev),
> 		dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2],
> 		dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]);
> 	printk(KERN_ERR "Please complain to your hardware vendor. Switching to a random MAC.\n");
> 	dev->dev_addr[0] = 0x00;
> 	dev->dev_addr[1] = 0x00;
> 	dev->dev_addr[2] = 0x6c;
> 	get_random_bytes(&dev->dev_addr[3], 3);
> }

Sometimes it helps to update the BIOS and/or set the MAC address which
is printed on the board as MAC address in the BIOS.

Regards,
Carl-Daniel

Re: forcedeth ?

[Kay Sievers]

On 7/31/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
> On 31.07.2007 00:17, Gabriel C wrote:
> > Sasa Ostrouska wrote:
> >
> >> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
> >> to check that, thx for the tip.
> >
> > Yes udev does this based on the MAC address but AFAIK forcedeth is 'special' for some reason
> > ( which I can really remember now and gets on each boot a new MAC address or alike )
>
> Ah yes, that's a workaround for certain buggy boards to make sure you're
> not left without networking even if the MAC address stored on the board
> is bogus.
>
> Basically, forcedeth checks if the MAC address supplied by your
> mainboard is bogus and autogenerates a random MAC address from a private
> range (prefix 00:00:6c) as workaround. However, it will complain loudly
> if it has to do that.
>
> Quoting from forcedeth.c:
> > if (!is_valid_ether_addr(dev->perm_addr)) {
> >       /*
> >        * Bad mac address. At least one bios sets the mac address
> >        * to 01:23:45:67:89:ab
> >        */
> >       printk(KERN_ERR "%s: Invalid Mac address detected: %02x:%02x:%02x:%02x:%02x:%02x\n",
> >               pci_name(pci_dev),
> >               dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2],
> >               dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]);
> >       printk(KERN_ERR "Please complain to your hardware vendor. Switching to a random MAC.\n");
> >       dev->dev_addr[0] = 0x00;
> >       dev->dev_addr[1] = 0x00;
> >       dev->dev_addr[2] = 0x6c;
> >       get_random_bytes(&dev->dev_addr[3], 3);
> > }
>
> Sometimes it helps to update the BIOS and/or set the MAC address which
> is printed on the board as MAC address in the BIOS.

In any case, it would be nice if the network core could add something like:
  MAC_ORIGIN=device
  MAC_ORIGIN=user
  MAC_ORIGIN=random
or whatever makes sense here, to the uevent environment. So userspace
can handle according to that, like falling back using the
bus-slot-number to lookup the persistent name, or whatever is
appropriate.

Thanks,
Kay

Re: forcedeth ?

[Kay Sievers]

On 7/31/07, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On 7/31/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
> > On 31.07.2007 00:17, Gabriel C wrote:
> > > Sasa Ostrouska wrote:
> > >
> > >> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
> > >> to check that, thx for the tip.
> > >
> > > Yes udev does this based on the MAC address but AFAIK forcedeth is 'special' for some reason
> > > ( which I can really remember now and gets on each boot a new MAC address or alike )
> >
> > Ah yes, that's a workaround for certain buggy boards to make sure you're
> > not left without networking even if the MAC address stored on the board
> > is bogus.
> >
> > Basically, forcedeth checks if the MAC address supplied by your
> > mainboard is bogus and autogenerates a random MAC address from a private
> > range (prefix 00:00:6c) as workaround. However, it will complain loudly
> > if it has to do that.
> >
> > Quoting from forcedeth.c:
> > > if (!is_valid_ether_addr(dev->perm_addr)) {
> > >       /*
> > >        * Bad mac address. At least one bios sets the mac address
> > >        * to 01:23:45:67:89:ab
> > >        */
> > >       printk(KERN_ERR "%s: Invalid Mac address detected: %02x:%02x:%02x:%02x:%02x:%02x\n",
> > >               pci_name(pci_dev),
> > >               dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2],
> > >               dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]);
> > >       printk(KERN_ERR "Please complain to your hardware vendor. Switching to a random MAC.\n");
> > >       dev->dev_addr[0] = 0x00;
> > >       dev->dev_addr[1] = 0x00;
> > >       dev->dev_addr[2] = 0x6c;
> > >       get_random_bytes(&dev->dev_addr[3], 3);
> > > }
> >
> > Sometimes it helps to update the BIOS and/or set the MAC address which
> > is printed on the board as MAC address in the BIOS.
>
> In any case, it would be nice if the network core could add something like:
>   MAC_ORIGIN=device
>   MAC_ORIGIN=user
>   MAC_ORIGIN=random
> or whatever makes sense here, to the uevent environment. So userspace
> can handle according to that, like falling back using the
> bus-slot-number to lookup the persistent name, or whatever is
> appropriate.

Can't we use the "locally administered" bit in the MAC address? By
checking for ENV{address}=="?[2367abef]:*", we would skip the
persistent rule generation based on the MAC address?

Thanks,
Kay

Re: forcedeth ?

[Carl-Daniel Hailfinger]

On 02.08.2007 13:33, Kay Sievers wrote:
> On 7/31/07, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On 7/31/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
>>> On 31.07.2007 00:17, Gabriel C wrote:
>>>> Sasa Ostrouska wrote:
>>>>
>>>>> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
>>>>> to check that, thx for the tip.
>>>> Yes udev does this based on the MAC address but AFAIK forcedeth is 'special' for some reason
>>>> ( which I can really remember now and gets on each boot a new MAC address or alike )
>>> Ah yes, that's a workaround for certain buggy boards to make sure you're
>>> not left without networking even if the MAC address stored on the board
>>> is bogus.
>>>
>>> Basically, forcedeth checks if the MAC address supplied by your
>>> mainboard is bogus and autogenerates a random MAC address from a private
>>> range (prefix 00:00:6c) as workaround. However, it will complain loudly
>>> if it has to do that.
>>>
>>> Quoting from forcedeth.c:
>>>> if (!is_valid_ether_addr(dev->perm_addr)) {
>>>>       /*
>>>>        * Bad mac address. At least one bios sets the mac address
>>>>        * to 01:23:45:67:89:ab
>>>>        */
>>>>       printk(KERN_ERR "%s: Invalid Mac address detected: %02x:%02x:%02x:%02x:%02x:%02x\n",
>>>>               pci_name(pci_dev),
>>>>               dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2],
>>>>               dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]);
>>>>       printk(KERN_ERR "Please complain to your hardware vendor. Switching to a random MAC.\n");
>>>>       dev->dev_addr[0] = 0x00;
>>>>       dev->dev_addr[1] = 0x00;
>>>>       dev->dev_addr[2] = 0x6c;
>>>>       get_random_bytes(&dev->dev_addr[3], 3);
>>>> }
>>> Sometimes it helps to update the BIOS and/or set the MAC address which
>>> is printed on the board as MAC address in the BIOS.
>> In any case, it would be nice if the network core could add something like:
>>   MAC_ORIGIN=device
>>   MAC_ORIGIN=user
>>   MAC_ORIGIN=random
>> or whatever makes sense here, to the uevent environment. So userspace
>> can handle according to that, like falling back using the
>> bus-slot-number to lookup the persistent name, or whatever is
>> appropriate.
> 
> Can't we use the "locally administered" bit in the MAC address? By
> checking for ENV{address}=="?[2367abef]:*", we would skip the
> persistent rule generation based on the MAC address?

Yes and no. Theoretically, that would work. However, there are two
problems with your rule specification:
- ENV{address}=="?[13579bdf]:*" are multicast addresses, so you wouldn't
want them tobe part of a network card MAC address at all.
- http://standards.ieee.org/regauth/oui/oui.txt tells us that the
following OIDs would be excluded by your rule:
02-07-01   (hex)                RACAL-DATACOM
02-1C-7C   (hex)                PERQ SYSTEMS CORPORATION
02-60-86   (hex)                LOGIC REPLACEMENT TECH. LTD.
02-60-8C   (hex)                3COM CORPORATION
02-70-01   (hex)                RACAL-DATACOM
02-70-B0   (hex)                M/A-COM INC. COMPANIES
02-70-B3   (hex)                DATA RECALL LTD
02-9D-8E   (hex)                CARDIAC RECORDERS INC.
02-AA-3C   (hex)                OLIVETTI TELECOMM SPA (OLTECO)
02-BB-01   (hex)                OCTOTHORPE CORP.
02-C0-8C   (hex)                3COM CORPORATION
02-CF-1C   (hex)                COMMUNICATION MACHINERY CORP.
02-E6-D3   (hex)                NIXDORF COMPUTER CORPORATION
AA-00-00   (hex)                DIGITAL EQUIPMENT CORPORATION
AA-00-01   (hex)                DIGITAL EQUIPMENT CORPORATION
AA-00-02   (hex)                DIGITAL EQUIPMENT CORPORATION
AA-00-03   (hex)                DIGITAL EQUIPMENT CORPORATION
AA-00-04   (hex)                DIGITAL EQUIPMENT CORPORATION

Since it seems that real OIDs conflict with the "locally adminstered"
bit of the MAC address, I don't see a way to use the MAC address as
indicator for persistent rule eligibility.


Regards,
Carl-Daniel