Hi all,
I have a strange issue after the upgrade to -current ( last week ) but I think they are dependent from the kernel bump from 4.19.80-v7+ to 5.4.21-v7
Basically what happens is that the "external interface":
Code:
Bus 001 Device 004: ID 0424:7500 Standard Microsystems Corp. LAN7500 Ethernet 10/100/1000 Adapter
when there is a high load on whichever network interface ( i will clarify this in a second ) in someway hangs.
Only nn the first hang I get an kernel oop, ad after that she start suspending transmit and I need an
Code:
ifconfig eth1 down
ifconfig eth1 up
to get her start working again.
To explain better, here is my physical config:
Code:
INTERNET-----eth1-Pi-eth0-----INTERNAL_LAN
As i told before, whenever there is a high load on the network stack on the first hang I get this message:
Code:
[Thu Feb 27 15:18:39 2020] smsc75xx 1-1.2:1.0 eth1: link up, 1000Mbps, full-duplex, lpa 0xDDE1
[Thu Feb 27 15:19:31 2020] ------------[ cut here ]------------
[Thu Feb 27 15:19:31 2020] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:447 dev_watchdog+0x310/0x314
[Thu Feb 27 15:19:31 2020] NETDEV WATCHDOG: eth1 (smsc75xx): transmit queue 0 timed out
[Thu Feb 27 15:19:31 2020] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_REDIRECT xt_nat xt_MASQUERADE xt_multiport xt_recent ipt_SYNPROXY nf_synproxy_core xt_CT xt_tcpudp xt_state xt_conntrack iptable_raw iptable_nat iptable_filter ip_tables x_tables nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack nf_defrag_ipv4 bridge stp llc tun ipv6 nf_defrag_ipv6 dm_mod evdev smsc75xx brcmfmac brcmutil rtc_ds1307 sha256_generic libsha256 cfg80211 bcm2835_codec(C) videobuf2_dma_contig bcm2835_v4l2(C) rfkill v4l2_mem2mem bcm2835_mmal_vchiq(C) videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common raspberrypi_hwmon hwmon i2c_bcm2835 videodev vc_sm_cma(C) mc uio_pdrv_genirq uio fixed
[Thu Feb 27 15:19:31 2020] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G C 5.4.21-v7 #3
[Thu Feb 27 15:19:31 2020] Hardware name: BCM2835
[Thu Feb 27 15:19:31 2020] Backtrace:
[Thu Feb 27 15:19:31 2020] [<8010de94>] (dump_backtrace) from [<8010e1e4>] (show_stack+0x20/0x24)
[Thu Feb 27 15:19:31 2020] r7:ba93a000 r6:00000000 r5:600e0113 r4:80d920dc
[Thu Feb 27 15:19:31 2020] [<8010e1c4>] (show_stack) from [<8088b4c8>] (dump_stack+0xd4/0x118)
[Thu Feb 27 15:19:31 2020] [<8088b3f4>] (dump_stack) from [<801202bc>] (__warn+0xe0/0x108)
[Thu Feb 27 15:19:31 2020] r10:bb053440 r9:00000009 r8:8079a520 r7:000001bf r6:8079a520 r5:00000009
[Thu Feb 27 15:19:31 2020] r4:80b0832c r3:00000000
[Thu Feb 27 15:19:31 2020] [<801201dc>] (__warn) from [<801206bc>] (warn_slowpath_fmt+0xa8/0xc4)
[Thu Feb 27 15:19:31 2020] r7:000001bf r6:80b0832c r5:80b082f0 r4:ba93a000
[Thu Feb 27 15:19:31 2020] [<80120618>] (warn_slowpath_fmt) from [<8079a520>] (dev_watchdog+0x310/0x314)
[Thu Feb 27 15:19:31 2020] r9:ba93a000 r8:ba33f000 r7:00000003 r6:80d03d00 r5:ba33f2a8 r4:00000000
[Thu Feb 27 15:19:31 2020] [<8079a210>] (dev_watchdog) from [<80198544>] (call_timer_fn+0x40/0x1a0)
[Thu Feb 27 15:19:31 2020] r8:0025fe28 r7:00000100 r6:8079a210 r5:ba33f2a8 r4:ba33f2a8
[Thu Feb 27 15:19:31 2020] [<80198504>] (call_timer_fn) from [<80198cd0>] (run_timer_softirq+0x248/0x63c)
[Thu Feb 27 15:19:31 2020] r8:0025fe28 r7:00000000 r6:80d97ee0 r5:ba33f2a8 r4:ba93be28
[Thu Feb 27 15:19:31 2020] [<80198a88>] (run_timer_softirq) from [<8010247c>] (__do_softirq+0x18c/0x410)
[Thu Feb 27 15:19:31 2020] r10:ba93a000 r9:00000282 r8:ba89c000 r7:00000100 r6:00000001 r5:00000002
[Thu Feb 27 15:19:31 2020] r4:80d03084
[Thu Feb 27 15:19:31 2020] [<801022f0>] (__do_softirq) from [<8012625c>] (irq_exit+0xdc/0x100)
[Thu Feb 27 15:19:31 2020] r10:00000000 r9:ba93a000 r8:ba89c000 r7:00000001 r6:00000000 r5:00000000
[Thu Feb 27 15:19:31 2020] r4:ffffe000
[Thu Feb 27 15:19:31 2020] [<80126180>] (irq_exit) from [<8017d7e0>] (__handle_domain_irq+0x70/0xc0)
[Thu Feb 27 15:19:31 2020] r5:00000000 r4:80c99264
[Thu Feb 27 15:19:31 2020] [<8017d770>] (__handle_domain_irq) from [<80102224>] (bcm2836_arm_irqchip_handle_irq+0x64/0xa4)
[Thu Feb 27 15:19:31 2020] r9:ba93a000 r8:80d974f4 r7:ba93bf6c r6:ffffffff r5:600e0013 r4:80109ad0
[Thu Feb 27 15:19:31 2020] [<801021c0>] (bcm2836_arm_irqchip_handle_irq) from [<80101a3c>] (__irq_svc+0x5c/0x7c)
[Thu Feb 27 15:19:31 2020] Exception stack(0xba93bf38 to 0xba93bf80)
[Thu Feb 27 15:19:31 2020] bf20: 00000000 3a3c1000
[Thu Feb 27 15:19:31 2020] bf40: 600e0093 600e0093 ba93a000 00000003 80d04d64 80d04dac 80d974f4 80a9a8a0
[Thu Feb 27 15:19:31 2020] bf60: 00000000 ba93bf94 ffffe000 ba93bf88 ba93a000 80109ad0 600e0013 ffffffff
[Thu Feb 27 15:19:31 2020] [<80109a9c>] (arch_cpu_idle) from [<808a97d4>] (default_idle_call+0x34/0x48)
[Thu Feb 27 15:19:31 2020] [<808a97a0>] (default_idle_call) from [<801539a0>] (do_idle+0xec/0x16c)
[Thu Feb 27 15:19:31 2020] [<801538b4>] (do_idle) from [<80153cf8>] (cpu_startup_entry+0x28/0x2c)
[Thu Feb 27 15:19:31 2020] r9:410fd034 r8:0000406a r7:80da8710 r6:10c0387d r5:00000003 r4:00000089
[Thu Feb 27 15:19:31 2020] [<80153cd0>] (cpu_startup_entry) from [<8010fc14>] (secondary_start_kernel+0x160/0x16c)
[Thu Feb 27 15:19:31 2020] [<8010fab4>] (secondary_start_kernel) from [<0010278c>] (0x10278c)
[Thu Feb 27 15:19:31 2020] r5:00000055 r4:3a92406a
[Thu Feb 27 15:19:31 2020] ---[ end trace bf88d81f97966385 ]---
This particular problem as showed up while I was dumping my filesystem via ssh on internal net:
Code:
dump 0uf - / | ssh root@internalhost "cat > /extdisk/Backup.dump"
The internal net, btw has had no problem ( the dump continued flawlessly ) while I wasn't able to reach internet ( either from Pi then from any host on internal net ).
So apparently the problem is in network-area of the kernel, or eventually in some obscure area of firmwares or overlays.
Needed to say that with 4.19.80-v7+ or all the precedents kernels I hadn't had this issue never, also if I did exactly the same stuffs ( lot and lot of time ).
Any hint on how to fix this or who to report ?
Thanks in advance
Pigi
