MT7612E still firmware crashes on x86_64 laptop #362
Comments
|
Could you please bisect this? |
|
Turns out to be unrelated to recent commits but was just due to the fast connectivity I enjoyed in a specific environment. It reliably occurs when RX goes beyond ~35MBit/s, sitting right next to the AP, then even with disable_ht=1 and disable_vht=1 802.11a 54MBit/s data rates would kill it. It then ends up in a reset-loop (see logs above), even unloading mt76x2e kernel module doesn't help at this point, only reboot does. Probably Linux doesn't control PCI hardware reset but it's done by firmware. |
|
The reset loop should be fixed now, please test |
|
I had similar experience as dangowrt. Now from OpenWrt master 0f8c806eb8 (that includes your fix) the reset loops seem to have turned into series of resets (that stop when data transfer is interrupted); I may have encountered a single reset loop, but I cannot confirm this. |
|
After updating to OpenWrt master fd0cc72d9c (that includes upto and including mt76 master 85c5160) the series of resets seem to have turned into a single reset followed by a kernel panic. Again I connected the STA with another AP (ath9k) at HT40 (Netgear WNDR3800 now running at OpenWrt 19.07.2; ath79). When STA is running iperf as client, transmission is still fine. When STA is running iperf as server, the following kernel messages result. [ 75.652197] mt76x2e 0000:02:00.0: MCU message 31 (seq 11) timed out |
|
After updating to OpenWrt master 4682d4d770 (that includes upto and including mt76 master b22977c) the series of resets seem to have returned; I can even trigger it with (V)HT modes disabled now. It is as if the series of resets get triggered when the incoming data rate exceeds a certain threshold; The outgoing data rate seems to be unaffected; i.e. I now see the same as what dangowrt already described on Feb, 24. Also, the MT7612U seems unaffected, while both chips seem to run the same firmware; e.g. when I let the (x86_64) AP switch from the MT7612E to the MT7612U and let the (x86_32) STA run iperf as client transmission rate is up to ~310 Mbit/s!* It could well be that all this is strictly PCI interface related, like dangowrt already hinted at. Please let me know when there is anything I can do to help solve this. *Although the earlier reported ~190 Mbit/s is a steady flow, this ~310 Mbit/s is not; my working assumption is that the accompanying incoming data rate exceeds the described threshold in this latter case. |
|
I'm also still seeing this with recent mt76 and developed another theory which I will try to pursue once I have measurement tools for that around: mPCIe of laptops build for other WiFi modules might not provide enough power. |
|
In recent versions, resets still happen but the card then in most cases subsequently recovers (at least a bit) and functions again after the reset, just with much lower transfer rates and more frequent repetitions of that reset... |
|
Indeed good to keep options open and yes, I would also not expect RX to draw most power. Three laptops and one mPCIe card would also lead me to suspect the card and not the laptops. If I recall correctly ath10k chips/drivers early on had PCI related quirks. Maybe this case is something similar? I am not aware of what detail can be observed from the kernel side when it comes to the state of the PCI bus. Maybe enough to figure out what is going on?* I am also curious if the only difference between the MT7612E and MT7612U is the host interface. *My background in IC design unfortunately limits me here, as I have not yet been able to find any serious time to spend on low-level Linux stuff and gain sufficient experience. |
Previously wifi was usable in station mode with disable_ht=1 and disable_vht=1 set. Now, after recent commits (i'm on fd892bc), it crashes immediately after connecting once any traffic goes over the link:
Running:
The same hardware works fine with the iwlwifi card which originally shipped with it and also ath9k-based mPCIe modules work flawlessly.
The text was updated successfully, but these errors were encountered: