项目有20台工业网关，使用EM05-CE模组，会不同不同频次出现断网。
经查日志都会有这条记录“NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out”
我是用户，集成商支持有限，请问有哪些问题可能会触发，能否帮忙指导一下排查步骤？万分感谢！日志如下
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13176.965254] ------------[ cut here ]------------
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13176.969923] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:473 dev_watchdog+0x288/0x28c
Thu Jan 2 14:48:08 2025 kern.info kernel: [13176.978210] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13176.985002] Modules linked in: rtl8192cu rtl8192c_common rtl_usb rt2800usb rt2800lib rt2500usb qcserial pppoe ppp_async option mt76x0u mt76x0_common iptable_nat cdc_mbim ath6kl_usb ath6kl_core xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xradio_wlan usb_wwan rtlwifi rt2x00usb rt2x00lib rndis_host qmi_wwan pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack mt76x2u mt76x2_common mt76x02_usb mt76x02_lib mt7601u mt76_usb mt76 mac80211 ipt_REJECT huawei_cdc_ncm cfg80211 cdc_ncm cdc_ether asix xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG usbserial usbnet slhc r8712u(C) nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 mcp251x iptable_mangle iptable_filter ip_tables goodix compat cdc_wdm can_raw can_dev can_bcm evdev usb_f_acm u_serial usb_f_ecm u_ether libcomposite rtc_sunxi ledtrig_gpio nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 tun snd_rawmidi
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13176.985149] snd_seq_device snd_pcm_oss snd_mixer_oss snd_hwdep autofs4 pwm_sun8i pwm_bl sun4i_emac wk2xxx_spi ch432 rtc_sd3078 rtc_rx8010 at24 ahci_sunxi fsl_mph_dr_of ehci_fsl ahci_platform libahci_platform libahci gpio_button_hotplug yt8521s yt8512c sun8i_drm_hdmi dw_hdmi sun4i_drm_hdmi cec sun6i_mipi_dsi crc_ccitt phy_sun6i_mipi_dphy panel_simple panel_lvds backlight sun8i_mixer sun6i_drc sun4i_tv sun4i_drm sun4i_tcon sun8i_tcon_top sun4i_backend sun4i_frontend mali_dp drm_kms_helper sysimgblt sysfillrect syscopyarea fb_sys_fops lima gpu_sched drm drm_panel_orientation_quirks
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.123857] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G C 5.4.268 #0
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.131251] Hardware name: Allwinner sun8i Family
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.135976] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.143728] [] (show_stack) from [] (dump_stack+0x94/0xa8)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.150958] [] (dump_stack) from [] (__warn+0xa0/0xbc)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.157834] [] (__warn) from [] (warn_slowpath_fmt+0x84/0x94)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.165324] [] (warn_slowpath_fmt) from [] (dev_watchdog+0x288/0x28c)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.173504] [] (dev_watchdog) from [] (call_timer_fn.constprop.10+0x24/0x98)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.182289] [] (call_timer_fn.constprop.10) from [] (run_timer_softirq+0x3fc/0x428)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.191682] [] (run_timer_softirq) from [] (__do_softirq+0x120/0x2b0)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.199861] [] (__do_softirq) from [] (irq_exit+0xb0/0xd4)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.207088] [] (irq_exit) from [] (__handle_domain_irq+0x60/0xb4)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.214919] [] (__handle_domain_irq) from [] (gic_handle_irq+0x4c/0x90)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.223269] [] (gic_handle_irq) from [] (__irq_svc+0x58/0x74)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.230748] Exception stack(0xde07bf78 to 0xde07bfc0)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.235798] bf60: 00000000 03a97c04
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.243974] bf80: dffb25f4 c0235c40 ffffe000 c0e04eb4 c0e04ef4 00000008 c0e0dd18 c097e910
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.252150] bfa0: 00000000 00000000 00000000 de07bfc8 c0229c34 c0229c38 60000013 ffffffff
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.260330] [] (__irq_svc) from [] (arch_cpu_idle+0x38/0x3c)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.267731] [] (arch_cpu_idle) from [] (do_idle+0x110/0x154)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.275128] [] (do_idle) from [] (cpu_startup_entry+0x18/0x1c)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.282699] [] (cpu_startup_entry) from [<402027ec>] (0x402027ec)
Thu Jan 2 14:48:08 2025 kern.warn kernel: [13177.289685] —[ end trace 5e317b578f6f22c9 ]—
Thu Jan 2 15:08:54 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending renew to 160.173.45.221
Thu Jan 2 15:38:54 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending renew to 160.173.45.221
Thu Jan 2 15:53:54 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending renew to 160.173.45.221
Thu Jan 2 16:01:24 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending renew to 160.173.45.221
Thu Jan 2 16:05:09 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending renew to 160.173.45.221
Thu Jan 2 16:07:01 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending renew to 160.173.45.221
Thu Jan 2 16:07:57 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending renew to 0.0.0.0
Thu Jan 2 16:08:26 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending renew to 0.0.0.0
Thu Jan 2 16:08:40 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending renew to 0.0.0.0
Thu Jan 2 16:08:47 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending renew to 0.0.0.0
Thu Jan 2 16:08:50 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending renew to 0.0.0.0
Thu Jan 2 16:08:52 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending renew to 0.0.0.0
Thu Jan 2 16:08:52 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: lease lost, entering init state
Thu Jan 2 16:08:52 2025 daemon.notice netifd: Interface ‘4g_wan_4’ has lost the connection
Thu Jan 2 16:08:52 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending discover
Thu Jan 2 16:08:55 2025 daemon.notice netifd: 4g_wan_4 (4582): udhcpc: sending discover
是否使用quectel-CM拨号？
是否存在未拨号的情况下就已经up了网卡并尝试传输？
这个是usbnet内核常见的一个错误。通常就是在一定时间内由于CPU的处理能力不足，传输大量网络任务数据无法完成，就会重启线程。
对这个qmi_wwan的网卡，还有一个特点，就是必须是拨号成功后，才能进行网络通信。
不管是哪一种拨号方式（AT拨号还是quectel-CM还是ModemManager\qmicli\uqmi 等），必须是拨号成功的状态下，才能使用这个网卡。
你这个是一个OpenWrt，后台是否是调用的uqmi, 如果是quectel-CM，最好提供下出现问题前的quectel-CM的打印。
您好，经确认拨号方式是uqmi。
因为是正常运行一段时间以后出现的错误，我理解应该不存在“未拨号的情况下就已经up了网卡并尝试传输”这种情况。
请您看下系统日志，前面是正常运行，莫名就出了。
由于测试的设备都在一起，对比各个设备出现错误的时间，之间并没有规律或者相干性。
这个log，在拨号成功和出现问题之间，是否有监控是否拨号断开的情况。
uqmi拨号后，在拨号断开后，是否会主动上报拨号断开？quectel-CM 采用轮询拨号的状态，一旦拨号断开或者掉网了，就会主动断开拨号并ifconfig wwan0 down. 我不确定您的系统是否也有对应的机制。
您好，网关设备厂家回复有拨号监控，是基于检测4g拨号网卡是否具备ip地址来判断的。
由于厂家也放假了，我询问他们是否有这一层的日志，到目前还没有回复。
如果是出现的概率非常小，认为可以考虑重启下设备。如果比较大的复现概率，希望可以使用移远的工具对比测试下。这个主控是MT7621吗？
7621 好像还有使能下USB 零包机制，也有可能是零包的问题导致的。
新年好~，假期间运行10台设备有6台各出现了一次，概率上来说也不是很好复现。
还请指导一下使用哪款工具、怎样对比测试啊？我好好准备下
另，这个主控看了下是A40i-H。
请使用quectel-CM测试。
上面的内核版本是多少
内核版本是5.4.268
嗯嗯好的，我研究一下quectel-CM
框出来的不是识别到了吗？
wwan0 本来就不是一个无线网卡设备。
您好，我观察的情况是：
网关机正常启动后，4G模组在usb3-1（高速）口正常识别到。
当前述看门狗报错后，由于网关机自身的断网检测机制，进行重置4G模组，此后在usb3-1反复识别错误，attempt power cycle不一定多少轮后，在usb6-1（全速）被识别到。
所以我想补充这个情况，是否正常，是不是这个现象背后潜在的问题导致的看门狗报错。
USB 枚举的问题，建议找硬件看看电路。
1.重启模组建议有一个时间间隔的限制，不能出现任何问题就立即重启模组，譬如第一次出现问题5秒后重启，第二次10秒后重启；
2. 重启了一定次数后，就不要继续不停重启模组，很容易弄坏了模组。