Very slow setup of ethernet link

Hello, since a couple of days the setup of my ethernet link during boot is very slowly: [ 1.612889] r8169 0000:01:00.0 eth0: RTL8168g/8111g, 90:1b:0e:c9:f9:09, XID 4c0, IRQ 128 [ 1.613649] r8169 0000:01:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko] [ 1.659073] r8169 0000:01:00.0 enp1s0: renamed from eth0 [ 2.444703] Generic FE-GE Realtek PHY r8169-0-100:00: attached PHY driver (mii_bus:phy_addr=r8169-0-100:00, irq=MAC) [ 2.608140] r8169 0000:01:00.0 enp1s0: No native access to PCI extended config space, falling back to CSI [ 2.634911] r8169 0000:01:00.0 enp1s0: Link is Down [ 67.399475] r8169 0000:01:00.0 enp1s0: Link is Up - 1Gbps/Full - flow control rx/tx This started since the update of iproute2 port to version 6.4.0 which I did at the same time as an update to Linux kernel version 6.4. Before those two updates the link was up in a couple of seconds, now it often takes more than a minute. I have a static configuration in /etc/rc.d/net so no DHCP is in use. Did someone notice a similar behaviour or even knows the cause and how to avoid it? Regards Markus Heinz

On 2023-07-02 15:02 +0200 Markus Heinz wrote:
since a couple of days the setup of my ethernet link during boot is very slowly:
[ 1.612889] r8169 0000:01:00.0 eth0: RTL8168g/8111g, 90:1b:0e:c9:f9:09, XID 4c0, IRQ 128 [ 1.613649] r8169 0000:01:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko] [ 1.659073] r8169 0000:01:00.0 enp1s0: renamed from eth0 [ 2.444703] Generic FE-GE Realtek PHY r8169-0-100:00: attached PHY driver (mii_bus:phy_addr=r8169-0-100:00, irq=MAC) [ 2.608140] r8169 0000:01:00.0 enp1s0: No native access to PCI extended config space, falling back to CSI [ 2.634911] r8169 0000:01:00.0 enp1s0: Link is Down [ 67.399475] r8169 0000:01:00.0 enp1s0: Link is Up - 1Gbps/Full - flow control rx/tx
This started since the update of iproute2 port to version 6.4.0 which I did at the same time as an update to Linux kernel version 6.4.
Before those two updates the link was up in a couple of seconds, now it often takes more than a minute.
I have a static configuration in /etc/rc.d/net so no DHCP is in use.
Yesterday I tried a git bisect on the Linux kernel with 6.3.9 as good version and 6.4.1 as bad version. After more than two hours with compiling and booting kernels the git bisect ended with a commit on "bpf": commit d7a799ec782b6ae9158f8d587c9f49cf34a6c5f4 Merge: 45cea721ea36 006c0e44ed92 Author: Alexei Starovoitov <ast@kernel.org> Date: Fri Apr 21 11:35:51 2023 -0700 Merge branch 'bpf: add netfilter program type' While bisecting I considered an ethernet link setup time up to ten seconds as good and more than ten seconds as bad. The setup times varied between a couple of seconds and more than two minutes. But I don't think this commit is related to my issue. Right after the bisect I reinstalled and booted my Linux 6.4.1 stable kernel. In that case the link was up in about six seconds which is normal with my hardware. So I think my test procedure is invalid because the link setup time is not strictly related to kernel code version. It's kind of random. On an Ubuntu installation on the same hardware with kernel 5.15 (dual boot) the link setup time is still kind of constant with six seconds. Initially my plan was to report the result of the git bisect on the Linux kernel bug tracker. But due to the kind of randomness I discovered later on I did not proceed with reporting it to the kernel bug tracker. I have read the chat logs of #crux-devel now. Thank you to all trying to reproduce my issue. As the issue could not be reproduced it seems it is not a general issue. Maybe just my hardware is starting to get broken :-/ It's more than six years old now... Regards Markus Heinz
participants (1)
-
Markus Heinz