Re: ath9k becon loss messages

[Kalle Valo]

Kalle Valo <kalle.valo@xxxxxx> writes:

> On Mon, Apr 6, 2009 at 1:51 PM, Helmut Schaa
> <helmut.schaa@xxxxxxxxxxxxxx> wrote:
>
>> Maybe this issue could be
>> avoided by making the beacon loss detection smarter then just checking if no
>> beacon was received within the last two seconds.
>
> Definitely the beacon loss logic should be smarter, but I think that
> should be improved separately. I just have tried to do small changes
> at a time to avoid regressions and I didn't even consider improving
> the beacon loss logic.

I reverted my beacon filter patches but added a similar "beacon loss"
message. With iwl3945 I was able to reproduce the problem even by just
associating to an AP and issuing 'iwlist wlan0 scan':

Apr  6 15:09:31 tikku kernel: [ 3692.544221] beacon loss (reverted version)
Apr  6 15:09:46 tikku kernel: [ 3707.654520] beacon loss (reverted version)
Apr  6 15:09:53 tikku kernel: [ 3714.314057] beacon loss (reverted version)

So the good news is that this is not a new regression, the problem just
appeared because of the new printk I added to my beacon filtering
patches.

I'm suffering from flu right now (damn the finnish weather), but I tried
to investigate this a bit. The problem happens when mac80211 does not
receive anything for two seconds while scanning. For example, at my home
there are only few APs and scanning takes a long time due to 11a support
in iwl3945, so I can reproduce the problem easily.

I'm working on implementing a proper fix, but due to my condition it
might take few days before I'm able to finish it. But in the mean time,
Michael's patch, changing the "beacon loss" messages visible only when
CONFIG_MAC80211_VERBOSE_DEBUG is enabled, is the way to go forward. The
message is useful for developers (eg. we found this bug because of the
message), but it's better that users don't see it. I would like to have
the patch for 2.6.30.

When I'm able to implement the proper fix, I think it should first have
proper testing in wireles-testing before pushing it to mainline. So
maybe the proper fix is 2.6.31 material, just to be on the safe side
here.

John, what do you think?

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/