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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1861936 Title: Raspberry Pi 3 network dies shortly after a burst of IPv6 tunnel network load ((lan78xx): transmit queue 0 timed out) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1861936/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
