New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out #211
Comments
Also to note that this router is constantly transferring around 12Mbps of data between Wi-Fi and LAN 24/7 and that both router/NAT/software offloading is turned off (since that was causing crashes if I tried it earlier)... No USB devices are connected to the router at the time. Kernel is on 4.14.78. |
This issue is not connected with the wifi driver, but with the switch. I have experienced the same issue and started a discussion some time ago on the OpenWRT-mailing list. We have not been able to find a solution, but if you skip to the last email in the thread you can read a description of my current work-around. The short version is that in my case, the timeout problem was caused by pause frames. Disabling flow control on the switch made the issue go away in my case. If you (or other) are interested, I can brush up my patch and submit it to the OpenWRT mailing list for review. |
Count me in... Have you experienced any issues with flow control turned off? |
No, I have not experienced any issues. When I worked on the issue I did some research on flow control and how it is handled in other networks drivers. It seems that flow control is mostly disabled by default. Also, it seems that flow control is quite a ... controversial feature and at least most of the references I found say that it should never have been implemented. I will clean up and try to submit my patch during the weekend and let you know. However, I guess you can close this issue since error is not related to mt76. |
Great - is there somewhere I can monitor this so I can get updates on it after closing this issue? Thanks! |
Well looks like in the latest commits I am not seeing this anymore... I do see there were some changes made to mt76 - maybe they are related - will close this for now. |
this issues still exists .... tried newest TRUNK version ... (MT7620 MT 7621) how is it possible to disable the FLOW CONTROL ? is that possible via settings on /etc/cfg dir ? problems ...
|
Latest snapshot as of today (on a Dlink 860L, mtk7621):
|
This repo contains MTK wireless drivers, while the issue is related to MT7530 commutation chip, but also this page is one of the first, when you are trying to google error message, so i will dare to post here. |
Can you explain how to do that on the router side? I also have mt7621, but I was not able to turn it off via normal methods. Thanks! |
@dchard as soon as i remember, using standard interfaces like debugfs, there is no way to check chip revision (i did it, adding pr_info("Chip rev: %u", rt_sysc_r32(SYSC_REG_CHIP_REV_ID)) to the code), nor a way to disable flow control.
, placed into the file: target/linux/ramips/patches-4.14/220-mt7621-disable-flow-control.patch |
Several users have been reporting crashing issues with the ethernet driver. One source says that this is a silicon bug in mt7621: openwrt/mt76#211 (comment) A user that has been testing this has seen greater than 2-3 days uptime of the ethernet interface with this change: https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/50000/12 Signed-off-by: Rosen Penev <rosenp@gmail.com>
Several users have been reporting crashing issues with the ethernet driver. One source says that this is a silicon bug in mt7621: openwrt/mt76#211 (comment) A user that has been testing this has seen greater than 2-3 days uptime of the ethernet interface with this change: https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/50000/12 Signed-off-by: Rosen Penev <rosenp@gmail.com>
Several users have been reporting crashing issues with the ethernet driver. One source says that this is a silicon bug in mt7621: openwrt/mt76#211 (comment) A user that has been testing this has seen greater than 2-3 days uptime of the ethernet interface with this change: https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/50000/12 Signed-off-by: Rosen Penev <rosenp@gmail.com>
Several users have been reporting crashing issues with the ethernet driver. One source says that this is a silicon bug in mt7621: openwrt/mt76#211 (comment) A user that has been testing this has seen greater than 2-3 days uptime of the ethernet interface with this change: https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/50000/12 Signed-off-by: Rosen Penev <rosenp@gmail.com>
Several users have been reporting crashing issues with the ethernet driver. One source says that this is a silicon bug in mt7621: openwrt/mt76#211 (comment) A user that has been testing this has seen greater than 2-3 days uptime of the ethernet interface with this change: https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/50000/12 Signed-off-by: Rosen Penev <rosenp@gmail.com>
Several users have been reporting crashing issues with the ethernet driver. One source says that this is a silicon bug in mt7621: openwrt/mt76#211 (comment) A user that has been testing this has seen greater than 2-3 days uptime of the ethernet interface with this change: https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/50000/12 backport it to 17.01 https://patchwork.ozlabs.org/project/openwrt/patch/1459866124-17771-1-git-send-email-cristian@samknows.com/ Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: lunaticurey <125438787@qq.com>
Several users have been reporting crashing issues with the ethernet driver. One source says that this is a silicon bug in mt7621: openwrt/mt76#211 (comment) A user that has been testing this has seen greater than 2-3 days uptime of the ethernet interface with this change: https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/50000/12 backport it to 17.01 https://patchwork.ozlabs.org/project/openwrt/patch/1459866124-17771-1-git-send-email-cristian@samknows.com/ Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: lunaticurey <125438787@qq.com> (cherry picked from commit d968df3)
MT7620, I faced this problem, 19.07.03, 4.14kernel. Perhaps I missed the patch above, you will have to rebuild. :(
|
Same problem
|
It might (or might not) be related, I have the same router that drew my blood for months with same switch issues until I found this volt-mod scheme. Looks like this router is undervolted by default compared to datasheet spec. Once I've modded it to 1.1 volts it became rock-stable. I've never saw such crashes for about 2 month already. |
Same problem here on ZBT-WE1326 When i was on 19.07.03 i had over 100days uptime. Now on 19.07.04 the issue occurs daily. Today the router lasted on 30min
|
Confirming the same issue on TP-Link Archer C20 v1 (mt7620) and OpenWRT 19.07.4. |
Hey guys please stop spamming this issue, which originally had nothing to do with mt76 driver, is already closed for almost 2 years, and besides it has nothing to do with the problem you are facing now. Not only it does not make sense, but also the devs won't read or reply to it. And bothers everyone else who is following the driver's evolution and receiving the true issues' messages by email (which is my case). I'm not affiliated with the team developing the driver or openwrt, but please search or seek help in the appropriate channels, in this case the openwrt forum and the openwrt bug tracker. Anyway your problem is only on the 19.07 branch and was introduced in someone's attempt to fix what didn't need fixing in here: openwrt/openwrt@7ac4540 That was reverted here, after the 19.07.4 release: openwrt/openwrt@34a9652 So your options are (assuming you want to remain on the stable branch):
But it makes zero sense to complain of a ethernet driver problem on a closed issue of the the WiFi driver. As I said, next time please search the forum. |
For reference for everyone like me, who stumbles across this thread while searching for this symptom, here a little hint for a possible cause beside kernel issues. If you are using the image builder or do somehow else mess around with the network configuration: If you miss to configure the internal ethernet switch of the mt76, i.e. not include the |
It looks like on my Xiaomi 3G device the device crashes every other day or so and would require a hard reboot to get traffic to flow again. This problem has been there for a while now, and the problem exists as of OpenWrt SNAPSHOT r8393-dd9da51 (10/30/18). Any ideas why this is happening? I have seen there were some attempts earlier in fixing this but it's still occurring on this device. Thanks!
The text was updated successfully, but these errors were encountered: