[opensuse] Persistent mac <-> ethX in oS 12.3
I have a rather new SuperMicro MB that has two on-board NIC, as well as a card with 4 Intel NIC ports. The problem is that it seems that the BIOS does not report these in the same order (I am guessing) so that the same NIC gets the same ethX across reboots. 90% of the time they are the same. But the rest of the times they are different. I thought I could add something like this as a udev rule: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a0:36:9f:00:5f:69", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a0:36:9f:00:5f:6a", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c0:36:9f:00:5f:68", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c0:36:9f:00:5f:69", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c0:36:9f:00:5f:6a", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c0:36:9f:00:5f:6b", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4" But this seems not to be used. I wonder why. YaST seems to have a different idea of which MAC addresses go with which ethX. I would have thought that if the udev rule made the ethX values as I want, then YaST need not get involved with MAC addresses. As it is, the network is unusable. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
I have a rather new SuperMicro MB that has two on-board NIC, as well as a card with 4 Intel NIC ports. The problem is that it seems that the BIOS does not report these in the same order (I am guessing) so that the same NIC gets the same ethX across reboots. 90% of the time they are the same. But the rest of the times they are different.
I thought I could add something like this as a udev rule:
In 12.3, 70-persistent-net.rules should be automatically set up for you. -- Per Jessen, Zürich (14.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday, October 03, 2013 06:26:21 PM Per Jessen wrote:
Roger Oberholtzer wrote:
I have a rather new SuperMicro MB that has two on-board NIC, as well as a card with 4 Intel NIC ports. The problem is that it seems that the BIOS does not report these in the same order (I am guessing) so that the same NIC gets the same ethX across reboots. 90% of the time they are the same. But the rest of the times they are different.
I thought I could add something like this as a udev rule: In 12.3, 70-persistent-net.rules should be automatically set up for you.
It is. But the problem is that the file is set up however the BIOS reported the devices when the system was installed (it seems). If that changes in a later boot, it seems that the rules no longer work. As I suggested, perhaps that is because of possible conflicts with the original names. I surely cannot rename an interface in the rules file to be the same as an existing one. And when the order of when each rule changes (the BIOS presents the list in a different order), this may happen. If I use a new naming scheme so that a conflict does not arrise, the udev rules work every time. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Thursday, October 03, 2013 06:26:21 PM Per Jessen wrote:
Roger Oberholtzer wrote:
I have a rather new SuperMicro MB that has two on-board NIC, as well as a card with 4 Intel NIC ports. The problem is that it seems that the BIOS does not report these in the same order (I am guessing) so that the same NIC gets the same ethX across reboots. 90% of the time they are the same. But the rest of the times they are different.
I thought I could add something like this as a udev rule: In 12.3, 70-persistent-net.rules should be automatically set up for you.
It is. But the problem is that the file is set up however the BIOS reported the devices when the system was installed (it seems). If that changes in a later boot, it seems that the rules no longer work.
Hmm, I can't quite follow you - _what_ exactly changes in a later boot? The MAC addresses?
As I suggested, perhaps that is because of possible conflicts with the original names. I surely cannot rename an interface in the rules file to be the same as an existing one.
Correct. Because of the possiblity of using the same names (eth0-1-2-3-4-5...) but on different mac-addresses, usually devices are first renamed to <somethingelse>, then renamed to the names specified.
And when the order of when each rule changes (the BIOS presents the list in a different order), this may happen.
No, the order isn't (shouldn't be) relevant for the rules. They simply take a MAC-address and rename the interface when it matches. Of course, if your driver has named an interface 'eth0' and you try to use that too, it won't work. Do you have rename rules for all 6 MACs ? -- Per Jessen, Zürich (15.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, October 04, 2013 02:06:22 PM Per Jessen wrote:
Roger Oberholtzer wrote:
On Thursday, October 03, 2013 06:26:21 PM Per Jessen wrote:
Roger Oberholtzer wrote:
I have a rather new SuperMicro MB that has two on-board NIC, as well as a card with 4 Intel NIC ports. The problem is that it seems that the BIOS does not report these in the same order (I am guessing) so that the same NIC gets the same ethX across reboots. 90% of the time they are the same. But the rest of the times they are different.
I thought I could add something like this as a udev rule: In 12.3, 70-persistent-net.rules should be automatically set up for you.
It is. But the problem is that the file is set up however the BIOS reported the devices when the system was installed (it seems). If that changes in a later boot, it seems that the rules no longer work.
Hmm, I can't quite follow you - _what_ exactly changes in a later boot? The MAC addresses?
No. It is the same MAC address for each NIC. But the order the kernel discovers the NICS seems to change in some boots. Even if there is no change to the hardware at all. When this happens, whatever is eth0 may change. I would have thought that the udev rule would have sorted this. And it does if the names are guaranteed not to conflict with the traditional ethNUMBER names.
As I suggested, perhaps that is because of possible conflicts with the original names. I surely cannot rename an interface in the rules file to be the same as an existing one.
Correct. Because of the possiblity of using the same names (eth0-1-2-3-4-5...) but on different mac-addresses, usually devices are first renamed to <somethingelse>, then renamed to the names specified.
The naming to <somethingelse> must first happen for all devices. Then they can be named as specified. But the udev rule is done as each devices is added. So you must get to the final name directly. Unless I missed some neat trick.
And when the order of when each rule changes (the BIOS presents the list in a different order), this may happen.
No, the order isn't (shouldn't be) relevant for the rules. They simply take a MAC-address and rename the interface when it matches. Of course, if your driver has named an interface 'eth0' and you try to use that too, it won't work. Do you have rename rules for all 6 MACs ?
I would have thought the same. In fact, that is how I started. But it simply did not work. I have rules for all existing NICs. I think part of the problem may be that one card has 4 NIC. When that card is found, I bet all 4 NIC get a kernel name. Then the udev add rules get called for each, one at a time. If the first udev rule wants to name a NIC to one of the 3 addresses for the other NIC on the card, it may fail. Just a guess. There is no message in /var/log/messages. It just does not work. So I have names like ethA, ethB, etc. But I do not want that! -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Friday, October 04, 2013 02:06:22 PM Per Jessen wrote:
Roger Oberholtzer wrote:
On Thursday, October 03, 2013 06:26:21 PM Per Jessen wrote:
Roger Oberholtzer wrote:
I have a rather new SuperMicro MB that has two on-board NIC, as well as a card with 4 Intel NIC ports. The problem is that it seems that the BIOS does not report these in the same order (I am guessing) so that the same NIC gets the same ethX across reboots. 90% of the time they are the same. But the rest of the times they are different.
I thought I could add something like this as a udev rule: In 12.3, 70-persistent-net.rules should be automatically set up for you.
It is. But the problem is that the file is set up however the BIOS reported the devices when the system was installed (it seems). If that changes in a later boot, it seems that the rules no longer work.
Hmm, I can't quite follow you - _what_ exactly changes in a later boot? The MAC addresses?
No. It is the same MAC address for each NIC. But the order the kernel discovers the NICS seems to change in some boots.
Yes, that is possible, for instance if the modules are loaded in a different order. (presuming the on-board and your card use different drivers).
I have rules for all existing NICs. I think part of the problem may be that one card has 4 NIC. When that card is found, I bet all 4 NIC get a kernel name.
Yes, ethX, X incremented once per interface port. I have a couple of boxes with 4-port NICs too, I have no such problems. Okay, none of them is running 12.3, they're older systems.
Then the udev add rules get called for each, one at a time. If the first udev rule wants to name a NIC to one of the 3 addresses for the other NIC on the card, it may fail. Just a guess.
You should be able to see what happens in the dmesg output.
There is no message in /var/log/messages. It just does not work. So I have names like ethA, ethB, etc. But I do not want that!
You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction. -- Per Jessen, Zürich (18.0°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, October 04, 2013 03:48:15 PM Per Jessen wrote:
You should be able to see what happens in the dmesg output.
That only lists the initial kernel assignment of an ethX name befote the udev add rule is called. The names stay as listed here, despite the udev rules. Unless I use a different nameing scheme i.e., ethA). As to what caused this: who knows. We have the combination of a new SuperMicro MB and oS 12.3. I still suspect that the SuperMicro is the difference. I have the feeling that the older ones always reported the MB NICs first, followed by those on cards. Now it liike like you can get the first MB NIC, then the card, then the last MB NIC. Or any other order.
There is no message in /var/log/messages. It just does not work. So I have names like ethA, ethB, etc. But I do not want that!
You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.
I suspect you are right. I do look forward to this feature. I hope it will be working. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Friday, October 04, 2013 03:48:15 PM Per Jessen wrote:
You should be able to see what happens in the dmesg output.
That only lists the initial kernel assignment of an ethX name befote the udev add rule is called. The names stay as listed here, despite the udev rules. Unless I use a different nameing scheme i.e., ethA).
As to what caused this: who knows. We have the combination of a new SuperMicro MB and oS 12.3. I still suspect that the SuperMicro is the difference. I have the feeling that the older ones always reported the MB NICs first, followed by those on cards. Now it liike like you can get the first MB NIC, then the card, then the last MB NIC. Or any other order.
I think it's more likely to do with the order of the modules being loaded. The build-in NICs are likely on one of the first PCI-busses, the 4-port card on one of the later. I'm not sure if modules are loaded in order of PCI-location, but there's no inter-dependence so whoever's first ...
There is no message in /var/log/messages. It just does not work. So I have names like ethA, ethB, etc. But I do not want that!
You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.
I suspect you are right. I do look forward to this feature. I hope it will be working.
It looks like it is - I've hit one or two bugs, but my situation is a little exotic. Anyway, I intend to stick to ethN :-) -- Per Jessen, Zürich (18.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Fri, 04 Oct 2013 15:48:15 +0200 Per Jessen <per@computer.org> пишет:
You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.
Well, it is still supposed to work in 12.3, if it does not - it is a bug. But so far description was far too vague to even guess what the problem is. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrey Borzenkov wrote:
В Fri, 04 Oct 2013 15:48:15 +0200 Per Jessen <per@computer.org> пишет:
You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.
Well, it is still supposed to work in 12.3, if it does not - it is a bug. But so far description was far too vague to even guess what the problem is.
Agree. -- Per Jessen, Zürich (18.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, October 04, 2013 06:27:44 PM Per Jessen wrote:
Andrey Borzenkov wrote:
В Fri, 04 Oct 2013 15:48:15 +0200
Per Jessen <per@computer.org> пишет:
You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.
Well, it is still supposed to work in 12.3, if it does not - it is a bug. But so far description was far too vague to even guess what the problem is.
Agree.
OOC, does the udev rule happen when the NIC is found, or when a cable is plugged to it? Another odd problem: It used to be that when you plugged in or took out the network cable, you got a message in /var/log/messages that the activity had occurred. I no longer see this. Also, even though the LEDs in the NIC light as expected, the link is not list as up in 'ip addr'. This is on a couple machines. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Friday, October 04, 2013 06:27:44 PM Per Jessen wrote:
Andrey Borzenkov wrote:
В Fri, 04 Oct 2013 15:48:15 +0200
Per Jessen <per@computer.org> пишет:
You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.
Well, it is still supposed to work in 12.3, if it does not - it is a bug. But so far description was far too vague to even guess what the problem is.
Agree.
OOC, does the udev rule happen when the NIC is found, or when a cable is plugged to it?
I believe the renaming happens as early as possible, ie. when the NIC device is recognized during boot-up.
Another odd problem:
It used to be that when you plugged in or took out the network cable, you got a message in /var/log/messages that the activity had occurred.
I've never seen any such messages, maybe they are from the Network Manager? Or maybe you need NICs configured as "onplug" (can't remember the correct term).
I no longer see this. Also, even though the LEDs in the NIC light as expected, the link is not list as up in 'ip addr'. This is on a couple machines.
The NIC LEDs and the interface config status are independent, afaik. Usually one LED indicates connection (sometimes also speed), the other indicates activity on the network. -- Per Jessen, Zürich (12.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday, October 07, 2013 09:15:19 AM Per Jessen wrote:
Roger Oberholtzer wrote:
On Friday, October 04, 2013 06:27:44 PM Per Jessen wrote:
Andrey Borzenkov wrote:
В Fri, 04 Oct 2013 15:48:15 +0200
Per Jessen <per@computer.org> пишет:
You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.
Well, it is still supposed to work in 12.3, if it does not - it is a bug. But so far description was far too vague to even guess what the problem is.
Agree.
OOC, does the udev rule happen when the NIC is found, or when a cable is plugged to it?
I believe the renaming happens as early as possible, ie. when the NIC device is recognized during boot-up.
Another odd problem:
It used to be that when you plugged in or took out the network cable, you got a message in /var/log/messages that the activity had occurred.
I've never seen any such messages, maybe they are from the Network Manager? Or maybe you need NICs configured as "onplug" (can't remember the correct term).
I will check that. In our system, the connections are fine at boot. We have not changed the settings. On a different 12.3 system, with similar persistent cabled connections, I see this when I unplug/plug a cable: kernel: [340741.476759] r8169 0000:0a:00.0 eth0: link down kernel: [340743.984668] r8169 0000:0a:00.0 eth0: link up But not on the system I am trying to sort out.
I no longer see this. Also, even though the LEDs in the NIC light as expected, the link is not list as up in 'ip addr'. This is on a couple machines.
The NIC LEDs and the interface config status are independent, afaik. Usually one LED indicates connection (sometimes also speed), the other indicates activity on the network.
Indeed. I just meant that a link is sensed by the NIC (the cable has a connection at the other end). -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On a different 12.3 system, with similar persistent cabled connections, I see this when I unplug/plug a cable:
kernel: [340741.476759] r8169 0000:0a:00.0 eth0: link down kernel: [340743.984668] r8169 0000:0a:00.0 eth0: link up
I don't remember seeing those, are they logged to /var/log/messages ? -- Per Jessen, Zürich (14.3°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday, October 07, 2013 11:48:34 AM Per Jessen wrote:
Roger Oberholtzer wrote:
On a different 12.3 system, with similar persistent cabled
connections, I see this when I unplug/plug a cable: kernel: [340741.476759] r8169 0000:0a:00.0 eth0: link down kernel: [340743.984668] r8169 0000:0a:00.0 eth0: link up
I don't remember seeing those, are they logged to /var/log/messages ?
Yes. I usually have used them to see what NIC is what. Very handy. When they worked... I am also curious why the link status (e.g., UP) no longer gets set when the cable is plugged in. In both systems, the sysconfig file for the interface is: BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='10.2.10.41/24' MTU='' NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' USERCONTROL='no' IPADDR_0='10.1.5.1/24' LABEL_0='ANTS' With only IPADDR, NAME and IPADDR being different. Both systems use the traditional way to bring up the interfaces. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Monday, October 07, 2013 11:48:34 AM Per Jessen wrote:
Roger Oberholtzer wrote:
On a different 12.3 system, with similar persistent cabled
connections, I see this when I unplug/plug a cable: kernel: [340741.476759] r8169 0000:0a:00.0 eth0: link down kernel: [340743.984668] r8169 0000:0a:00.0 eth0: link up
I don't remember seeing those, are they logged to /var/log/messages ?
Yes. I usually have used them to see what NIC is what. Very handy. When they worked...
I am also curious why the link status (e.g., UP) no longer gets set when the cable is plugged in.
I think your startmode needs to be "ifplugd", but check in YaST. -- Per Jessen, Zürich (14.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday, October 07, 2013 04:04:08 PM Per Jessen wrote:
Roger Oberholtzer wrote:
On Monday, October 07, 2013 11:48:34 AM Per Jessen wrote:
Roger Oberholtzer wrote:
On a different 12.3 system, with similar persistent cabled
connections, I see this when I unplug/plug a cable: kernel: [340741.476759] r8169 0000:0a:00.0 eth0: link down kernel: [340743.984668] r8169 0000:0a:00.0 eth0: link up
I don't remember seeing those, are they logged to /var/log/messages ?
Yes. I usually have used them to see what NIC is what. Very handy. When they worked...
I am also curious why the link status (e.g., UP) no longer gets set when the cable is plugged in.
I think your startmode needs to be "ifplugd", but check in YaST.
In YaST, "Traditionla method with ifup" is selected. This is what I always have for these types of systems. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
In YaST, "Traditionla method with ifup" is selected. This is what I always have for these types of systems.
Even there, you have options. For example, on my main system, where I use static configuration, I have set Device Activation to At Boot Time. If I used DHCP, I would go with On Cable Connection, as unplugging and reconnecting the cable is an easy way to force DHCP to run again. On my notebook computer I use the network manager to handle the connection, as I could be using either Ethernet or WiFi. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Roger Oberholtzer wrote:
In YaST, "Traditionla method with ifup" is selected. This is what I always have for these types of systems.
Me too, but "ifplugd" is an option per interface.
Even there, you have options. For example, on my main system, where I use static configuration, I have set Device Activation to At Boot Time. If I used DHCP, I would go with On Cable Connection,
That's the one I'm talking about. I'm pretty certain that becomes startmode=ifplugd. -- Per Jessen, Zürich (13.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/10/13 07:55, Roger Oberholtzer wrote:
Also, even though the LEDs in the NIC light as expected, the link is not list as up in 'ip addr'.
The LEDs are controlled at the hardware level, and indicate connection and activity at that level - you might notice the LINK LED may well stay on when the machine is off (even with mains power disconnected, sometimes) and the ACTIVITY LED may well flash when the machine has no IP-level connection. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday, October 07, 2013 08:41:23 AM Dylan wrote:
On 07/10/13 07:55, Roger Oberholtzer wrote:
Also, even though the LEDs in the NIC light as expected, the link is not
list as up in 'ip addr'.
The LEDs are controlled at the hardware level, and indicate connection and activity at that level - you might notice the LINK LED may well stay on when the machine is off (even with mains power disconnected, sometimes) and the ACTIVITY LED may well flash when the machine has no IP-level connection.
Indeed. I am guessing this is hardware specific. We use intel Intelliport cards. On some systems these light up as expected, and on others they do not. On the ones where the NIC does not light up, the link is never listed as 'up' when there is a link. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
lso, even though the LEDs in the NIC light as expected, the link is not list as up in 'ip addr'.
Those LEDs only indicate the phyical conneciton is made and the NIC sees proper Ethernet signalling on the line. They have nothing to do with any software. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday, October 07, 2013 08:08:44 AM James Knott wrote:
Roger Oberholtzer wrote:
lso, even though the LEDs in the NIC light as expected, the link is not list as up in 'ip addr'.
Those LEDs only indicate the phyical conneciton is made and the NIC sees proper Ethernet signalling on the line. They have nothing to do with any software.
Exactly. All I want is for them to light when I attach a cable that is physically connected to the network. This seems unreliable. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Monday, October 07, 2013 08:08:44 AM James Knott wrote:
Roger Oberholtzer wrote:
lso, even though the LEDs in the NIC light as expected, the link is not list as up in 'ip addr'.
Those LEDs only indicate the phyical conneciton is made and the NIC sees proper Ethernet signalling on the line. They have nothing to do with any software.
Exactly. All I want is for them to light when I attach a cable that is physically connected to the network. This seems unreliable.
That's surely a hardware issue then? -- Per Jessen, Zürich (14.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday, October 07, 2013 04:04:45 PM Per Jessen wrote:
Roger Oberholtzer wrote:
On Monday, October 07, 2013 08:08:44 AM James Knott wrote:
Roger Oberholtzer wrote:
lso, even though the LEDs in the NIC light as expected, the link is not list as up in 'ip addr'.
Those LEDs only indicate the phyical conneciton is made and the NIC sees proper Ethernet signalling on the line. They have nothing to do with any software.
Exactly. All I want is for them to light when I attach a cable that is physically connected to the network. This seems unreliable.
That's surely a hardware issue then?
I have eliminated cables. Not sure how to figure out why only one of the NIC on the MB light up as expected. I have seen this on more than one system. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday, October 07, 2013 04:18:30 PM Roger Oberholtzer wrote:
On Monday, October 07, 2013 04:04:45 PM Per Jessen wrote:
Roger Oberholtzer wrote:
On Monday, October 07, 2013 08:08:44 AM James Knott wrote:
Roger Oberholtzer wrote:
lso, even though the LEDs in the NIC light as expected, the link is not list as up in 'ip addr'.
Those LEDs only indicate the phyical conneciton is made and the NIC sees proper Ethernet signalling on the line. They have nothing to do with any software.
Exactly. All I want is for them to light when I attach a cable that is physically connected to the network. This seems unreliable.
That's surely a hardware issue then?
I have eliminated cables. Not sure how to figure out why only one of the NIC on the MB light up as expected. I have seen this on more than one system. --
I am sort of at wit's end here. Things simply do not act as I expect. If I connect three cables to the NIC, I see the lights on those light up as expected when the system is powered on. They stay lit until the kernel starts. At that time, some of them turn off. They should not do this. The status (e.g., NO_CARRIER) shown by 'ip addr' seems not to match what I see in the NIC LEDs. For example, if I see two NIC with proper lights, I would expect to see two interfaces listed as having a physical connection. I do not. Also, the 'connection' between a specific NIC and the ethX is gets is random. I am not changing any hardware. I just reboot. It makes no difference if YaST jhas put something in a udev rule. Those seem not to be consulted. I am confused why, with the same config settings, one oS 12.3 system gives a message in /var/log/messages when cable is altered, and the trouble systems do not. The NIC card is the same intel IntelliPort card that we always use. This happens on more than one system. I am not suspecting hardware. Famous last words. But this is my gut feeling. It is software. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
I am sort of at wit's end here. Things simply do not act as I expect.
If I connect three cables to the NIC,
You are able to fit three cables into _one_ port? That may be the key issue here :-)
I see the lights on those light up as expected when the system is powered on. They stay lit until the kernel starts. At that time, some of them turn off. They should not do this.
You have two on-board NICs and a four-port card, right? I agree that none of them should change the "cable-connected" LED regardless of what the kernel does. Which ports are affected and how?
The status (e.g., NO_CARRIER) shown by 'ip addr' seems not to match what I see in the NIC LEDs. For example, if I see two NIC with proper lights, I would expect to see two interfaces listed as having a physical connection. I do not.
Try using "ethtool" to ascertain the connection status.
Also, the 'connection' between a specific NIC and the ethX is gets is random. I am not changing any hardware. I just reboot. It makes no difference if YaST jhas put something in a udev rule. Those seem not to be consulted.
On 12.3 that is a plain bug, one that should be investigated. Maybe try posting your dmesg output (susepaste or ewhatever it is called). -- Per Jessen, Zürich (13.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, October 09, 2013 08:18:30 PM Per Jessen wrote:
Roger Oberholtzer wrote:
I am sort of at wit's end here. Things simply do not act as I expect.
If I connect three cables to the NIC,
You are able to fit three cables into _one_ port? That may be the key issue here :-)
I see the lights on those light up as expected when the system is powered on. They stay lit until the kernel starts. At that time, some of them turn off. They should not do this.
You have two on-board NICs and a four-port card, right? I agree that none of them should change the "cable-connected" LED regardless of what the kernel does. Which ports are affected and how?
The status (e.g., NO_CARRIER) shown by 'ip addr' seems not to match what I see in the NIC LEDs. For example, if I see two NIC with proper lights, I would expect to see two interfaces listed as having a physical connection. I do not.
Try using "ethtool" to ascertain the connection status.
On ports where the cable and connection on the switch are known to work and the NIC is not lit, ethtool reports: Link detected: no The LEDs on these ports are lit when the computer is powered on. They get turned off when the kernel boots. Could this have something to do with the feature I just noticed in YaST that will blink the NIC LEDs to help you identify them? (I am not doing this.) Of course, the LEDs are not really my concern. I just want the NIC to work consistently. There are some ports where the LEDs are on, but ethtool reports no link detected. This is this way with the current oS12.3 kernel, as well as the newer one in Kernel:/stable/standard I can't see that it makes any difference if the cable is connected when the system is powered on. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Drastic times... I removed the 4-port Intel Intelliport card, leaving only the two on-board NIC interfaces. I reinstalled oS 12.3 (KIWI OEM - goes fast and is an identical install). On boot, the two NIC LEDs look correct. I configured them, and they still were correct. And they worked. Rebooted a few times, and all looks fine. :) Got adventerous Updated XOrg to support the new intel GPU. Still working. :) Updated the kernel to Kernel:/stable/standard to complete the intel GPU support. Still working. And now the intel GPU is using the intel X driver instead of fbdev. :) I feel quite sure that it I put an intel Intelliport card (igb driver) in to the box, all will begin to fail. It seems to me that this is the case with both the oS 12.3 kernel 3.7.10 and the 3.11.4 from Kernel:/stable/standard. The problem happens in two different computers with two different cards. It must be either the intel ethernet igb driver (in both the 3.7.10 and 3.11.4 kernels?), or something about the way oS 12.3 is dealing with the card. I sense I have reached the limits of this list to help me solve something I may be doing wrong and, as Per sugegsted, need to file a bug report. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 10 Oct 2013 09:51:15 +0200 Roger Oberholtzer <roger@opq.se> wrote:
I sense I have reached the limits of this list to help me solve something I may be doing wrong and, as Per sugegsted, need to file a bug report.
Please post bug report link. I'm interested to see discussion as I have built-in network adapter in Dell Inspiron desktop, that is behaving when connected to a LAN trough the switch, but not connected directly to the router. Symptoms are the same as you have seen. I can see that adapter is on when I power up computer, but during the boot light goes off and stay that way. Cure is to apply one or more times: ethtool -s eth0 speed 100 duplex full or to power up switch after computer boots up, which is not always convenient. Two add on PCI cards that I used to troubleshoot the problem work fine. One that is used right now is a gigabit nic run by r8169 driver. On this computer I still use 12.2. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Andrey Borzenkov -
Dylan -
James Knott -
Per Jessen -
Rajko -
Roger Oberholtzer