GNOME Bugzilla – Bug 784854
Regression: Adapters that must reset to enable large MTU (9000) are seen as disconnected and begin an infinite activation loop
Last modified: 2017-11-28 15:12:40 UTC
Description of problem: I have an onboard Intel I218-V ethernet adapter. In order to enable Jumbo Frames (9000 MTU) the adapter must go through a reset of itself, which temporarily turns off the adapter and then back on. This process takes anywhere from 1 to 2 seconds. Prior to NetworkManager 1.8 (which is in Fedora 26, Fedora 25 uses NM 1.4) the adapter would activate without any problem. Starting with NetworkManager 1.8 the adapter is attempted to be brought up, but during the time the adapter is resetting itself NetworkManager is seeing the adapter is disconnected and shuts off the adapter. When the adapter is done resetting itself NetworkManager then sees it online and attempts another activation... NM log: https://paste.fedoraproject.org/paste/jszyLFcEj96lQ32ZfidGPQ Version-Release number of selected component (if applicable): NetworkManager-1.8.0-6.fc26.x86_64 How reproducible: Always Steps to Reproduce: 1. Intel NIC, or any NIC, that resets during MTU jump from 1500 to 9000 2. Start from a cold boot, or MTU set to 1500 3. Activation loop begins Actual results: Network adapter never activates Expected results: Network adapter activates like it did prior to NM 1.8 Additional info: I can get the adapter to activate if I use Gnome Settings to turn off the adapter mid-activation and wait for the adapter to finish setting up. Then turning the adapter on lets it stay active. Network connectivity is fully function and the MTU is properly set to 9000.
Please provide a full logfile with level=TRACE. See hints in https://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/contrib/fedora/rpm/NetworkManager.conf?id=master And please attach it to the bug, not fpaste (which expires). thanks.
Created attachment 355522 [details] NetworkManager TRACE logging I am attaching the NetworkManager log with TRACE level set. The log will show multiple cycling of activation. The last activation will be me manually stopping the device by clicking the ON/OFF toggle in Gnome, waiting for the device to settle for 2 seconds (I see the green LED light light up), and then turning on the device by clicking the ON/OFF toggle in Gnome. Thanks.
Same problem reported on gentoo bug tracker (with a patch) https://bugs.gentoo.org/show_bug.cgi?id=620662
Created attachment 356731 [details] [review] POC patch from Gentoo Attaching patch here for visibility, but it may not be the appropriate fix.
The problem persists in version 1.10.0. Applying the patch always bypasses the problem.
I think this should be fixed now upstream: master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=2becc0a0ac82834ea96898c17ec79cd038e6db54 nm-1-10: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=eb95d6bbbb6982dac78949368fc8b2512aa906bb The timeout is made configurable, but most importantly, after changing the MTU, the timeout is automatically extended from 5 to 10 seconds. So, you shouldn't actually need to configure anything.
Nice, It works, thanks Thomas
Thanks, Thomas.