You are not logged in.
On a fresh boot, or on resume from suspend, my automatic wired connection in plasma-nm takes at least 60 seconds to connect. On resume specifically, it often fails to connect entirely, no matter how long I wait, forcing me to reboot. I can see it continually try to connect over and over again, but I don't know enough about networkmanager to come up with any more diagnostic info on my own.
Setting a static IP in plasma-nm will cause it to show a successful connection immediately, but "ip route" returns "linkdown" and I can't actually load any network resources. If I open a browser and try to load any website and leave it alone for a minute or two, it will eventually load, after which everything will work fine for the rest of that session.
No adapter power management or disabling on the Windows side of my dual-boot system. No changes to my router; other devices all connect fine. WiFi connections in plasma-nm work perfectly. Ignoring plasma-nm and setting my wired connection up by running "dhcpcd" manually works perfectly.
I believe this problem started after a full system upgrade on Sept. 27th, but no packages in the log that day are jumping out at me as being obviously network-related.
Thanks for any help.
Last edited by lowspeedpursuit (2019-10-27 20:33:25)
Offline
Have you examined the journal after resume?
Offline
Never looked, it didn't even occur to me that the answer to "where are more detailed networkmanager logs?" is "in the systemd journal, obviously". It says this, over and over again, every 6 seconds:
Oct 25 20:32:47 hostname kdeinit5[599]: plasma-nm: Unhandled active connection state change: 1
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.7541] dhcp4 (eth0): activation: beginning transaction (timeout in 45 seconds)
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.7535] device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.7521] device (eth0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.6623] manager: NetworkManager state is now CONNECTING
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.6615] device (eth0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.6613] device (eth0): Activation: starting connection 'Ethernet 0.104 Auto' (e668085c-fb7d-4504-aa53-3c9e23de01e7)
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.6597] policy: auto-activating connection 'Ethernet 0.104 Auto' (e668085c-fb7d-4504-aa53-3c9e23de01e7)
Oct 25 20:32:47 hostname kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.6581] device (eth0): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.6576] device (eth0): carrier: link connected
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.6075] manager: NetworkManager state is now DISCONNECTED
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.6029] dhcp4 (eth0): state changed unknown -> done
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.6028] dhcp4 (eth0): canceled DHCP transaction
Oct 25 20:32:47 hostname NetworkManager[512]: <info> [1572049967.5848] device (eth0): state change: ip-config -> unavailable (reason 'carrier-changed', sys-iface-state: 'managed')The only thing about this that jumps out at me is "state change: unavailable / disconnected -> reason 'carrier-changed'", but that seems to imply a hardware problem, and like I said, I can kill everything networkmanager-related and run "dhcpcd eth0" and have my connection work perfectly and immediately every time.
Last edited by lowspeedpursuit (2019-10-26 03:04:51)
Offline
Is the issue present under linux-lts? If it is please post the journal for a whole boot including a resume.
Offline
The issue is not present under linux-lts; my wired connection works immediately and reliably on boot and resume. Do you still want any additional logs from either kernel? Am I supposed to be either looking up or filing a kernel bug?
Incidentally, the lts kernel reverts to only coming up from suspend when I press the power button, while latest resumes on any USB input, which has also been driving me absolutely nuts, so I guess now I can look into that more effectively as well.
Last edited by lowspeedpursuit (2019-10-27 00:41:08)
Offline
https://bugs.archlinux.org/task/64018 ? Please test the DKMS driver from https://bugs.archlinux.org/task/64018?getfile=17888 to see if it is the same issue.
Offline
Yeah, if I install that DKMS driver everything works fine on latest (5.3.7). Is my best move to keep an eye on the upstream bug and leave this driver installed until they figure it out? It seems like it's not really clear if we can expect this to be fixed in 5.4 or not.
Offline
That seems like the best plan to me as well.
Offline
Marking solved. Thank you very much for all your help.
Offline