Comment 43 for bug 1861936

Hi all,

From my tests, it doesn't seem like a problem related to ipv6, but with high load in 3B+ version. In my case its easy to reproduce if I use ipforward and connection state over 20.04 server pi image, more less from scratch, static ip, pihole, tun0 and no ipv6.

root@pin:/home/janzun# uname -a
Linux pin 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

# sysctl -p
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv4.ip_forward = 1|0 -> it depends

First test:

# echo 0 > /proc/sys/net/ipv4/ip_forward
# iptables -F; iptables -X; iptables -P INPUT|FORWARD|OUTPUT ACCEPT
# wget -O /dev/null https://*/10GB.bin ==> Some error in one of the attemps

Second test (forget the purpose of the rules):

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
# wget -O /dev/null https://*/10GB.bin ==> Allways stopped at about 1.5GB and crash (same with -p udp).

Kernel log:

Apr 25 18:11:21 localhost kernel: [22872.242430] ------------[ cut here ]------------
Apr 25 18:11:21 localhost kernel: [22872.242515] NETDEV WATCHDOG: eth0 (lan78xx): transmit queue 0 timed out
Apr 25 18:11:21 localhost kernel: [22872.242716] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:447 dev_watchdog+0x324/0x330
Apr 25 18:11:21 localhost kernel: [22872.242733] Modules linked in: 8021q garp mrp stp llc xt_multiport xt_state xt_conntrack xt_tcpudp iptab
Apr 25 18:11:21 localhost kernel: [22872.242956] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G C E 5.4.0-1008-raspi #8-Ubuntu
Apr 25 18:11:21 localhost kernel: [22872.242962] Hardware name: Raspberry Pi 3 Model B Plus Rev 1.3 (DT)
Apr 25 18:11:21 localhost kernel: [22872.242972] pstate: 60400005 (nZCv daif +PAN -UAO)
Apr 25 18:11:21 localhost kernel: [22872.242985] pc : dev_watchdog+0x324/0x330
Apr 25 18:11:21 localhost kernel: [22872.242995] lr : dev_watchdog+0x324/0x330
Apr 25 18:11:21 localhost kernel: [22872.243000] sp : ffff80001000bd60
Apr 25 18:11:21 localhost kernel: [22872.243005] x29: ffff80001000bd60 x28: 0000000000000140
Apr 25 18:11:21 localhost kernel: [22872.243014] x27: 00000000ffffffff x26: 0000000000000000
Apr 25 18:11:21 localhost kernel: [22872.243023] x25: ffff00002f650000 x24: ffffa8d07f545018
Apr 25 18:11:21 localhost kernel: [22872.243031] x23: 0000000000000000 x22: 0000000000000001
Apr 25 18:11:21 localhost kernel: [22872.243039] x21: ffff00002f650480 x20: ffffa8d07fa07000
Apr 25 18:11:21 localhost kernel: [22872.243047] x19: 0000000000000000 x18: 0000000000000000
Apr 25 18:11:21 localhost kernel: [22872.243055] x17: ffff800010876378 x16: 0000000000000000
Apr 25 18:11:21 localhost kernel: [22872.243063] x15: ffff000039234090 x14: ffffffffffffffff
Apr 25 18:11:21 localhost kernel: [22872.243072] x13: 0000000000000000 x12: ffffa8d07fb3e000
Apr 25 18:11:21 localhost kernel: [22872.243081] x11: ffffa8d07fa2c000 x10: 0000000000000000
Apr 25 18:11:21 localhost kernel: [22872.243088] x9 : 0000000000000004 x8 : 00000000000001cb
Apr 25 18:11:21 localhost kernel: [22872.243096] x7 : 0000000000000000 x6 : 0000000000000001
Apr 25 18:11:21 localhost kernel: [22872.243103] x5 : 0000000000000000 x4 : 0000000000000002
Apr 25 18:11:21 localhost kernel: [22872.243111] x3 : ffffa8d07ee15790 x2 : 0000000000000040
Apr 25 18:11:21 localhost kernel: [22872.243119] x1 : 3cb8609474fd0d00 x0 : 0000000000000000
Apr 25 18:11:21 localhost kernel: [22872.243128] Call trace:
Apr 25 18:11:21 localhost kernel: [22872.243138] dev_watchdog+0x324/0x330
Apr 25 18:11:21 localhost kernel: [22872.243155] call_timer_fn+0x3c/0x178
Apr 25 18:11:21 localhost kernel: [22872.243168] __run_timers.part.0+0x204/0x330
Apr 25 18:11:21 localhost kernel: [22872.243177] run_timer_softirq+0x40/0x78
Apr 25 18:11:21 localhost kernel: [22872.243188] __do_softirq+0x168/0x384
Apr 25 18:11:21 localhost kernel: [22872.243199] irq_exit+0xb0/0xe8
Apr 25 18:11:21 localhost kernel: [22872.243213] __handle_domain_irq+0x70/0xc0
Apr 25 18:11:21 localhost kernel: [22872.243222] bcm2836_arm_irqchip_handle_irq+0x74/0xe0
Apr 25 18:11:21 localhost kernel: [22872.243230] el1_irq+0x108/0x200
Apr 25 18:11:21 localhost kernel: [22872.243242] arch_cpu_idle+0x3c/0x1c8
Apr 25 18:11:21 localhost kernel: [22872.243255] default_idle_call+0x24/0x48
Apr 25 18:11:21 localhost kernel: [22872.243269] do_idle+0x210/0x2a0
Apr 25 18:11:21 localhost kernel: [22872.243278] cpu_startup_entry+0x28/0x30
Apr 25 18:11:21 localhost kernel: [22872.243291] secondary_start_kernel+0x134/0x1b8
Apr 25 18:11:21 localhost kernel: [22872.243297] ---[ end trace d80fb39a4340a900 ]---

Workaround 1, reboot on kernel message:

# cat /etc/rsyslog.d/60-lan7800-reboot.conf
:msg, regex, "transmit queue 0 timed" ^/usr/sbin/reboot

Workaround 2, better for me:

# crontab -e

* * * * * /scripts/7800-authorized.sh

Mine is version 3B+ with the following usb table:

# lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
            |__ Port 1: Dev 6, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
        |__ Port 3: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 3: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M

So:

# cat /scripts/7800-authorized.sh
#!/bin/sh

# The number of Ips and lines at your convenience, increasing the -c number has no sense.
ping -c1 192.168.1.1 > /dev/null && exit 0
ping -c1 192.168.1.45 > /dev/null && exit 0

echo 0 > /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.1/authorized
sleep 5
echo 1 > /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.1/authorized

logger [Error] Rebooting network iface due to module fail...

# eol

You cannot do a mix (rsyslog and 0/1 authorized) because kernel message happends only first time, until reboot.

Hope it helps you.