On Tue, 2009-12-22 at 14:30 -0500, Luis R. Rodriguez wrote: > Johannes, any preferences how to handle this? The patch below avoids > the Interrupt being turned off but its not enough given that we still > could be associated according to userspace. If the hardware is > unresponsive maybe it is best to just let the IRQ go disabled, not > sure, but its likely not what happens in all cases. > > Trimming out the irrelevant parts below. > http://bombadil.infradead.org/~mcgrof/logs/2.6.31-with-2.6.32-wireless > /irq-disabled.txt > > > > This can be fixed by something like the following: > > > > diff --git a/net/mac80211/util.c b/net/mac80211/util.c > > index e6c08da..63d42fa 100644 > > --- a/net/mac80211/util.c > > +++ b/net/mac80211/util.c > > @@ -1031,7 +1031,14 @@ int ieee80211_reconfig(struct ieee80211_local > *local) > > > > /* restart hardware */ > > if (local->open_count) { > > + /* > > + * Upon resume hardware can sometimes be goofy due to > > + * various platform issues, so restarting the device may > > + * at times not work immediately. Propagate the error. > > + */ > > res = drv_start(local); > > + if (res) > > + return res; > > > > ieee80211_led_radio(local, true); > > } > > > > But this isn't enough. And since we cannot exactly talk to hardware > > we can't try to send a deassoc as harware would be unresponsive. I > > also don't see us handling such cases before either on cfg80211 or > > mac80211, so curious what we should do. Well it seems to me that if the driver determines that the hardware is unreachable or not responding, it would unregister it from mac80211, which would clean up all user-visible state, obviously. The patch above seems ok to me, but basically papers over the problem. If the start there fails, the driver will have to unregister the hw since any subsequent start will fail as well. The way I see it, it's like a USB unplug while suspended/hibernated ... the driver notices that and remo johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
