0

I have the same problem as many others here, in short the problem is the same as in this thread.

Specifically, I have the problem that I am connected via cable, but always after about 10-60 minutes the cable connection is disconnected and from that point on I work on Wi-Fi.

I have tried everything that was in the mentioned thread, also tips from here, but nothing really help.

I am using CAT 5e cable (which I tried to replace), I have a laptop Dell 5511, this USB hub through which I am connected to ethernet (also tried to insert ethernet cable directly in laptop, but the problem still occured).

I've tried also this: "We replace the r8169 driver by installing dkms and r8168-dkms and rebooting. We then observe to see if the problem is fixed." - did not help.

route -n (When everything is OK):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    100    0        0 enx98fc84e24e39
0.0.0.0         192.168.0.1     0.0.0.0         UG    600    0        0 wlo1

route -n (When connection dropped):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    600    0        0 wlo1
default         _gateway        0.0.0.0         UG    20100  0        0 enx98fc84e24e39

sudo lshw -C network:

*-network:0
       description: Wireless interface
       product: Comet Lake PCH CNVi WiFi
       vendor: Intel Corporation
       physical id: 14.3
       bus info: pci@0000:00:14.3
       logical name: wlo1
       version: 00
       serial: XX:XX:XX:XX:XX:XX
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=iwlwifi driverversion=6.8.0-45-generic firmware=77.2df8986f.0 QuZ-a0-hr-b0-77.u ip=192.168.0.112 latency=0 link=yes multicast=yes wireless=IEEE 802.11
       resources: irq:16 memory:cc33c000-cc33ffff
  *-network:1
       description: Ethernet interface
       product: Ethernet Connection (11) I219-LM
       vendor: Intel Corporation
       physical id: 1f.6
       bus info: pci@0000:00:1f.6
       logical name: eno2
       version: 00
       serial: XX:XX:XX:XX:XX:XX
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=6.8.0-45-generic firmware=0.4-4 latency=0 link=no multicast=yes port=twisted pair
       resources: irq:145 memory:cc300000-cc31ffff
  *-network
       description: Ethernet interface
       physical id: e
       bus info: usb@4:1.3
       logical name: enx98fc84e24e39
       serial: XX:XX:XX:XX:XX:XX
       size: 1Gbit/s
       capacity: 1Gbit/s
       capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8152 driverversion=v1.12.13 duplex=full firmware=rtl8153a-4 v2 02/07/20 ip=192.168.0.111 link=yes multicast=yes port=MII speed=1Gbit/s

sudo dmesg:

[ 3694.004401] perf: interrupt took too long (5248 > 5162), lowering kernel.perf_event_max_sample_rate to 38000
[ 4610.269599] veth7e5ea36: renamed from eth0
[ 4610.310159] docker0: port 25(vethae505c3) entered disabled state
[ 4610.314330] docker0: port 25(vethae505c3) entered disabled state
[ 4610.315024] vethae505c3 (unregistering): left allmulticast mode
[ 4610.315027] vethae505c3 (unregistering): left promiscuous mode
[ 4610.315031] docker0: port 25(vethae505c3) entered disabled state
[ 4687.307672] docker0: port 25(veth01b1973) entered blocking state
[ 4687.307679] docker0: port 25(veth01b1973) entered disabled state
[ 4687.307688] veth01b1973: entered allmulticast mode
[ 4687.307866] veth01b1973: entered promiscuous mode
[ 4687.443780] eth0: renamed from veth4f034ed
[ 4687.449951] docker0: port 25(veth01b1973) entered blocking state
[ 4687.449960] docker0: port 25(veth01b1973) entered forwarding state
[ 4706.659420] docker0: port 25(veth01b1973) entered disabled state
[ 4706.659531] veth4f034ed: renamed from eth0
[ 4706.695191] docker0: port 25(veth01b1973) entered disabled state
[ 4706.695802] veth01b1973 (unregistering): left allmulticast mode
[ 4706.695806] veth01b1973 (unregistering): left promiscuous mode
[ 4706.695811] docker0: port 25(veth01b1973) entered disabled state
[ 4706.915370] docker0: port 25(veth6c78271) entered blocking state
[ 4706.915376] docker0: port 25(veth6c78271) entered disabled state
[ 4706.915423] veth6c78271: entered allmulticast mode
[ 4706.915567] veth6c78271: entered promiscuous mode
[ 4707.043920] eth0: renamed from veth1e045b3
[ 4707.050294] docker0: port 25(veth6c78271) entered blocking state
[ 4707.050300] docker0: port 25(veth6c78271) entered forwarding state

When ethernet disconnects, wlo1 interface jumps on te 1st place in the table.

I can share additional logs if needed.

Thank you in advance :)

LukynCZE
  • 1

1 Answers1

1

It looks like it is going wrong after the following adjustment (by perf).

(Perf is the processor performance monitor application.)

[ 3694.004401] perf: interrupt took too long (5248 > 5162), lowering kernel.perf_event_max_sample_rate to 38000

This is measure of the NMI (none maskable interrupts) rate. (Samples/second?) When this gets high it appears to have performance effects on the OS. If fact it will start to seem to freeze. In order to avoid this the kernel adjusts it down. I suspect the consequence is the network problems you are having.

The following will display the default limit settings: -

sudo sysctl -a | grep perf

My PC gives the following: -

dev.i915.perf_stream_paranoid = 1
kernel.perf_cpu_time_max_percent = 25
kernel.perf_event_max_contexts_per_stack = 8
kernel.perf_event_max_sample_rate = 16000
kernel.perf_event_max_stack = 127
kernel.perf_event_mlock_kb = 516
kernel.perf_event_paranoid = 4

It is possible to override this (switch it off) with the following command (AT YOUR OWN RISK)

sudo sysctl -w kernel.perf_cpu_time_max_percent=0         //turn off

sudo sysctl -w kernel.perf_cpu_time_max_percent={1..100}  //adjust

(I think this is setback when you reboot.)

In order to fix this without making this adjustment would mean reducing the kernel.perf_cpu_time_max_percent below 25 (%)

perf_cpu_time_max_percent:

Hints to the kernel how much CPU time it should be allowed to use to handle perf sampling events. If the perf subsystem is informed that its samples are exceeding this limit, it will drop its sampling frequency to attempt to reduce its CPU usage.

Some perf sampling happens in NMIs. If these samples unexpectedly take too long to execute, the NMIs can become stacked up next to each other so much that nothing else is allowed to execute.

0: disable the mechanism. Do not monitor or correct perf's sampling rate no matter how CPU time it takes.

1-100: attempt to throttle perf's sample rate to this percentage of CPU. Note: the kernel calculates an "expected" length of each sample event. 100 here means 100% of that expected length. Even if this is set to 100, you may still see sample throttling if this length is exceeded. Set to 0 if you truly do not care how much CPU is consumed.

I hope this might be of some help

https://stackoverflow.com/questions/48457273/how-to-change-perf-event-open-max-sample-rate

https://stackoverflow.com/questions/49807213/maximum-sampling-frequency-supported-by-perf

https://phoenixnap.com/kb/linux-perf

david
  • 937