From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5E9F43B260 for ; Mon, 19 Sep 2016 07:27:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 3EECB40D5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1474284470; bh=FPNI10z5BNTGYK9mVa4LjkZ9DePr5KZ+OwQs7SW/aEw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=rWeOuvxKS8ZmXDF+H+sKKkJi8do9N0lyJprh/wMscRt8I/pPTvHjXoUFaHNQntJEG aK+CgQ99x9gMUNX2CRHl0OH9xSpftH8Thu6CKtL1AnQz0fR9bRbOPg2knQE7O04IBk B6xoxBTtxpjokurZ3vz/0t6aX2jajia3dlGTSLbg= Sender: toke@toke.dk Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id 22B8E85567A; Mon, 19 Sep 2016 13:27:49 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: moeller0 Cc: Loganaden Velvindron , make-wifi-fast@lists.bufferbloat.net References: <87shsyjupm.fsf@toke.dk> Date: Mon, 19 Sep 2016 13:27:49 +0200 In-Reply-To: (moeller0's message of "Mon, 19 Sep 2016 10:33:38 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8760psgmdm.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] crypto-fq bug postmortem is up X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 11:27:52 -0000 moeller0 writes: > Hi Loganaden, hi Toke, > >> On Sep 19, 2016, at 05:56 , Loganaden Velvindron w= rote: >>=20 >> On Mon, Sep 19, 2016 at 12:50 AM, Sebastian Moeller wr= ote: >>>=20 >>> Hi Loganaden, >>>=20 >>> this sounds somewhat familiar to me (see >>> https://bugs.lede-project.org/index.php?do=3Ddetails&task_id=3D176 ). A= t least >>> the symptoms are similar and so is the temporary remedy (calling wifi o= n the >>> CLI). Are you using LEDE firmwares as well? In my case it seems bad rad= io >>> 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 deal= ing >>> with unexpected BlockAck frames') might either have introduced an easie= r way >>> to trigger the offensive conditions, but that is conjecture... >>>=20 >>=20 >> I'm using this firmware: >>=20 >> https://kau.toke.dk/lede/airtime-fairness-builds/ar71xx/generic/lede-r15= 26%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=E2=80=A6 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... -Toke