After upgrading to Tumbleweed, onboard LAN worked for some time, but stopped working later. Needed to add a PCI LAN card to connect again with the following result:
The machine is openSUSE only. What raised some concerns was a defective USB disk causing trouble. The system reported files to be new, but actually never had been changed. Detaching and restarting udisks2 fixed that. Later on onboard LAN stopped working and never connected to to the router again.
Anything interesting reported with the following?
dmesg|grep e1000e
Nothing special except for some missing lines compared to the working adapter:
[hofkirchen:~ # dmesg|grep r8169
[ 3.150570] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
3.150751] r8169 0000:03:00.0 (unnamed net_device) (uninitialized): not PCI Express
3.151049] r8169 0000:03:00.0 eth0: RTL8169sb/8110sb at 0xffffb82c01b6a000, c4:12:f5:31:b5:05, XID 10000000 IRQ 18
3.151051] r8169 0000:03:00.0 eth0: jumbo features [frames: 7152 bytes, tx checksumming: ok]
3.181686] r8169 0000:03:00.0 enp3s0: renamed from eth0
4.240148] r8169 0000:03:00.0 enp3s0: link down
4.240152] r8169 0000:03:00.0 enp3s0: link down
5.854541] r8169 0000:03:00.0 enp3s0: link up
181.518970] r8169 0000:03:00.0 enp3s0: link down
183.155310] r8169 0000:03:00.0 enp3s0: link up
hofkirchen:~ #
LINK_REQUIRED { auto | yes | no }
While a working and connected link is required for further setup steps, such as bridge STP, link authentication, auto configu-
ration of the IP address (dhcp, ...) and duplicate IP address detection (enabled by default), it is required in some cases to
continue the setup without to consider the link detection (carrier), e.g. in well-known static "router like" setups. You may
want to disable also the duplicate IP detection (see CHECK_DUPLICATE_IP and the ifsysctl(5) manual page).
This variable permits to configure the waiting for link-detection. When set to yes, wicked waits until link has been detected
before it continues with further steps. When set to no, wicked is permitted to continue earlier, without to wait for a link in
a usable state. When set to auto (default), an internal logic is applied causing to use a "no" for tun/tap devices (which
require a driver daemon) and for bridges with enabled STP and without any ports. In other cases, it behaves as "yes".
I wonder if setting
LINK_REQUIRED=no
in your ifcfg-enp0s25 config file could serve as a workaround here. Just a thought.
Just to clarify, do you have it connected to the router, or are you using the other network interface? (If the latter, then it will be reported as down of course.)
If it is connected, what is reported by the following?
hofkirchen:~ # dmesg|grep e1000e
3.241210] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
3.241211] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
3.241411] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
3.360853] e1000e 0000:00:19.0 0000:00:19.0 (uninitialized): registered PHC clock
3.470015] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) bc:5f:f4:f7:1d:c6
3.470018] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
3.470050] e1000e 0000:00:19.0 eth0: MAC: 11, PHY: 12, PBA No: FFFFFF-0FF
3.471380] e1000e 0000:00:19.0 enp0s25: renamed from eth0
1877.057711] e1000e: EEE TX LPI TIMER: 00000011
1877.882845] e1000e 0000:00:19.0: System wakeup enabled by ACPI
1878.433439] e1000e 0000:00:19.0: System wakeup disabled by ACPI
1997.458811] e1000e: enp0s25 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
1997.458816] e1000e 0000:00:19.0 enp0s25: 10/100 speed: disabling TSO
2061.733486] e1000e: enp0s25 NIC Link is Down
2070.775616] e1000e: enp0s25 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
2070.775623] e1000e 0000:00:19.0 enp0s25: 10/100 speed: disabling TSO
hofkirchen:~ # ethtool enp0s25
Settings for enp0s25:
Supported ports: TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
hofkirchen:~ #
Onboard LAN is back! I doubted it would work again, because I already tried plugging the cable to the mainboard at least 10 times and it never worked. Even UEFI did not connect to the network. Output of wicked is now:
hofkirchen:~ # journalctl -b -u wicked
-- Logs begin at Tue 2016-10-25 15:09:12 CEST, end at Tue 2016-11-08 10:35:07 CET. --
Nov 08 09:59:29 hofkirchen systemd[1]: Starting wicked managed network interfaces...
Nov 08 09:59:59 hofkirchen wicked[764]: lo up
Nov 08 09:59:59 hofkirchen wicked[764]: enp3s0 up
Nov 08 09:59:59 hofkirchen wicked[764]: enp0s25 setup-in-progress
Nov 08 09:59:59 hofkirchen systemd[1]: Started wicked managed network interfaces.
Nov 08 10:34:23 hofkirchen systemd[1]: Stopping wicked managed network interfaces...
Nov 08 10:34:24 hofkirchen wicked[3830]: enp3s0 device-ready
Nov 08 10:34:24 hofkirchen wicked[3830]: enp0s25 device-ready
Nov 08 10:34:24 hofkirchen systemd[1]: Stopped wicked managed network interfaces.
Nov 08 10:34:31 hofkirchen systemd[1]: Starting wicked managed network interfaces...
Nov 08 10:35:01 hofkirchen wicked[4183]: lo up
Nov 08 10:35:01 hofkirchen wicked[4183]: enp3s0 setup-in-progress
Nov 08 10:35:01 hofkirchen wicked[4183]: enp0s25 up
Nov 08 10:35:01 hofkirchen systemd[1]: Started wicked managed network interfaces.
hofkirchen:~ #
But I am really clueless what changed things. Many thanks for helping!
