lkml.org 
[lkml]   [2011]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: iwlagn is getting very shaky
From
>> Could something be hogging the workqueues?
>>
>
>
> So I tried to understand what is going on with the workqueue and ended
> up to see that if we are lucky, we can need the workqueue for the BA
> handshake (could be AddBA / DelBA handling, or driver callback) while
> we are scanning. Which basically means that we will need to wait until
> the scan is over to handle these frames / callbacks. I got these
> measurements while stopping the BA session:
>
> * scanning working for roughly 3 seconds (pardon me not being precise,
> but with this order of magnitude I don't care much about the single
> millisecond..)
> * when scanning is over, the while loop in ieee80211_iface_work
> consumes 73 mgmt for about 34ms.
> ( how come we have so many beacons during those 3 seconds..., or maybe
> all the BCAST probe request ?, my network is quite busy...)
> * then the finally my stop_tx_ba_cb was served which took 10ms (time
> takes by the driver).
> * another series of beacons (10ms).

What about flushing the workqueue before we scan ?
This is not a bullet proof solution of course, we will still encounter
bad races, but at least we would flush what we can before the
workqueue becomes unable for 4 seconds (!).
We can also delay the scan if we are in the middle of {add,del}BA
handshake, which is the only flow I can think about that needs
responsiveness. The other frame exchanges are MLME ones and involve
the wpa_supplicant (unless we are using the late WEXT). Hopefully the
wpa_supplicant won't request to scan in the middle of association or
so. There might be other features (mesh or whatever), that may be
hidden from the wpa_supplicant and require good responsiveness from
the wq too.

\
 
 \ /
  Last update: 2011-12-11 20:59    [from the cache]
©2003-2011 Jasper Spaans