“NETDEV WATCHDOG: eth0 (r8168) error

The same problem occurs with Orin NX 16GB.
R8168 error - Jetson & Embedded Systems / Jetson Nano - NVIDIA Developer Forums

・SOM: Orin NX 16GB
・JetPack: L4T r35.5.0 (JetPack 5.1.3)

Are there any common bugs?
[2024-04-03 08:56:34.912] [143308.465586] ------------[ cut here ]------------
[2024-04-03 08:56:34.912] [143308.470488] NETDEV WATCHDOG: eth0 (r8168): transmit queue 0 timed out
[2024-04-03 08:56:34.912] [143308.470536] WARNING: CPU: 5 PID: 0 at net/sched/sch_generic.c:467 dev_watchdog+0x3d4/0x3e0
[2024-04-03 08:56:34.929] [143308.479141] Modules linked in: fuse iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter lzo_rle lzo_compress zram ramoops reed_solomon smsc smsc95xx r8168 loop snd_soc_tegra186_asrc snd_soc_tegra210_ope snd_soc_tegra186_dspk snd_soc_tegra210_iqc snd_soc_tegra186_arad snd_soc_tegra210_mvc snd_soc_tegra210_afc snd_soc_tegra210_dmic snd_soc_tegra210_adx snd_soc_tegra210_admaif snd_soc_tegra210_mixer snd_soc_tegra210_amx snd_soc_tegra210_i2s snd_soc_tegra210_sfc snd_soc_tegra_pcm snd_soc_tegra210_adsp binfmt_misc snd_soc_spdif_tx snd_soc_tegra_machine_driver snd_soc_tegra_utils snd_hda_codec_hdmi snd_soc_simple_card_utils nvadsp snd_hda_tegra tegra_bpmp_thermal snd_hda_codec tegra210_adma snd_soc_tegra210_ahub snd_hda_core userspace_alert nv_imx219 nvidia(OE) xilinx_ps_pcie_dma_client ina3221 pwm_fan ip_tables x_tables overlay nvgpu aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce sha2_ce sha256_arm64 sha1_ce nvmap spi_tegra114 [last unloaded: mtd]
[2024-04-03 08:56:34.941] [143308.479309] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G OE 5.10.192-tegra #2
[2024-04-03 08:56:34.941] [143308.479312] Hardware name: NVIDIA Orin NX Developer Kit (DT)
[2024-04-03 08:56:34.941] [143308.479318] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=–)
[2024-04-03 08:56:34.941] [143308.479323] pc : dev_watchdog+0x3d4/0x3e0
[2024-04-03 08:56:34.941] [143308.479327] lr : dev_watchdog+0x3d4/0x3e0
[2024-04-03 08:56:34.941] [143308.479330] sp : ffff80001002bd50
[2024-04-03 08:56:34.941] [143308.479333] x29: ffff80001002bd50 x28: 0000000000000001
[2024-04-03 08:56:34.941] [143308.479339] x27: 0000000000000004 x26: 0000000000000140
[2024-04-03 08:56:34.941] [143308.479345] x25: ffff31c4f29dce80 x24: 00000000ffffffff
[2024-04-03 08:56:34.941] [143308.479351] x23: ffff31c1c6eb83dc x22: ffffc6c6f7d16000
[2024-04-03 08:56:34.941] [143308.479356] x21: ffff31c1c6eb8000 x20: ffff31c1c6eb8480
[2024-04-03 08:56:34.941] [143308.479362] x19: 0000000000000000 x18: 0000000000000000
[2024-04-03 08:56:34.959] [143308.479367] x17: 0000000000000000 x16: ffffc6c6f60250f0
[2024-04-03 08:56:34.959] [143308.479373] x15: ffff31c1c0224f30 x14: ffffffffffffffff
[2024-04-03 08:56:34.959] [143308.479378] x13: ffffc6c6f8039e28 x12: ffffc6c6f8039a78
[2024-04-03 08:56:34.959] [143308.479383] x11: 0000000000000000 x10: 0000000000000001
[2024-04-03 08:56:34.959] [143308.479389] x9 : 00000000fffffffe x8 : 756f2064656d6974
[2024-04-03 08:56:34.959] [143308.479395] x7 : 2030206575657571 x6 : 0000000000000003
[2024-04-03 08:56:34.959] [143308.479400] x5 : 0000000000000000 x4 : 0000000000000000
[2024-04-03 08:56:34.959] [143308.479406] x3 : 0000000000000100 x2 : 0000000000000100
[2024-04-03 08:56:34.959] [143308.479411] x1 : 0000000000000000 x0 : 0000000000000000
[2024-04-03 08:56:34.959] [143308.479417] Call trace:
[2024-04-03 08:56:34.959] [143308.479423] dev_watchdog+0x3d4/0x3e0
[2024-04-03 08:56:34.959] [143308.479430] call_timer_fn+0x3c/0x200
[2024-04-03 08:56:34.959] [143308.479434] run_timer_softirq+0x50c/0x5e0
[2024-04-03 08:56:34.959] [143308.479439] __do_softirq+0x140/0x3e8
[2024-04-03 08:56:34.959] [143308.479445] irq_exit+0xc0/0xe0
[2024-04-03 08:56:34.976] [143308.479453] __handle_domain_irq+0x74/0xd0
[2024-04-03 08:56:34.976] [143308.479457] gic_handle_irq+0x68/0x134
[2024-04-03 08:56:34.976] [143308.479460] el1_irq+0xd0/0x180
[2024-04-03 08:56:34.976] [143308.479468] cpuidle_enter_state+0xb8/0x410
[2024-04-03 08:56:34.976] [143308.479471] cpuidle_enter+0x40/0x60
[2024-04-03 08:56:34.976] [143308.479476] call_cpuidle+0x44/0x80
[2024-04-03 08:56:34.976] [143308.479480] do_idle+0x208/0x270
[2024-04-03 08:56:34.976] [143308.479483] cpu_startup_entry+0x2c/0x60
[2024-04-03 08:56:34.976] [143308.479489] secondary_start_kernel+0x15c/0x180
[2024-04-03 08:56:34.976] [143308.479494] —[ end trace 0a16d0cbd8b1f08d ]—
[2024-04-03 08:56:34.976] [143310.844360] r8168: eth0: link up

please help clarify how to reproduce this issue.

I don’t have DevKit at hand, so I can’t try it with DevKit.

If I run the following on a custom board, the problem will be reproduced, so please check.
① Execute the “yes > /dev/null &” command 8 times
② Run iperf3 from a Windows computer
Windows PC: Clinet
Orin NX: Server
Windows PC Command: iperf3.exe -c IPAddress -p 8080 -t 1000

What is the purpose for this?

This is because I think that if the CPU is under high load, the problem may occur more easily.
It may be unrelated, but I haven’t been able to investigate the details.

Is there really any service using 8080 port on Jetson for this test case?

iperf3.exe -c IPAddress -p 8080 -t 1000

That’s right.
Jetson executes the following command.
iperfs -s -p 8080

1 Like

Sorry!

Could you try it?