kernel 5 fails to start systemd-networkd on old Dell Inspiron 1720

[vatbier]

linux kernel 5.0.0-13
Kubuntu 19.04
hardware: old Dell laptop Inspiron 1720

After upgrading an old Dell laptop Inspiron 1720 (from 2007 I think) from Kubuntu 18.10 to 19.04, the result is a broken system:
booting takes + 5 minutes
looking at the boot messages I see "Failed to start Dispatcher daemon for systemd-networkd" and consequently Network Manager fails to run.
Eventually it reaches the desktop where it takes another 5 minutes to display the panel.
In a terminal it fails to execute any network command (ifconfig, ip) as well as "sudo" and "lshw".

If I boot with the previous kernel, the 4.18.0-18 of Kubuntu 18.10, it works without problem.
For now I have set its grub to start by default the 4.18 kernel instead of the 5.0 one.

I tried running "apport-cli -f -p linux --save kernel5.0onOldDellInspiron1720.apport" but that has been spitting out periods ("....") for 10 minutes now and still hasn't finished.

dmesg output attached.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1829310

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[vatbier (vatbier)]

using kernel 5 for kubuntu 19.04, I have no network interface and thus no internet connection so I can't run that apport-collect command.

[Kai-Heng Feng (kaihengfeng)]

Please test upstream stable kernel:
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0.16/

[Kai-Heng Feng (kaihengfeng)]

This is fixed in mainline, but not sure if upstream stable have this fix or not.
[ 48.065638] RIP: 0010:swiotlb_tbl_map_single+0x120/0x310
[ 48.065641] Code: 4c 8b 45 a8 4c 8b 1d af c7 a9 01 89 d3 45 31 d2 44 8b 4d a4 44 89 c7 41 89 dc 4b 8d 44 25 00 48 21 f0 48 01 f8 49 39 c7 72 0a <47> 39 0c a3 0f 83 cb 00 00 00 42 8d 04 33 48 89 c3 48 39 c1 41 0f
[ 48.065643] RSP: 0018:ffffbed680f6b3c0 EFLAGS: 00010016
[ 48.065646] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000
[ 48.065648] RDX: 0000000000000000 RSI: 00000000001fffff RDI: 0000000000000001
[ 48.065650] RBP: ffffbed680f6b420 R08: 0000000000000001 R09: 0000000000000001
[ 48.065652] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 48.065653] R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000200000
[ 48.065656] FS: 00007f9e750f16c0(0000) GS:ffff96d53da00000(0000) knlGS:0000000000000000
[ 48.065659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 48.065661] CR2: 0000000000000000 CR3: 0000000073114000 CR4: 00000000000006f0
[ 48.065662] Call Trace:
[ 48.065669] swiotlb_map+0x6c/0x1c0
[ 48.065673] dma_direct_map_page+0xc5/0x160
[ 48.065679] b44_alloc_rx_skb+0x18e/0x3f0 [b44]
[ 48.065683] b44_init_rings+0xbe/0x1b0 [b44]
[ 48.065686] b44_open+0xfc/0x3f0 [b44]
[ 48.065691] __dev_open+0xd4/0x170
[ 48.065694] __dev_change_flags+0x18f/0x200
[ 48.065698] dev_change_flags+0x27/0x60
[ 48.065701] do_setlink+0x31c/0xe30
[ 48.065707] ? __nla_parse+0x38/0x120
[ 48.065710] __rtnl_newlink+0x531/0x910
[ 48.065715] ? update_load_avg+0x4b6/0x590
[ 48.065719] ? __alloc_pages_nodemask+0x13f/0x2e0
[ 48.065726] ? _cond_resched+0x19/0x30
[ 48.065730] ? kmem_cache_alloc_trace+0x153/0x1d0
[ 48.065732] rtnl_newlink+0x48/0x70
[ 48.065735] rtnetlink_rcv_msg+0x213/0x300
[ 48.065737] ? rtnl_calcit.isra.31+0x100/0x100
[ 48.065741] netlink_rcv_skb+0x4f/0x120
[ 48.065744] rtnetlink_rcv+0x15/0x20
[ 48.065746] netlink_unicast+0x1a1/0x260
[ 48.065749] netlink_sendmsg+0x20d/0x3c0
[ 48.065753] sock_sendmsg+0x3e/0x50
[ 48.065756] ___sys_sendmsg+0x295/0x2f0
[ 48.065758] ? sock_destroy_inode+0x2f/0x40
[ 48.065762] ? destroy_inode+0x3e/0x60
[ 48.065764] ? evict+0x139/0x1a0
[ 48.065767] ? iput+0x148/0x210
[ 48.065769] ? _cond_resched+0x19/0x30
[ 48.065772] ? __dentry_kill+0x124/0x170
[ 48.065775] ? dentry_kill+0x52/0x1a0
[ 48.065778] __sys_sendmsg+0x5c/0xa0
[ 48.065781] __x64_sys_sendmsg+0x1f/0x30
[ 48.065785] do_syscall_64+0x5a/0x110
[ 48.065788] entry_SYSCALL_64_after_hwframe+0x44/0xa9

