[rt2x00-users] rt2x00 workqueue problems

[Ivo Van Doorn]

Hi,

With the recent rt2x00 code (with the queue refactoring) I have a user
which reported some problems which I at first assumed to be unrelated. But
I seem to have found the cause, but I want to discuss the possible solutions.

But first the bugs:
 - Association time with unencrypted or WPA encrypted networks can
   take up to 2 seconds.
 - Latency problems in xterm where keystrokes are recognized with a delay,
   or sometimes ignored altogether.
 - Errors in the log about failed TX queue flush operations

These errors all disappeared by simply deactivating the
flush() callback function from mac80211.

The reason why this removal works is simple, because flush() stalls for a long
time, we get long association times (wpa_supplicant always scans
before associating).
Blocking the kernels threads will also cause the xterm latency problems.

But why is flush() stalling? As I understand it now, is that flush()
is being called
from the mac80211 workqueue. But flush() depends on the mac80211 workqueue
being available for processing the TX and RX status. This was a
similar issue with the
watchdog which I for that specific reason moved to the kernel workqueue. However
if my assumption is correct then the proper assignment must be:

watchdog -> mac80211 workqueue
flush -> mac80211 workqueue
tx/rx status handling -> kernel workqueue

Does anybody have an alternative idea of cause of this problem,
or are there any objections against this reassignment of the workqueues?

Ivo