Re: [Make-wifi-fast] crypto-fq bug postmortem is up

[moeller0 <moeller0@gmx.de>]

Hi Toke,

> On Sep 19, 2016, at 13:27 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> moeller0 <moeller0@gmx.de> writes:
> 
>> Hi Loganaden, hi Toke,
>> 
>>> On Sep 19, 2016, at 05:56 , Loganaden Velvindron <loganaden@gmail.com> wrote:
>>> 
>>> On Mon, Sep 19, 2016 at 12:50 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>>>> 
>>>> Hi Loganaden,
>>>> 
>>>> this sounds somewhat familiar to me (see
>>>> https://bugs.lede-project.org/index.php?do=details&task_id=176 ). At least
>>>> the symptoms are similar and so is the temporary remedy (calling wifi on the
>>>> CLI). Are you using LEDE firmwares as well? In my case it seems bad radio
>>>> conditions help expose the issue somewhat easier... My current idea is that
>>>> r1482 (commit    372d0fea29e60b02154fd7176ba32e7742f6640e, ' ath9k: add a
>>>> bunch of powersave handling fixes') somehow introduced a new or exposed an
>>>> old and hidden bug for the atheros radios, r1483 (commit
>>>> a894a535ff7e6c37bd853e951663130482bc0ff2, 'mac80211: add fixes for dealing
>>>> with unexpected BlockAck frames') might either have introduced an easier way
>>>> to trigger the offensive conditions, but that is conjecture...
>>>> 
>>> 
>>> I'm using this firmware:
>>> 
>>> https://kau.toke.dk/lede/airtime-fairness-builds/ar71xx/generic/lede-r1526%2B2-ar71xx-generic-archer-c7-v2-squashfs-factory.bin
>> 
>> Since this is based on LEDE r1526 it should contain the suspect
>> commits 372d0fea29e60b02154fd7176ba32e7742f6640e and
>> a894a535ff7e6c37bd853e951663130482bc0ff2, so this might be the exact
>> same issue. I seem to be able to force this issue with moving from
>> area of good reception to an area of bad reception (yeah for living in
>> an old house with massive brich walls), maybe that cild work for you
>> as well? I am not sure whether the issue is regarded by the LEDE
>> developers as very critical yet (and rightfully so IMHO, there are
>> only a few reports), so any added report might turn this more into the
>> development spot light…
> 
> The patches you are talking about went in as part of debugging the
> intermediate queueing implementation. Opening an issue on the LEDE bug
> tracker for this might be a good idea…

	I believe/hope I already did: https://bugs.lede-project.org/index.php?do=details&task_id=176 There are other reports of similar failures in the tracker, but I am not fully convinced they all have the exact same root cause. I would not be amazed if the commits I indicated above do not introduce real bugs, but rather expose existing issues by making the conditions to trigger the radio loss more likely. 

Best Regards
	Sebastian


> 
> -Toke