Hello,
I'm facing something quite strange... When booting one of these kernels
(it's a new machine, I've not been running older kernels), the boot message
says :
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 19 (level, low) -> IRQ 19
sky2 v1.10 addr 0xff8fc000 irq 19 Yukon-EC (0xb6) rev 2
sky2 eth0: addr 00:18:f3:e0:5d:d4
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 16 (level, low) -> IRQ 16
sky2 v1.10 addr 0xff7fc000 irq 16 Yukon-EC (0xb6) rev 2
sky2 eth1: addr 00:18:f3:e0:36:fd
So, I'm expecting two interfaces : eth0 and eth1
Unfortunately, at the end of the boot process, I can find eth1 and eth2,
something/somewhat/someone has renumbered them ;
eth1 Link encap:Ethernet HWaddr 00:18:F3:E0:36:FD
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)
Interrupt:16
eth2 Link encap:Ethernet HWaddr 00:18:F3:E0:5D:D4
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::218:f3ff:fee0:5dd4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:42780 errors:0 dropped:0 overruns:0 frame:0
TX packets:25519 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:61859841 (58.9 MiB) TX bytes:2031644 (1.9 MiB)
Interrupt:19
This does also occurs when I boot in single user mode, so I did a quick check
at the processes running then, and found udevd, but there is no reference to
ethX in the configuration files, only veth :
root@riri:/Kernels/External# cd /etc/udev/
root@riri:/etc/udev# grep -r eth *
rules.d/90-modprobe.rules:ENV{VIO_TYPE}=="network",
RUN+="/sbin/modprobe -Qba ibmveth"
rules.d/90-modprobe.rules:ENV{VIO_TYPE}=="vlan",
RUN+="/sbin/modprobe -Qba iseries_veth"
Is it something expected ? Or is it because Sky2 is still EXPERIMENTAL ?
Regards,
Paul
On Sun, Feb 11, Paul Rolland wrote:
> I'm facing something quite strange... When booting one of these kernels
> (it's a new machine, I've not been running older kernels), the boot message
> says :
>
> ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 19 (level, low) -> IRQ 19
> sky2 v1.10 addr 0xff8fc000 irq 19 Yukon-EC (0xb6) rev 2
> sky2 eth0: addr 00:18:f3:e0:5d:d4
> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> sky2 v1.10 addr 0xff7fc000 irq 16 Yukon-EC (0xb6) rev 2
> sky2 eth1: addr 00:18:f3:e0:36:fd
>
> So, I'm expecting two interfaces : eth0 and eth1
>
> Unfortunately, at the end of the boot process, I can find eth1 and eth2,
Unfortunately, this patch was not applied to mainline last year.
Maybe this year.
Keep track about which network interface names were renamed after the
network device driver printed its banner.
Signed-off-by: Olaf Hering <[email protected]>
--- linux-2.6.19.orig/net/core/dev.c
+++ linux-2.6.19/net/core/dev.c
@@ -749,7 +749,11 @@ int dev_change_name(struct net_device *d
else if (__dev_get_by_name(newname))
return -EEXIST;
else
+ {
+ if (strncmp(newname, dev->name, IFNAMSIZ))
+ printk(KERN_INFO "%s renamed to %s\n", dev->name, newname);
strlcpy(dev->name, newname, IFNAMSIZ);
+ }
err = class_device_rename(&dev->class_dev, dev->name);
if (!err) {
On 2/11/07, Paul Rolland <[email protected]> wrote:
> Hello,
>
> I'm facing something quite strange... When booting one of these kernels
> (it's a new machine, I've not been running older kernels), the boot message
> says :
>
> ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 19 (level, low) -> IRQ 19
> sky2 v1.10 addr 0xff8fc000 irq 19 Yukon-EC (0xb6) rev 2
> sky2 eth0: addr 00:18:f3:e0:5d:d4
> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> sky2 v1.10 addr 0xff7fc000 irq 16 Yukon-EC (0xb6) rev 2
> sky2 eth1: addr 00:18:f3:e0:36:fd
>
> So, I'm expecting two interfaces : eth0 and eth1
>
> Unfortunately, at the end of the boot process, I can find eth1 and eth2,
> something/somewhat/someone has renumbered them ;
usually distro enable persistent interface naming with udev, check
/etc/iftab and see if you have something like
/etc/udev/something-iftab.rules
regards,
Benoit
Hello Benoit,
> usually distro enable persistent interface naming with udev, check
> /etc/iftab and see if you have something like
> /etc/udev/something-iftab.rules
Found this :
# This file assigns persistent names to network interfaces.
# See iftab(5) for syntax.
eth0 mac 00:11:d8:a9:c0:c2 arp 1
ra0 mac 00:11:d8:b9:27:7e arp 1
As these are no MAC on my machine, I suspect this is the reason for the
renaming.
I'm trying Olaf's patch to check the message is printed, and next boot
is without this crap in this /etc/iftab file.
Regards,
Paul
Excellent Olaf !
Yes, I got a "eth0 renamed to eth2".
> Unfortunately, this patch was not applied to mainline last year.
> Maybe this year.
Seconded, you have my vote for this !
Regards,
Paul
Thanks Benoit, that was it ! Removing the entry in the iftab file
stopped the renaming of the interface !
Regards,
Paul
From: Olaf Hering <[email protected]>
Date: Sun, 11 Feb 2007 13:54:23 +0100
> Keep track about which network interface names were renamed after the
> network device driver printed its banner.
>
> Signed-off-by: Olaf Hering <[email protected]>
This is kernel log clutter.
You can ask the kernel for the list of interfaces, and
use even ethtool to ask what driver each interface is
associated with.
The patch wasn't applied because it really is not necessary.
From: Jason Lunz <[email protected]>
Date: Sun, 11 Feb 2007 13:27:05 -0500
> On Sun, Feb 11, 2007 at 09:55:52AM -0800, David Miller wrote:
> > This is kernel log clutter.
> >
> > You can ask the kernel for the list of interfaces, and
> > use even ethtool to ask what driver each interface is
> > associated with.
> >
> > The patch wasn't applied because it really is not necessary.
>
> I disagree completely. I'm working right now on a udev-based system that
> does ethernet device renaming. It's quite difficult when working with
> udev to tell exactly when and why each interface was renamed, since it's
> typically done within initramfs where it's difficult to enable debug
> messages. This printk helps immensely.
You can listen on a netlink socket for these events if you
want to see when they occur.
There is no need for this log message, it is superfluous.
David Miller wrote:
> From: Jason Lunz <[email protected]>
> Date: Sun, 11 Feb 2007 13:27:05 -0500
>
>> On Sun, Feb 11, 2007 at 09:55:52AM -0800, David Miller wrote:
>>> This is kernel log clutter.
>>>
>>> You can ask the kernel for the list of interfaces, and
>>> use even ethtool to ask what driver each interface is
>>> associated with.
>>>
>>> The patch wasn't applied because it really is not necessary.
>> I disagree completely. I'm working right now on a udev-based system that
>> does ethernet device renaming. It's quite difficult when working with
>> udev to tell exactly when and why each interface was renamed, since it's
>> typically done within initramfs where it's difficult to enable debug
>> messages. This printk helps immensely.
>
> You can listen on a netlink socket for these events if you
> want to see when they occur.
Unfortunately that's not very practical if, as in this case, the
renaming is being done from an initramfs. Hiding this information as we
do now is rather user-hostile.
>
> There is no need for this log message, it is superfluous.
I think the minimal extra output from this is well worth it. If we care
so much about limiting dmesg output, how about getting rid of all those
hundreds of "PM: Adding info for" messages in recent kernels..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
From: Robert Hancock <[email protected]>
Date: Sun, 11 Feb 2007 13:20:10 -0600
> Unfortunately that's not very practical if, as in this case, the
> renaming is being done from an initramfs. Hiding this information as we
> do now is rather user-hostile.
Perhaps you have a point, I'll think about this some more.
But on the other hand note that kernel log messages can scroll away
and get lost, so you cannot really rely upon them for gathering
information which is necessary for properly detecting devices
in userspace or anything like that.
Am 11.02.2007 19:28 schrieb David Miller:
> From: Jason Lunz <[email protected]>
> Date: Sun, 11 Feb 2007 13:27:05 -0500
>
>> On Sun, Feb 11, 2007 at 09:55:52AM -0800, David Miller wrote:
>>> This is kernel log clutter.
>>>
>>> You can ask the kernel for the list of interfaces, and
>>> use even ethtool to ask what driver each interface is
>>> associated with.
>>>
>>> The patch wasn't applied because it really is not necessary.
>> I disagree completely. I'm working right now on a udev-based system that
>> does ethernet device renaming. It's quite difficult when working with
>> udev to tell exactly when and why each interface was renamed, since it's
>> typically done within initramfs where it's difficult to enable debug
>> messages. This printk helps immensely.
>
> You can listen on a netlink socket for these events if you
> want to see when they occur.
>
> There is no need for this log message, it is superfluous.
I disagree. This message can be very helpful. The problem of network
interfaces being renamed is a real and frequent one. A single message
per interface is tolerable even if you don't actually need it. My
kernel log currently produces well over 400 messages per boot, so if
you want to reduce kernel log clutter, there are lots of other
candidates.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)