2007-09-04 17:14:31

by davide rossetti

[permalink] [raw]
Subject: origin of __tmp1930643048 network device name: kernel-space or user-space

dear all,
I'm trying to track down a problem on a Sun V40Z server with 4 network
devices grabbing random ethX device names. now, trying to force the
device names to what I want, I got a __tmpXXXXX form of device name,
which I think is a half-configured device... but which piece of
software is to blame ??? kernel, udev, hotplug

it is a Fedora Core 6, fully updated (kernel-2.6.22.2-42.fc6
udev-095-17.fc6.x86_64)

ifconfig reports it as:
__tmp1930643048 Link encap:Ethernet HWaddr 00:04:23:CA:BC:CB
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Base address:0x3040 Memory:e70a0000-e70c0000

bond0 Link encap:Ethernet HWaddr 00:04:23:CA:BC:CA
inet addr:10.0.0.139 Bcast:10.0.255.255 Mask:255.255.0.0
inet6 addr: fe80::204:23ff:feca:bcca/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:7409 errors:0 dropped:0 overruns:0 frame:0
TX packets:3855 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1300152 (1.2 MiB) TX bytes:509271 (497.3 KiB)

eth1 Link encap:Ethernet HWaddr 00:04:23:CA:BC:CA
inet6 addr: fe80::204:23ff:feca:bcca/64 Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:7409 errors:0 dropped:0 overruns:0 frame:0
TX packets:3855 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1300152 (1.2 MiB) TX bytes:509271 (497.3 KiB)
Base address:0x3000 Memory:e7080000-e70a0000
....

help appreciated... so much :(

davide

--
[email protected] ICQ:290677265 SKYPE:d.rossetti


--
[email protected] ICQ:290677265 SKYPE:d.rossetti


2007-09-04 20:50:55

by Kay Sievers

[permalink] [raw]
Subject: Re: origin of __tmp1930643048 network device name: kernel-space or user-space

On 9/4/07, davide rossetti <[email protected]> wrote:
> I'm trying to track down a problem on a Sun V40Z server with 4 network
> devices grabbing random ethX device names. now, trying to force the
> device names to what I want, I got a __tmpXXXXX form of device name,
> which I think is a half-configured device... but which piece of
> software is to blame ??? kernel, udev, hotplug
>
> it is a Fedora Core 6, fully updated (kernel-2.6.22.2-42.fc6
> udev-095-17.fc6.x86_64)

I don't think any of the mentioned tools is to blame. Please use the
distro's bugtracker.

Thanks,
Kay

2007-09-06 12:49:27

by Jan Engelhardt

[permalink] [raw]
Subject: Re: origin of __tmp1930643048 network device name: kernel-space or user-space


On Sep 4 2007 19:14, davide rossetti wrote:
>
>dear all,
>I'm trying to track down a problem on a Sun V40Z server with 4 network
>devices grabbing random ethX device names. now, trying to force the
>device names to what I want, I got a __tmpXXXXX form of device name,
>which I think is a half-configured device... but which piece of
>software is to blame ??? kernel, udev, hotplug


Look into dmesg. If the device was once known as ethX or similar,
then it is userspace to blame.



Jan
--

2007-09-06 13:38:19

by Bill Nottingham

[permalink] [raw]
Subject: Re: origin of __tmp1930643048 network device name: kernel-space or user-space

Jan Engelhardt ([email protected]) said:
> >dear all,
> >I'm trying to track down a problem on a Sun V40Z server with 4 network
> >devices grabbing random ethX device names. now, trying to force the
> >device names to what I want, I got a __tmpXXXXX form of device name,
> >which I think is a half-configured device... but which piece of
> >software is to blame ??? kernel, udev, hotplug
>
> Look into dmesg. If the device was once known as ethX or similar,
> then it is userspace to blame.

It's userspace.

<off-topic for l-k, but while I'm here...>

I'm assuming you're running some sort of Fedora/RHEL/
derivative; this is what you get when you have a device that starts
out named ethX, but which needed to be renamed so that an already
configured ethX could be changed to that name.

For the new device, either add a HWADDR in a ifcfg-ethX file for
that interface, add something to /etc/mactab, or add a udev rule.

Bill

2007-09-06 15:02:56

by davide rossetti

[permalink] [raw]
Subject: Re: origin of __tmp1930643048 network device name: kernel-space or user-space

On 9/6/07, Bill Nottingham <[email protected]> wrote:
> Jan Engelhardt ([email protected]) said:
> > >dear all,
> > >I'm trying to track down a problem on a Sun V40Z server with 4 network
> > >devices grabbing random ethX device names. now, trying to force the
> > >device names to what I want, I got a __tmpXXXXX form of device name,
> > >which I think is a half-configured device... but which piece of
> > >software is to blame ??? kernel, udev, hotplug
> >
> > Look into dmesg. If the device was once known as ethX or similar,
> > then it is userspace to blame.
>
> It's userspace.

while we are at it.... could you briefly help me describe the 'code
sequence' involved in the naming of an interface ? with it we could
write a small doc...

for instance I'm tracking tg3.c code as:
alloc_etherdev()
--> sets net_device->name="eth%d"

register_netdev()
--> register_netdevice()
--> netdev_register_sysfs(struct net_device *net)
struct device *dev = &(net->dev)
dev->class = &net_class
--> device_add(dev)

here I stopped... but I guess that device_add builds and event for udev.

anyway, on my system it produces such a sysfs device:

$> udevinfo -p /sys/class/net/__tmp1930643048 -a
looking at device '/class/net/__tmp1930643048':
KERNEL=="__tmp1930643048"
SUBSYSTEM=="net"
SYSFS{weight}=="64"
SYSFS{tx_queue_len}=="1000"
SYSFS{flags}=="0x1002"
SYSFS{mtu}=="1500"
SYSFS{operstate}=="down"
SYSFS{broadcast}=="ff:ff:ff:ff:ff:ff"
SYSFS{address}=="00:04:23:ca:bc:cb"
SYSFS{link_mode}=="0"
SYSFS{type}=="1"
SYSFS{features}=="0x113a9"
SYSFS{ifindex}=="5"
SYSFS{iflink}=="5"
SYSFS{addr_len}=="6"

> <off-topic for l-k, but while I'm here...>
>
> I'm assuming you're running some sort of Fedora/RHEL/
> derivative; this is what you get when you have a device that starts
> out named ethX, but which needed to be renamed so that an already
> configured ethX could be changed to that name.

yes, it's FC6.

> For the new device, either add a HWADDR in a ifcfg-ethX file for
> that interface, add something to /etc/mactab, or add a udev rule.

seems like HWADDR is incompatible with bonding.... there is some
message using HWADDR as well as MASTER=bond0 and SLAVE=yes.

davide

--
[email protected] ICQ:290677265 SKYPE:d.rossetti

2007-09-07 16:44:39

by davide rossetti

[permalink] [raw]
Subject: Re: origin of __tmp1930643048 network device name: kernel-space or user-space

> > I'm assuming you're running some sort of Fedora/RHEL/
> > derivative; this is what you get when you have a device that starts
> > out named ethX, but which needed to be renamed so that an already
> > configured ethX could be changed to that name.
>
> yes, it's FC6.
>
> > For the new device, either add a HWADDR in a ifcfg-ethX file for
> > that interface, add something to /etc/mactab, or add a udev rule.
>
> seems like HWADDR is incompatible with bonding.... there is some
> message using HWADDR as well as MASTER=bond0 and SLAVE=yes.

for the records I worked-around it:
- problem seems to be the interface 'bond0', which is started first,
stops the ability to create another device named 'eth0' (WHY?)
- so I shifted all of the interface names: 0->1, 1->2,...
now it is ok. still I do not understand why bond0 seems to interfere
with eth0...

davide
--
[email protected] ICQ:290677265 SKYPE:d.rossetti

2007-09-08 07:21:44

by Jan Engelhardt

[permalink] [raw]
Subject: Re: origin of __tmp1930643048 network device name: kernel-space or user-space


On Sep 7 2007 18:44, davide rossetti wrote:
>
>> > I'm assuming you're running some sort of Fedora/RHEL/
>> > derivative; this is what you get when you have a device that starts
>> > out named ethX, but which needed to be renamed so that an already
>> > configured ethX could be changed to that name.
>>
>> yes, it's FC6.
>>
>> > For the new device, either add a HWADDR in a ifcfg-ethX file for
>> > that interface, add something to /etc/mactab, or add a udev rule.
>>
>> seems like HWADDR is incompatible with bonding.... there is some
>> message using HWADDR as well as MASTER=bond0 and SLAVE=yes.
>
>for the records I worked-around it:
>- problem seems to be the interface 'bond0', which is started first,
>stops the ability to create another device named 'eth0' (WHY?)
>- so I shifted all of the interface names: 0->1, 1->2,...
>now it is ok. still I do not understand why bond0 seems to interfere
>with eth0...

Fedora says it all.