Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.19 kernel[0].
If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'. If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'. Once testing of the upstream kernel is complete, please mark this bug as "Confirmed". Thanks in advance. [0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19 ** Changed in: linux (Ubuntu) Importance: Undecided => Medium ** Changed in: linux (Ubuntu) Status: Confirmed => Incomplete ** Tags added: kernel-da-key -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1800888 Title: interfaces repetitively deleted in apparent synchrony with up/down network interface seesawing Status in linux package in Ubuntu: Incomplete Bug description: In Description: Ubuntu 18.04.1 LTS Release: 18.04 Occasionally an attempt to open a connection fails, or an attempt to transfer a file, or do something else that works by opening a socket fails. Other things that you would expect to proceed normally with an already opened socket continue to do so. That's the case with TCP, at least. One might draw a conclusion based on the log contents described below that it would probably not so be for UDP, but I haven't tried to verify that. Examining syslog reveals groupings of strange repetitive behavior as demonstrated in the 3 successive groups copied from syslog below. I'm not certain of exactly when this behavior first appeared. I don't know if it's related, but since it appeared, I have seen no more instances of a different anomalous interface network interface behavior (namely: the network being unavailable upon system resumption following system suspension, and requiring performance of at least once more system suspension in order to restore network connectivity) The following are the most concise extracts I could make from the logs to demonstrate the issue. See the attachment for more: Oct 31 00:07:57 notebook ntpd[5122]: Deleting interface #124 enp2s0, 192.168.0.215#123, interface stats: received=72, sent=72, dropped=0, active_time=211 secs Oct 31 00:07:57 notebook ntpd[5122]: Deleting interface #125 enp2s0, fe80::540b:bc14:dd5f:304f%2#123, interface stats: received=0, sent=0, dropped=0, active_time=211 secs Oct 31 00:07:57 notebook kernel: [16414.973867] atl1 0000:02:00.0: enp2s0 link is up 100 Mbps full duplex Oct 31 00:07:57 notebook NetworkManager[975]: <info> [1540969677.5690] device (enp2s0): carrier: link connected Oct 31 00:07:59 notebook ntpd[5122]: Listen normally on 126 enp2s0 192.168.0.215:123 Oct 31 00:07:59 notebook ntpd[5122]: Listen normally on 127 enp2s0 [fe80::540b:bc14:dd5f:304f%2]:123 Oct 31 00:12:42 notebook kernel: [16699.579883] atl1 0000:02:00.0: enp2s0 link is down Oct 31 00:12:43 notebook ntpd[5122]: Deleting interface #126 enp2s0, 192.168.0.215#123, interface stats: received=87, sent=88, dropped=0, active_time=284 secs Oct 31 00:12:43 notebook ntpd[5122]: Deleting interface #127 enp2s0, fe80::540b:bc14:dd5f:304f%2#123, interface stats: received=0, sent=0, dropped=0, active_time=284 secs Oct 31 00:12:43 notebook kernel: [16701.175235] atl1 0000:02:00.0: enp2s0 link is up 100 Mbps full duplex Oct 31 00:12:43 notebook NetworkManager[975]: <info> [1540969963.7701] device (enp2s0): carrier: link connected Oct 31 00:12:45 notebook ntpd[5122]: Listen normally on 128 enp2s0 192.168.0.215:123 Oct 31 00:12:45 notebook ntpd[5122]: Listen normally on 129 enp2s0 [fe80::540b:bc14:dd5f:304f%2]:123 Oct 31 00:13:09 notebook kernel: [16726.743280] atl1 0000:02:00.0: enp2s0 link is down Oct 31 00:13:10 notebook ntpd[5122]: Deleting interface #128 enp2s0, 192.168.0.215#123, interface stats: received=20, sent=20, dropped=0, active_time=25 secs Oct 31 00:13:10 notebook ntpd[5122]: Deleting interface #129 enp2s0, fe80::540b:bc14:dd5f:304f%2#123, interface stats: received=0, sent=0, dropped=0, active_time=25 secs Oct 31 00:13:10 notebook NetworkManager[975]: <info> [1540969990.9253] device (enp2s0): carrier: link connected Oct 31 00:13:10 notebook kernel: [16728.330285] atl1 0000:02:00.0: enp2s0 link is up 100 Mbps full duplex Oct 31 00:13:12 notebook ntpd[5122]: Listen normally on 130 enp2s0 192.168.0.215:123 Oct 31 00:13:12 notebook ntpd[5122]: Listen normally on 131 enp2s0 [fe80::540b:bc14:dd5f:304f%2]:123 Oct 31 00:16:30 notebook kernel: [16927.574126] atl1 0000:02:00.0: enp2s0 link is down While not scientific, I suspect the following view of the (brief enough to permit reliable TCP byte streams, as verified by md5sum) timing between "link down" and "link up" events (as opposed to the much longer amount of time elapsing between "link up" and the next down event) might help to explain why the problem is not more symptomatic than it is: [Oct30 20:23] atl1 0000:02:00.0: enp2s0 link is down [ +1.544088] atl1 0000:02:00.0: enp2s0 link is up 100 Mbps full duplex [Oct30 20:24] atl1 0000:02:00.0: enp2s0 link is down [ +1.630772] atl1 0000:02:00.0: enp2s0 link is up 100 Mbps full duplex [Oct30 20:32] atl1 0000:02:00.0: enp2s0 link is down [Oct30 20:33] atl1 0000:02:00.0: enp2s0 link is up 100 Mbps full duplex [Oct30 20:38] atl1 0000:02:00.0: enp2s0 link is down [ +1.626526] atl1 0000:02:00.0: enp2s0 link is up 100 Mbps full duplex [Oct30 20:42] atl1 0000:02:00.0: enp2s0 link is down [ +1.578927] atl1 0000:02:00.0: enp2s0 link is up 100 Mbps full duplex As before, this is brief, but enough to be illustrative, and more can be found in the tarred log info. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1800888/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
