search

openwrt / openwrt

This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins. We will continue to accept Pull Requests here. They will be merged via staging trees then into openwrt.git.
Other
19.75k stars 10.29k forks source link

NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out #11932

Open qussss opened 1 year ago

qussss commented 1 year ago

Describe the bug

[12606.027405] ------------[ cut here ]------------ [12606.028094] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:467 0xc080f248 [12606.031445] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out [12606.038419] Modules linked in: pppoe ppp_async option nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet ath10k_pci ath10k_core ath wireguard usb_wwan qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_chain_nat nf_tables nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_amanda nf_nat nf_flow_table nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast nf_conntrack_amanda nf_conntrack mac80211 libchacha20poly1305 curve25519_neon cfg80211 usbserial usbnet ts_kmp ts_fsm ts_bm slhc poly1305_arm nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_ipv6 nf_log_ipv4 nf_log_common nf_defrag_ipv6 nf_defrag_ipv4 libcurve25519_generic libcrc32c hwmon crc_ccitt compat chacha_neon cdc_wdm [12606.046733] asn1_decoder ip6_udp_tunnel udp_tunnel tun kpp ghash_arm_ce cmac leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom gpio_button_hotplug mii crc32c_generic [12606.133678] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.161 #0 [12606.148821] Hardware name: Generic DT based system [12606.154950] Function entered at [] from [] [12606.159612] Function entered at [] from [] [12606.165424] Function entered at [] from [] [12606.171237] Function entered at [] from [] [12606.177060] Function entered at [] from [] [12606.182875] Function entered at [] from [] [12606.188688] Function entered at [] from [] [12606.194501] Function entered at [] from [] [12606.200311] Function entered at [] from [] [12606.206136] Function entered at [] from [] [12606.211948] Function entered at [] from [] [12606.217767] Function entered at [] from [] [12606.223583] Function entered at [] from [] [12606.229394] Exception stack(0xc0c01f20 to 0xc0c01f68) [12606.235306] 1f20: 0093cd16 00000000 0093cd18 c0312c00 c0c00000 00000000 c0c04f14 c0c04f54 [12606.240444] 1f40: 00000000 00000000 10c5387d c0b45fe8 c0c04fcc c0c01f70 c0306fec c0306ff0 [12606.248513] 1f60: 60000013 ffffffff [12606.256645] Function entered at [] from [] [12606.259951] Function entered at [] from [] [12606.265860] Function entered at [] from [] [12606.271666] Function entered at [] from [] [12606.277578] ---[ end trace e6b0a2c2acef730e ]---

OpenWrt version

r20035-aa5023b9cd

OpenWrt target/subtarget

ipq40xx/generic

Device

ZTE MF289F

Image kind

Official downloaded image

Steps to reproduce

No response

Actual behaviour

No response

Expected behaviour

No response

Additional info

No response

Diffconfig

No response

Terms

mrkiko commented 1 year ago

Hi!

Thank you for your report. Still, I don't think this is related to OpenWrt.

qussss commented 1 year ago

Hi!

Thank you for your report. Still, I don't think this is related to OpenWrt.

Is it related with issue with hardware?

mrkiko commented 1 year ago

No, this doesn't indicate necessarily a hardware problem. It may depend on network conditions, or - how the mobile modem firmware interacts with them. Probably @bmork has a better answer. :)

On Sat, 4 Feb 2023, qussss wrote:

Date: Sat, 4 Feb 2023 11:21:42 From: qussss @.> Reply-To: openwrt/openwrt @.> To: openwrt/openwrt @.> Cc: mrkiko @.>, Comment @.***> Subject: Re: [openwrt/openwrt] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out (Issue #11932)

  Hi!

  Thank you for your report. Still, I don't think this is related to OpenWrt.

Is it related with issue with hardware?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.[AEA6HOPXIWEVYM22XJEAX2TWVYUTNA5CNFSM6AAAAAAURBRI4SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSUOFPTQ.gif] Message ID: @.***>

bmork commented 1 year ago

Not much more to add here. Radio networks can never guarantee that it will be possible to transmit a packet within reasonable time. We still have to set some arbitrary timeout where we give up waiting. That warning is printed when this happens. It is not an error.

There are of course also a number of real errors which will cause transmit timeouts, and therefore producing the same warning.

Unfortunately there is no way to tell the difference based on this warning. You have to look at other symptoms. Do all packets time out? That's an error. Are there other messages in the log indicating errors? Etc.

But if this is an occasional warning then there is no need to worry. Yes, I know it looks terrifying with the whole stack trace. This is basically because the code is shared with all types of network adapters, and such timeouts are unexpected for most of them.