Re: Asus eeepc 1008HA suspend issue and mac80211 suspend corner case

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

On Wed, Dec 23, 2009 at 10:33:51AM -0800, Luis Rodriguez wrote:
> The issues are as follows:
> 
> 1) We stop TX and flush all packets out, and then call the driver stop().
>    Unfortunately there is a failed assumption that even ieee80211_xmit()
>    would not be called after stopping TX as __ieee80211_suspend() does
>    above.
> 2) Since ieee80211_xmit() is being called even after the driver stop()
>    callback it means mac80211 can potentially schedule work. Now the
>    new rework on the mac80211 workqueue pushes us to WARN when either
>    a driver or mac80211 tried to queue work onto the mac80211 workqueue
>    and we're suspended. A new patch from Johannes futher enhances this
>    to take into consideration resume so that we can allow drivers / mac80211
>    to queue work if we were suspended but now resuming. Even with these
>    checks in place I note that currently we do slip work through after
>    the driver stop() callback is called and before loacl->suspended is
>    set to true. So there seems to be a race here.
> 
> The first issue is not so clear to resolve as although we likely do prevent
> the networking core from calling ieee80211_subif_start_xmit() it doesn't
> mean ieee80211_xmit() internally will not be called by other parts of
> mac80211 and indeed I do believe this is what is happening. I'll try
> pin point the exact spot where this happens though, but I'll note though
> that checking for local->suspended will *not* work since we already know
> some work is being queued *and running!* and it wouldn't have if
> local->suspended was true already.

OK, not bad and pretty obvious too -- the issue is __ieee80211_suspend()
will tear down BA sessions and this does require xmit'ing. The only issue
then becomes that of trying to queue work after a driver stop(), that can
be fixed easily and will send a patch next.

  Luis