On Wed, Feb 17, 2016 at 1:23 AM, Krishna Chaitanya
wrote:
> From a quick glance of symptoms, i think the below patch is worth a
> try, even though
> i don't see you are doing any background scans for which this applies.
>
> https://patchwork.kernel.org/patch/8015321/
On Wed, Feb 17, 2016 at 10:02 AM, Avery Pennarun wrote:
>
> On Tue, Feb 16, 2016 at 5:05 PM, Johannes Berg
> wrote:
> > On Tue, 2016-02-16 at 16:28 -0500, Avery Pennarun wrote:
> >> Changing default_agg_timeout to zero (as it is on most non-ath9k
>
On Tue, Feb 16, 2016 at 5:05 PM, Johannes Berg
wrote:
> On Tue, 2016-02-16 at 16:28 -0500, Avery Pennarun wrote:
>> Changing default_agg_timeout to zero (as it is on most non-ath9k
>> drivers) makes the problem pretty much go away. However, I think
>> it's because I'm
On Tue, 2016-02-16 at 16:28 -0500, Avery Pennarun wrote:
>
> Changing default_agg_timeout to zero (as it is on most non-ath9k
> drivers) makes the problem pretty much go away. However, I think
> it's because I'm just dodging the code path that triggers a race
> condition.
That does seem likely.
Okay, I've made much more progress on this old thread. I haven't actually
fixed the bug, which I suspect is a race condition only on multicore
machines, but I at least have better reproduction steps and a workaround.
The bug seems to trigger when three things happen at once:
1) Background
[fixed ath9k list address. sorry for the spam]
Hi all,
I have a pretty weird problem I've been chasing for a few weeks and
have narrowed it down, but not quite solved it. It may be caused by
bugs in aggregation-related code.
Steps:
- Set up an ath9k-based Linux AP on an ARM processor
Hi all,
I have a pretty weird problem I've been chasing for a few weeks and
have narrowed it down, but not quite solved it. It may be caused by
bugs in aggregation-related code.
Steps:
- Set up an ath9k-based Linux AP on an ARM processor (currently using
this version of backports, though I've