kernel 4.18.4 eth0: hw csum failure - Pi3b+ only

[polojoe]

I get following errors
eth0: hw csum failure
since upgrade to 4.18 from 4.14

kernel log http://ix.io/1l8g

rpi is connected directly to my isp router

[popcornmix]

How repeatable is the error? Do you see it every boot? Always after playing a video?
Can you try running:
ethtool -K eth0 rx off ; ethtool -K eth0 tx off

and let us know if problem still occurs?
Ping @6by9

[polojoe]

errors start repeatable several minutes after boot.
ethtool -K eth0 rx off ; ethtool -K eth0 tx off
solves errors in kernel log

[popcornmix]

Can you test just ethtool -K eth0 rx off and just ethtool -K eth0 tx off to see which is fixing the error?

[polojoe]

ethtool -K eth0 rx off
does the trick

[6by9]

I assume this is on a 3B+.
Are you running VLANs? That was the only time we were previously seeing these errors, and there was a patch that swapped to s/w checksum offload in those conditions.

[polojoe]

I'm using rpi3+, no vlan configured.
Direct lan connection to router with integrated 4 port 100 Mbit switch.

[maxnet]

I'm using rpi3+, no vlan configured.

[    4.827651] 8021q: 802.1Q VLAN Support v1.8
[    4.827687] 8021q: adding VLAN 0 to HW filter on device eth0

Module normally only gets loaded when you do configure VLAN tagging.
Or do you have a custom kernel configuration in which it is statically built into kernel?

[MilhouseVH]

Or do you have a custom kernel configuration in which it is statically built into kernel?

In LibreELEC 9 with rpi-4.18.y, the config from LibreELEC/LibreELEC.tv#2913 is being used.

A quick grep of the config for VLAN shows the following:

neil@nm-linux:~/projects/pullrequest_repos/LibreELEC.tv/projects/RPi/devices/RPi2$ git grep VLAN
linux/linux.arm.conf:# CONFIG_BRIDGE_VLAN_FILTERING is not set
linux/linux.arm.conf:CONFIG_VLAN_8021Q=m
linux/linux.arm.conf:# CONFIG_VLAN_8021Q_GVRP is not set
linux/linux.arm.conf:# CONFIG_VLAN_8021Q_MVRP is not set
linux/linux.arm.conf:CONFIG_MACVLAN=m
linux/linux.arm.conf:# CONFIG_IPVLAN is not set

The same VLAN options are being used for rpi-4.14.y which doesn't appear to have any problems.

[maxnet]

The same VLAN options are being used for rpi-4.14.y which doesn't appear to have any problems.

Ok.
Probably connman doing something that pulls in the module then.
Module is not loaded on distributions with other network managers like Raspbian's dhcpcd.

If it already did so in previous versions, then that's probably not the problem
But perhaps you can still try adding module_blacklist=8021q to cmdline.txt, to see if it's any different without it?

(Have not seen any checksum problems in 4.17 or 4.18 myself, even though running network intensive software)

[MilhouseVH]

But perhaps you can still try adding module_blacklist=8021q to cmdline.txt module_blacklist=8021q

I guess it's something we (@polojoe) can rule out - I added module_blacklist=8021q to the LibreELEC kernel command line and can confirm the VLAN module is no longer loaded. LibreELEC (on an RPi3+, wired ethernet) appears to be behaving normally without it.

(Have not seen any checksum problems in 4.17 or 4.18 myself, even though running network intensive software)

No, me neither - my network seems to be frustratingly boring and problem free. :(

[polojoe]

Blacklist doesn't work for me
Commandline http://ix.io/1lfr
Kernel log http://ix.io/1lfq

[OrN]

I can confirm this issue happens on RPi 2 as well on kernel version 4.14.71. "Fixable" with

ethtool -K eth0 rx off

but that isnt a real solution.

EDIT: I didn't bisect it, but the issue isn't present in 4.14.18. Going to be using it for now, it got broken somewhere between 4.14.18 and 4.14.71.

[therealbstern]

I'm getting this without VLANs in use. I am using NAT and iptables, but not VLANs.

RPi 3, Linux beret 4.14.72-v7+ #1146 SMP Wed Sep 26 16:58:28 BST 2018 armv7l GNU/Linux

[JamesH65]

@therealbstern and does the ethtool -K eth0 rx off make the issue go away?

[therealbstern]

It did.