mac80211 suspend gotchas

mac80211 suspend gotchas

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 3325 bytes --]

Hi driver authors :)

I suggest you guys get together and write some proper suspend support
for mac80211. We can discuss in Ottawa, but I just wanted to let you
know that I just ran into this:

[...]
[55292.062873] adb: starting probe task...
[55292.063012] adb: finished probe task...
[55292.502871] wlan0: No ProbeResp from current AP 00:1a:2a:2c:a2:c5 - assume out of range
[55292.502883] phy2: Removed STA 00:1a:2a:2c:a2:c5
[55292.562874] mac80211-phy2: failed to remove key (0, 00:1a:2a:2c:a2:c5) from hardware (-19)
[55292.563229] phy2: Destroyed STA 00:1a:2a:2c:a2:c5
[55292.768591] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[55292.776295] hda: UDMA/100 mode selected
[55292.777058] ide-cdrom 1.0: resuming
[55292.779026] hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[55292.779210] hdc: MWDMA2 mode selected
[55292.779533] therm_adt746x 8-002e: resuming
[55292.779548] b43 ssb0:0: resuming
[55292.779552] b43-phy2 debug: Resuming...
[...]

As you can see, mac80211 "noticed" that the AP was "out of range",
probably because it sent a probe request just before or during
suspending and the time till now was about an hour.

We _really_ need to tie mac80211's workqueues and everything to the
hardware so we don't try to do these things before the driver resumes.

As you can see, mac80211 also complained that the key couldn't be
removed; that is because b43 didn't like being called when the hardware
was still shut down.

I don't even know if b43 keeps hardware keys across suspend (if not that
might explain some of the wpa problems I had with suspend) but it
shouldn't have to. In fact, I think it shouldn't even have to keep the
MAC address setting (it does that now.)

This is not a hard problem to solve.

What needs to be done is:
 - extend the ieee80211_notify_mac callback with two new paramters:
   suspend and resume
 - suspend is called by drivers when suspending _before_ taking any
   driver-specific locks, allowing mac80211 to call all callbacks as a
   response to that
 - resume is called by drivers when resuming _after_ having resumed the
   hardware
 - suspend does, in this order (callback used):
    * stop aggregation (ampdu_action)
    * remove all keys (set_key)
    * remove all STAs (sta_notify)
    * remove all interfaces (remove_interface)
    * stop the hardware (stop)
 - resume does the opposite in opposite order, and additionally
    * updates TKIP phase 1 keys (?)
    * re-sets RTS/frag threshold, retry limits
    * re-configures hardware (config)
    * re-configures TX parameters (conf_tx)
    * re-configures filters (configure_filter)
    * [probably more that I missed on first sight]

All the values should be there in software state inside mac80211 anyway,
so doing it shouldn't need a significant amount of new state, though one
may have to add something depending on the up/down state of interfaces
to the sdata struct.

It's not _extremely_ complicated, but testing it all and getting it
right is a significant effort. TBH, I'm not bored enough right now to
spend a significant amount of time on it; I know how to recover should
anything go wrong (b43 is a very good driver in that respect, it handles
all those stupid cases that shouldn't happen.)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: mac80211 suspend gotchas

[Michael Buesch]

On Friday 20 June 2008 14:46:58 Johannes Berg wrote:
> Hi driver authors :)
>=20
> I suggest you guys get together and write some proper suspend support
> for mac80211. We can discuss in Ottawa, but I just wanted to let you
> know that I just ran into this:
>=20
> [...]
> [55292.062873] adb: starting probe task...
> [55292.063012] adb: finished probe task...
> [55292.502871] wlan0: No ProbeResp from current AP 00:1a:2a:2c:a2:c5 =
- assume out of range
> =EF=BB=BF[55292.502883] phy2: Removed STA 00:1a:2a:2c:a2:c5
> [55292.562874] mac80211-phy2: failed to remove key (0, 00:1a:2a:2c:a2=
:c5) from hardware (-19)
> [55292.563229] phy2: Destroyed STA 00:1a:2a:2c:a2:c5
> [55292.768591] hda: host max PIO4 wanted PIO255(auto-tune) selected P=
IO4
> [55292.776295] hda: UDMA/100 mode selected
> [55292.777058] ide-cdrom 1.0: resuming
> [55292.779026] hdc: host max PIO4 wanted PIO255(auto-tune) selected P=
IO4
> [55292.779210] hdc: MWDMA2 mode selected
> [55292.779533] therm_adt746x 8-002e: resuming
> [55292.779548] b43 ssb0:0: resuming
> [55292.779552] b43-phy2 debug: Resuming...
> [...]
>=20
> As you can see, mac80211 "noticed" that the AP was "out of range",
> probably because it sent a probe request just before or during
> suspending and the time till now was about an hour.
>=20
> We _really_ need to tie mac80211's workqueues and everything to the
> hardware so we don't try to do these things before the driver resumes=
=2E

Yeah I agree.

However, currently wpa_supplicant will notice the connection loss right
after resume and scan for APs and connect, for me.

> I don't even know if b43 keeps hardware keys across suspend

It doesn't.

> This is not a hard problem to solve.

>  - suspend does, in this order (callback used):
>     * stop aggregation (ampdu_action)
>     * remove all keys (set_key)
>     * remove all STAs (sta_notify)
>     * remove all interfaces (remove_interface)
>     * stop the hardware (stop)

I think the hardware-stop should probably be done in the driver
suspend routine after the mac80211 notification and not by a mac80211 c=
allback.
Otherwise this is going to get complicated wrt locking.

--=20
Greetings Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211 suspend gotchas

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]


> > This is not a hard problem to solve.
> 
> >  - suspend does, in this order (callback used):
> >     * stop aggregation (ampdu_action)
> >     * remove all keys (set_key)
> >     * remove all STAs (sta_notify)
> >     * remove all interfaces (remove_interface)
> >     * stop the hardware (stop)
> 
> I think the hardware-stop should probably be done in the driver
> suspend routine after the mac80211 notification and not by a mac80211 callback.
> Otherwise this is going to get complicated wrt locking.

All of those callbacks potentially require locks, you really want to
call them outside of any locked section in your ->resume and ->suspend
handlers.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: mac80211 suspend gotchas

[Michael Buesch]

On Friday 20 June 2008 15:31:13 Johannes Berg wrote:
> 
> > > This is not a hard problem to solve.
> > 
> > >  - suspend does, in this order (callback used):
> > >     * stop aggregation (ampdu_action)
> > >     * remove all keys (set_key)
> > >     * remove all STAs (sta_notify)
> > >     * remove all interfaces (remove_interface)
> > >     * stop the hardware (stop)
> > 
> > I think the hardware-stop should probably be done in the driver
> > suspend routine after the mac80211 notification and not by a mac80211 callback.
> > Otherwise this is going to get complicated wrt locking.
> 
> All of those callbacks potentially require locks, you really want to
> call them outside of any locked section in your ->resume and ->suspend
> handlers.

ops->stop is special wrt suspend.

-- 
Greetings Michael.