Arrived at non-free entry in the non-full queue 0

[echo-devim]

The wifi works well, but after a random time (like some hours) it disconnects and trying to reconnect continuously. Looking into the dmesg output I found this:

ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 0

I'm using Manjaro linux with the kernel 4.1.15-2 and the latest version of this driver

[neurobin]

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 ?

[echo-devim]

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.

[echo-devim]

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.

[echo-devim]

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...

[echo-devim]

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.

[echo-devim]

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

[echo-devim]

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.

[neurobin]

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)

[echo-devim]

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.

[neurobin]

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.

[EddieLink]

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?

[echo-devim]

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).

[renatgalimov]

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

[EddieLink]

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!