Arrived at non-free entry in the non-full queue 0 about mt7630e HOT 14 OPEN

Can you upgrade your kernel and test? kernel 4.1 may be including it's own bug. For example, can you try with kernel 4.2.* or 4.4.0 ?

from mt7630e.

Ok, I don't think it's a kernel problem, but I'll try with a newer kernel (4.4). I'll let you know in the next days. Thank you.

from mt7630e.

I confirm the problem still exists. Seems reload the module (with rmmod and insmod) could fix the problem (I can reconnect to access point again), but too often this operation freeze the entire system.

from mt7630e.

Ok, I confirm that using rmmod and insmod the wifi works again. This is a little script to do automatically this work (assuming it's in the same folder of the driver):
https://gist.github.com/echo-devim/359982f01eb023c1cd2f

but the bug is still there. I'm still thinking about the reason and how to resolve...

from mt7630e.

I edited the rt2x00queue_write_tx_frame function (in rt2x00queue.c) to simply avoid to abort when the problem occurs. Here there is the modified code:
https://gist.github.com/echo-devim/e4118a67f7af38b15ac8
Looking in the dmesg output I can see the driver was automatically reloaded by the kernel (so I didn't need to use the previous script).
Maybe this isn't the right solution but is acceptable for me.. I'll test better to understand if this "solution" works.

from mt7630e.

as expected bypassing so badly the previous problem bring another problem.. infact, now the dmesg is full of these messages (also if the wifi still work)

ieee80211 phy2: rt2x00queue_flush_queue: Warning - Queue 2 failed to flush

from mt7630e.

I found that the previous error isn't related to my change, the "failed to flush" error sometimes happen (I don't know the reason), but the wifi works anyway. At the moment, bypassing the "Arrived at non-free entry in the non-full queue 0" error doesn't seem so bad, because the kernel reloads automatically the module and as final result I lose the wifi connection only for less than 1 second.

from mt7630e.

This seems reasonable enough. Is it tested in kernel 4.4?
If it is, I will test it in 3.13. If no side effect is found I will consider pushing an alpha release. This might actually solve the frequent disconnect problems of so many. I should also note that I can't reproduce these errors on Xubuntu 14.04 on HP ProBook 440 G1. In my case, it always seems to work somehow...

You can do a pull request too if you like. But use the master branch in that case. (default branch is release)

from mt7630e.

Yes, I'm testing with kernel 4.4.0. I'm going to test for other 2-3 days and then if it's all ok I'll do a pull request. Please try to test and let me know the result.

p.s. I don't consider this a "patch" because doesn't resolve the problem, but helps to reduce the bother. If I find a better solution I'll do a new pull request.

from mt7630e.

I don't consider this a "patch"

me, neither. It will be in a separate alpha release for testing purposes, until we get a real solution.

from mt7630e.

Can confirm this is still an issue all the way up to kernel 4.8. Reloading the module works about 10% of the time, in all other cases the system freezes and I need to force reboot. Anyone got any solutions?

from mt7630e.

I want to alert you that also with a wifi network with the 802.1x authentication protocol I've problems of continuosly disconnections (for several seconds).

from mt7630e.

I can confirm that the issue persists with the kernel 4.9.34.

from mt7630e.

I think the last update might have fixed this (version 2.0.8 on kernel 4.10). My connection hasn't dropped in four days, and it used to do it every thirty minutes or so.

Thanks @neurobin!

from mt7630e.