I am getting the following error message from drivers/base/core.c:
net eth1: device_rename: sysfs_create_symlink failed (-17)
Upon investigation, the call generating the error is renaming 'eth1' to 'eth1'. The following patch
suppresses the error.
Index: wireless-dev/drivers/base/core.c
===================================================================
--- wireless-dev.orig/drivers/base/core.c
+++ wireless-dev/drivers/base/core.c
@@ -1256,7 +1256,7 @@ int device_rename(struct device *dev, ch
sysfs_remove_link(&dev->class->subsys.kobj, old_device_name);
error = sysfs_create_link(&dev->class->subsys.kobj, &dev->kobj,
dev->bus_id);
- if (error) {
+ if (error && memcmp(dev->bus_id, new_name, sizeof(new_name))) {
/* Uh... how to unravel this if restoring can fail? */
dev_err(dev, "%s: sysfs_create_symlink failed (%d)\n",
__FUNCTION__, error);
Larry
From: Larry Finger <[email protected]>
Date: Tue, 07 Aug 2007 23:17:23 -0500
> I am getting the following error message from drivers/base/core.c:
>
> net eth1: device_rename: sysfs_create_symlink failed (-17)
>
> Upon investigation, the call generating the error is renaming 'eth1' to 'eth1'. The following patch
> suppresses the error.
I think this check belongs in udev not in the kernel. Thankfully
this message at least tells us it is happening, please don't
remove it.
I'm pretty sure it's UDEV doing this, and it should not try to rename
a netdevice to what it already is named.
David Miller wrote:
> From: Larry Finger <[email protected]>
> Date: Tue, 07 Aug 2007 23:17:23 -0500
>
>> I am getting the following error message from drivers/base/core.c:
>>
>> net eth1: device_rename: sysfs_create_symlink failed (-17)
>>
>> Upon investigation, the call generating the error is renaming 'eth1' to 'eth1'. The following patch
>> suppresses the error.
>
> I think this check belongs in udev not in the kernel. Thankfully
> this message at least tells us it is happening, please don't
> remove it.
>
> I'm pretty sure it's UDEV doing this, and it should not try to rename
> a netdevice to what it already is named.
>
Yes, it is most likely coming from udev. Do you know who maintains udev? Google didn't give an
answer in the first two pages.
Thanks,
Larry
From: Larry Finger <[email protected]>
Date: Tue, 07 Aug 2007 23:52:34 -0500
> Yes, it is most likely coming from udev. Do you know who maintains
> udev? Google didn't give an answer in the first two pages.
I may be mis-remembering but I thought Greg KH was at the
helm at least at one point.
David Miller wrote:
> From: Larry Finger <[email protected]>
> Date: Tue, 07 Aug 2007 23:52:34 -0500
>
>> Yes, it is most likely coming from udev. Do you know who maintains
>> udev? Google didn't give an answer in the first two pages.
>
> I may be mis-remembering but I thought Greg KH was at the
> helm at least at one point.
>
Between the previous message and this one, I found a link that lists him as one of the authors. I'll
ping him about the "problem". Thanks for your help.
Larry
On Tue, Aug 07, 2007 at 11:52:34PM -0500, Larry Finger wrote:
> David Miller wrote:
> >From: Larry Finger <[email protected]>
> >Date: Tue, 07 Aug 2007 23:17:23 -0500
> >
> >>I am getting the following error message from drivers/base/core.c:
> >>
> >>net eth1: device_rename: sysfs_create_symlink failed (-17)
> >>
> >>Upon investigation, the call generating the error is renaming 'eth1' to
> >>'eth1'. The following patch suppresses the error.
> >
> >I think this check belongs in udev not in the kernel. Thankfully
> >this message at least tells us it is happening, please don't
> >remove it.
> >
> >I'm pretty sure it's UDEV doing this, and it should not try to rename
> >a netdevice to what it already is named.
> >
>
> Yes, it is most likely coming from udev. Do you know who maintains udev?
> Google didn't give an answer in the first two pages.
Kay Sievers. Se contact details on his udev page here:
http://vrfy.org/log/recent-state-of-udev.html
Sam
On Tue, 07 Aug 2007 21:37:24 -0700 (PDT),
David Miller <[email protected]> wrote:
> From: Larry Finger <[email protected]>
> Date: Tue, 07 Aug 2007 23:17:23 -0500
>
> > I am getting the following error message from drivers/base/core.c:
> >
> > net eth1: device_rename: sysfs_create_symlink failed (-17)
> >
> > Upon investigation, the call generating the error is renaming 'eth1' to 'eth1'. The following patch
> > suppresses the error.
>
> I think this check belongs in udev not in the kernel. Thankfully
> this message at least tells us it is happening, please don't
> remove it.
Hm, device_rename() could alternatively just return success if
dev->bus_id and new_name are the same.
>
> I'm pretty sure it's UDEV doing this, and it should not try to rename
> a netdevice to what it already is named.
But it shouldn't cause an error either :)
Cornelia Huck wrote:
> On Tue, 07 Aug 2007 21:37:24 -0700 (PDT),
> David Miller <[email protected]> wrote:
>
>> I think this check belongs in udev not in the kernel. Thankfully
>> this message at least tells us it is happening, please don't
>> remove it.
>
> Hm, device_rename() could alternatively just return success if
> dev->bus_id and new_name are the same.
That is what my proposed patch did. One could argue that the test should come before the failure,
not after, but the effect is the same.
>> I'm pretty sure it's UDEV doing this, and it should not try to rename
>> a netdevice to what it already is named.
>
> But it shouldn't cause an error either :)
I agree with you, but you and David can fight it out. While finding out where to ask/complain about
udev, I had a private communication with GregKH. He thinks that a patch to fix this has already been
pushed through Linus. As Linville's wireless-dev tree is a little behind, I'm waiting to see if it
gets fixed here by 2.6.23-rc3. If not, I'll talk to the udev/hotplug folks.
On 8/8/07, Larry Finger <[email protected]> wrote:
> Cornelia Huck wrote:
> > On Tue, 07 Aug 2007 21:37:24 -0700 (PDT),
> > David Miller <[email protected]> wrote:
> >
> >> I think this check belongs in udev not in the kernel. Thankfully
> >> this message at least tells us it is happening, please don't
> >> remove it.
> >
> > Hm, device_rename() could alternatively just return success if
> > dev->bus_id and new_name are the same.
>
> That is what my proposed patch did. One could argue that the test should come before the failure,
> not after, but the effect is the same.
>
> >> I'm pretty sure it's UDEV doing this, and it should not try to rename
> >> a netdevice to what it already is named.
> >
> > But it shouldn't cause an error either :)
>
> I agree with you, but you and David can fight it out. While finding out where to ask/complain about
> udev, I had a private communication with GregKH. He thinks that a patch to fix this has already been
> pushed through Linus. As Linville's wireless-dev tree is a little behind, I'm waiting to see if it
> gets fixed here by 2.6.23-rc3. If not, I'll talk to the udev/hotplug folks.
Hmm, I can not immediately see how udev could request the renaming to
the same name:
/* look if we want to change the name of the netif */
if (strcmp(udev->name, udev->dev->kernel) != 0) {
...
retval = rename_netif(udev);
...
}
What udev version is it and which distro and version?
Kay
Kay Sievers wrote:
> On 8/8/07, Larry Finger <[email protected]> wrote:
>> I agree with you, but you and David can fight it out. While finding out where to ask/complain about
>> udev, I had a private communication with GregKH. He thinks that a patch to fix this has already been
>> pushed through Linus. As Linville's wireless-dev tree is a little behind, I'm waiting to see if it
>> gets fixed here by 2.6.23-rc3. If not, I'll talk to the udev/hotplug folks.
>
> Hmm, I can not immediately see how udev could request the renaming to
> the same name:
>
> /* look if we want to change the name of the netif */
> if (strcmp(udev->name, udev->dev->kernel) != 0) {
> ...
> retval = rename_netif(udev);
> ...
> }
>
> What udev version is it and which distro and version?
My distro is openSUSE 10.2, which is fully patched/updated. According to YaST, I'm using version
103-12 x86_64. My kernel is 2.6.23-rc2 from John Linville's git tree - I run bcm43xx-mac80211.
Larry
On Wed, 2007-08-08 at 08:59 -0500, Larry Finger wrote:
> Kay Sievers wrote:
> > On 8/8/07, Larry Finger <[email protected]> wrote:
> >> I agree with you, but you and David can fight it out. While finding out where to ask/complain about
> >> udev, I had a private communication with GregKH. He thinks that a patch to fix this has already been
> >> pushed through Linus. As Linville's wireless-dev tree is a little behind, I'm waiting to see if it
> >> gets fixed here by 2.6.23-rc3. If not, I'll talk to the udev/hotplug folks.
> >
> > Hmm, I can not immediately see how udev could request the renaming to
> > the same name:
> >
> > /* look if we want to change the name of the netif */
> > if (strcmp(udev->name, udev->dev->kernel) != 0) {
> > ...
> > retval = rename_netif(udev);
> > ...
> > }
> >
> > What udev version is it and which distro and version?
>
> My distro is openSUSE 10.2, which is fully patched/updated. According to YaST, I'm using version
> 103-12 x86_64. My kernel is 2.6.23-rc2 from John Linville's git tree - I run bcm43xx-mac80211.
Oh, that's likely a bug in the SUSE versions of the persistent net
interface rules. It is calling ifrename when it needs to swap interface
names (temp rename to free the target name), that logic which may have
that bug.
For the next SUSE release, it is replaced by the (now available)
upstream stuff from the udev tree, which most distros use now, and which
should not have that problem.
Thanks,
Kay
Kay Sievers wrote:
> On Wed, 2007-08-08 at 08:59 -0500, Larry Finger wrote:
>> Kay Sievers wrote:
>>> On 8/8/07, Larry Finger <[email protected]> wrote:
>>>> I agree with you, but you and David can fight it out. While finding out where to ask/complain about
>>>> udev, I had a private communication with GregKH. He thinks that a patch to fix this has already been
>>>> pushed through Linus. As Linville's wireless-dev tree is a little behind, I'm waiting to see if it
>>>> gets fixed here by 2.6.23-rc3. If not, I'll talk to the udev/hotplug folks.
>>> Hmm, I can not immediately see how udev could request the renaming to
>>> the same name:
>>>
>>> /* look if we want to change the name of the netif */
>>> if (strcmp(udev->name, udev->dev->kernel) != 0) {
>>> ...
>>> retval = rename_netif(udev);
>>> ...
>>> }
>>>
>>> What udev version is it and which distro and version?
>> My distro is openSUSE 10.2, which is fully patched/updated. According to YaST, I'm using version
>> 103-12 x86_64. My kernel is 2.6.23-rc2 from John Linville's git tree - I run bcm43xx-mac80211.
>
> Oh, that's likely a bug in the SUSE versions of the persistent net
> interface rules. It is calling ifrename when it needs to swap interface
> names (temp rename to free the target name), that logic which may have
> that bug.
> For the next SUSE release, it is replaced by the (now available)
> upstream stuff from the udev tree, which most distros use now, and which
> should not have that problem.
Thanks for the explanation. I'll ignore the message - it doesn't cause any problems anyway, and I'll
expect it to go away when openSUSE 10.3 comes out in October. I think I'll post a bug report with
SUSE just to make sure it gets fixed.
Larry