[vatbier (vatbier)]

Kai-Heng,
it is not fixed in 5.0.16.

I saw in boot messages still "Failed to start Dispatcher daemon for systemd-networkd"
dmesg output of 5.0.16 attached.

[vatbier (vatbier)]

also not fixed in 5.0.17. ( https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0.17/ )

[Kai-Heng Feng (kaihengfeng)]

Is it fixed in v5.1?

[vatbier (vatbier)]

Kai-Heng,
I can confirm it is fixed in 5.1.15-050115-generic.

However, I can not use 5.1.15 because with its linux-headers-5.1.15-050115-generic dkms can not build a module for nvidia-340
(see further below for the error output).
I switched to nouveau and with that driver I could reach with 5.1.15 the desktop and see that all network functionality is ok.
The nouveau driver is not as stable as nvidia's. But its biggest disadvantage is that after a while my old laptop is consumed with high cpu load from a process of systemd-udev or something.
Thus I had to revert to kernel 4.18 and to nvidia driver.

Please ask the kernel devs to make builds that can build dkms modules for nvidia-340.

For anyone that stumbles on this bug report:
I had a lot of trouble with kubuntu 19.04 to make nouveau working:

First I tried Discover > Sources > Additional drivers: changing to nouveau does not do anything.
Running from konsole "sudo software-properties-qt" shows that it can't change to nouveau. Someone, please make a bug for it (I currently have no time to dot it myself).

Then I found out about KDE's systemsettings > Driver Manager: that functionality to change to nouveau works.

Then the next hitch: booting then fails (for both 5.15 and 4.18): the boot message lines don't go further than systemd_user_sessions.service.
In a second tty (ctrl-alt-F2) I tried the command startx and KDE plasma desktop got loaded.
(without starting X you can't download and install packages with apt command as there is no wifi connection. Maybe a utp cable connection would have given internet access at the tty2.)

Searching further to make it boot completely I found the command "sudo apt purge nvidia*". Then I was able to boot to the desktop without getting stuck at systemd_user_sessions.service.

And this for both 5.1.15 and 4.18.

Someone, please also make a bug for the fact that the graphical way to change to nouveau driver is useless without the purge nvidia* command!

Alas, as already told, nouveau's quality is too low: after a while the cpu load goes up by a systemd-udev process.
So to revert back to nvidia driver and kernel 4.18 the command "sudo ubuntu-drivers autoinstall" does the trick.

Here the error output for kernel 5.1.15 when dkms tries to build a module for nvidia-340:

Building initial module for 5.1.15-050115-generic
ERROR (dkms apport): kernel package linux-headers-5.1.15-050115-generic is not supported
Error! Bad return status for module build on kernel: 5.1.15-050115-generic (x86_64)
Consult /var/lib/dkms/nvidia-340/340.107/build/make.log for more information.
dpkg: fout bij verwerken van pakket nvidia-340 (--configure):
 subproces van pakket nvidia-340 werd script post-installation geïnstalleerd gaf de foutwaarde 10 terug

[vatbier (vatbier)]

Forgot to mention that the command
lspci -nnk | grep -iA2 vga
was the easiest way to see what display driver is running (nouveau or nvidia).

Other commands found on the internet, didn't work on my laptop.
(glxinfo also shows info but you have to scroll a lot)

[vatbier (vatbier)]

a few weeks ago I have been able to build dkms nividia 340 kernel module for mainline build 5.1.16.
Install NVIDIA-Linux-x86_64-340.107 with kernel 5.0 and 5.1 patches from https://pkgs.rpmfusion.org/cgit/nonfree/nvidia-340xx-kmod.git/log/ (I had to fix one of the patches myself) with ubuntu's mainline kernel 5.1.16.
I also had to extract the *custom.run to disable compiling of uvm (dkms.conf and Makefile).

[bfluehr (bfluehr)]

I had this same problem on a Dell Inspiron 6400, which has Broadcom BCM4311 network controller and Broadcom BCM4401-B0 Ethernet controller.

Kernel 5.0.0-27 manifests the problem. Kernels 4.15.0-60 and 5.2.0-15 work fine.