What's the current state of mt76 driver?

if mt7621+mt7603e+mt7612e stable enough? (with wireless for under 5 device)
It's makeing budget 128/16 router and it looks working. or it's wireless unstable?

please define stable enough.

1 Like

support chip's spec (802.11ac) and driver should not crash or become zombie and make wifi unconnectable.

I think that we passed that milestone a while ago.
Even MT7628 should be usable now, but ac chipsets are stable for a long time now

Maybe someone can give a short status on https://openwrt.org/docs/techref/driver.wlan/mt76

2 Likes

As of 19.07.3, the wifi is still not stable for long-term usage. There are frequent station disconnects, occasional driver crashes and is very sensitive to congested WiFi (>10 APs) environments.
The high-density scenario makes it practically unusable, as it requires multiple restarts per day as devices lose connectivity.

If used in a low-congestion (<4 APs nearby) area, it will run OK for a day or two, before requiring a reboot.

I had high hopes for the MT76 platform, as it is one of the more open ones, and I expected the community would be focused on ensuring it showed off all the good stuff in OpenWRT (of which there is a ton of great work), but flaky wifi will undermine that really quick.

2 Likes

MT76 update commited to ^origin,master
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=479f1f2c92f6b7e75f945cfdb2214b609a92b692

1 Like

When shall we see a stable release for MT76 s?

Unfortunately, still nothing for mt7610
Details - forum, github

1 Like

There were several fixes to common components:

4e6f4e432d0d mt76: only iterate over initialized rx queues

My DIR-860L just hit 101 days of uptime on 19.07.1 with zero WiFi crashes. Super stable and happy with the platform.

Good to hear it is working well for you Mushoz. Would you mind describing your Wifi context?
How many APs visible on a scan, how many directly competing on the same Channel?

Your client density and frequency? Are any of the 'constant chatter' type of IoT?

Are your WiFi settings conservative? (e.g. running 5GHz in N mode)

It seems there are some environmental issues that trigger failures, for instance just lighting up a dozen APs within 50' of the 19.07.3 unit will soon cause 7603 firmware restarts. No need for traffic to those dozen units, just having them lit is enough. That alone makes it unusable in an apartment building.

here is what is in the kernel log when that occurs:

[13583.670457] mtk_soc_eth 1e100000.ethernet eth0: port 3 link down
[37684.500634] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
[37684.500656] mt76x2e 0000:01:00.0: Build: 1
[37684.500664] mt76x2e 0000:01:00.0: Build Time: 201507311614____
[37684.518953] mt76x2e 0000:01:00.0: Firmware running!
[37684.529257] ieee80211 phy1: Hardware restart was requested
[37771.801089] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
[37771.801116] mt76x2e 0000:01:00.0: Build: 1
[37771.801126] mt76x2e 0000:01:00.0: Build Time: 201507311614____
[37771.819053] mt76x2e 0000:01:00.0: Firmware running!
[37771.829102] ieee80211 phy1: Hardware restart was requested
[45727.341495] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
[45727.341518] mt76x2e 0000:01:00.0: Build: 1
[45727.341525] mt76x2e 0000:01:00.0: Build Time: 201507311614____
[45727.359795] mt76x2e 0000:01:00.0: Firmware running!
[45727.369971] ieee80211 phy1: Hardware restart was requested
[45731.461560] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
[45731.461582] mt76x2e 0000:01:00.0: Build: 1
[45731.461590] mt76x2e 0000:01:00.0: Build Time: 201507311614____
[45731.479843] mt76x2e 0000:01:00.0: Firmware running!
[45731.490011] ieee80211 phy1: Hardware restart was requested

There are 7 other 2.4ghz APs visible. No other 5ghz WiFi networks are visible. 5ghz is running AC WiFi.
I have ~11 clients up plus whatever devices any guests might bring. I have two SSIDs on 2.4ghz (Our own WiFi + Guest) and two SSIDs on 5ghz (Our own WiFi + Guest).

I also have a DIR-860L deployed at a friend, where there's 30+ APs visible with no real issues (Range could be better, but stability is good).

Do note that the Dir-860L is running a MT7602E chip for its 2.4ghz WiFi, versus a MT7603 for more recent mt76 devices. 5ghz WiFi should be the same WiFi chip though.

Thanks for the detail, good to hear it works well on that platform.

I would try a master build, but with the change to a new kernel and tons of work in MT76 adding support for new chips, I'm leery of wading into a bunch of new challenges.

Anyone have a suggested set of commits one could patch into a 19.07.3 build?

The one referenced above seems like a very useful one, but some commits depend on prior ones, and my build-fu is close to zero.

  1. Backup your current settings
  2. Flash a master build (WITHOUT keeping settings, very important since the current configs are incompatible with the new DSA driver) and try it out!

Worst case you flash 19.07.3 again and restore the configurations you backed up in step 1).

My anti-vote to mediatek platform. It's a pain in on word.
What I experienced with my TpLink archer c6u :

  1. Windows PC with USB 802.11ac wireless adapter Realtek 8812bu.
    Random loss of connectivity. Packets stop walking in both direction. Rebooting PC does not help.
    Only restart wifi interfaces on the router help for some time

  2. Windows PC with old USB 802.11a wireless adapter D-Link DWA-160
    bad, very unstable connection with long downtimes (from several seconds to minute)

  3. Sometimes broadcasts stop being delivered to AP clients (ARP, NDP) until they send something.
    Unicast is working in this state. Wifi interface restart on the router does not help. Only full reload of mt* kernel modules help. May be this is firmware problem - I don't know

  4. Sometimes mt driver begins 100% using one cpu core without any activity. Attempt to unload kernel module leads to crash.

  5. Drivers are not very well tested in module unload procedures Looks like unload routine sometimes fail to stop all code execution within the module before it exits. => more crashes

  6. mediatek ethernet driver from original linux kernel tree on every link creation (network restart) attempts to allocate contiguous kernel memory block of 1 Mb for DMA buffer. If failed it leads to loss of ethernet connectivity. It can easily fail if memory is fragmented enough on low ram system (<=128 mb)

None of that happened with atheros / ath9k