From: "davide rossetti" <davide.rossetti@gmail.com>
To: "Bill Nottingham" <notting@redhat.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: origin of __tmp1930643048 network device name: kernel-space or user-space
Date: Thu, 6 Sep 2007 17:02:40 +0200 [thread overview]
Message-ID: <6e7a378f0709060802r677b4a8emb9c8cb7530f8028b@mail.gmail.com> (raw)
In-Reply-To: <20070906133551.GA25155@nostromo.devel.redhat.com>
On 9/6/07, Bill Nottingham <notting@redhat.com> wrote:
> Jan Engelhardt (jengelh@computergmbh.de) 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
--
davide.rossetti@gmail.com ICQ:290677265 SKYPE:d.rossetti
next prev parent reply other threads:[~2007-09-06 15:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-04 17:14 davide rossetti
2007-09-04 20:50 ` Kay Sievers
2007-09-06 12:49 ` Jan Engelhardt
2007-09-06 13:35 ` Bill Nottingham
2007-09-06 15:02 ` davide rossetti [this message]
2007-09-07 16:44 ` davide rossetti
2007-09-08 7:21 ` Jan Engelhardt
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=6e7a378f0709060802r677b4a8emb9c8cb7530f8028b@mail.gmail.com \
--to=davide.rossetti@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=notting@redhat.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®