From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 89C783BA8D for ; Thu, 5 Jan 2017 09:51:48 -0500 (EST) Received: by mail-qk0-x244.google.com with SMTP id n21so58792634qka.0 for ; Thu, 05 Jan 2017 06:51:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=S4YNdDYTDmzW4qDyBF5fjX3b1WFq7DEyBqXUGtO7bYk=; b=ZeQ7+mkIRG+vyovU5mMaueu3WXxC0GNFJ2QjruNsTIscay6Xu5oVSf+vC7t2IPjCSP REyPeAgh7yGvrrDeYry/RvBg/tcUGG9e4ASlXZ9GcTgc9hMJ+HFAptFk2kVVpGm7wnrJ KaJ2Pe7TfULHTpKdqy8WI7lANEOk/uELjmgfEm7zh2yNx2SRELIXZ96Q3iAe1BkCksuw iFNMXwDPb8xp/ch5jtnMya3mqE6XEzE80MDaN8T6+GO3gkKTG5cv5F2ScPM1s7EnfGoX HKJQFIdjwGa8CP4qsxhU088UReTxtzfl6Mrma6QEDe6OoZkUXxmQDPB4rNdyx7uZw1zD XRlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=S4YNdDYTDmzW4qDyBF5fjX3b1WFq7DEyBqXUGtO7bYk=; b=KWngI9roETGecYoP6JMi1BDxDgFpBPFzoJFoDQ+kEdziBeJ6gO4FPOgxIZTDq2YRFw vBGtKMoeD05Qfli3yQQG0fbaiYk5gqXiPERT17SJ/vzbDvtgWIjCS+6W4ZlGMHDGsGbW gt2B83ni/CYb8TiJmY5O0BJSFQQvnCthC4Nw/3y2sKm+k+847Egw9dSBukDfLsL8/949 LzToBZn70m2hgD0yP/5giPY3uW7IXcedAhUjooA2IOLty69jl6WHFahtPWpnHPfXT+AF lyzhHdQIShP03KygGYqPkFNGPSnMJ0TsPV9CTnQ3GDYxUEF82fR4v486i5yJUur5hMlb ZT2Q== X-Gm-Message-State: AIkVDXI7Bq68eJ0FEWArnO/sxdXabnewjD0lEY04o58b8ujQxsXuKpDUdUrLOgoBhMg9ay7lKC2FDaZewhvCzg== X-Received: by 10.55.162.86 with SMTP id l83mr70251777qke.17.1483627908148; Thu, 05 Jan 2017 06:51:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.152.197 with HTTP; Thu, 5 Jan 2017 06:51:47 -0800 (PST) In-Reply-To: References: <46229222-ccb9-549d-578d-a8f4c9b83de4@nbd.name> From: Dave Taht Date: Thu, 5 Jan 2017 06:51:47 -0800 Message-ID: To: Michal Kazior Cc: Felix Fietkau , Loganaden Velvindron , make-wifi-fast@lists.bufferbloat.net, LEDE Development List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] ath9k airtime fairness stabiity issues? 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: Thu, 05 Jan 2017 14:51:48 -0000 On Thu, Jan 5, 2017 at 6:03 AM, Michal Kazior wro= te: > On 5 January 2017 at 14:23, Felix Fietkau wrote: >> On 2017-01-05 14:22, Loganaden Velvindron wrote: >>> On Thu, Jan 5, 2017 at 4:59 PM, Dave Taht wrote: >>>> Felix: >>>> >>>> Was there a bugreport? (don't see one) >>>> >>>> Do you have a specific device or behavior triggering this revert? >>>> >>>> >>>> On Thu, Jan 5, 2017 at 4:42 AM, Dave Taht wrote: >>>>> https://github.com/lede-project/source/commit/c296ba834db4ce8c71e0ad7= 030aab188fe60b27b >>>> >>>> >>> >>> Hi nbd & Toke, >>> >>> Would it be possible to enable it only on platforms like the tp-link >>> archer c7 v2 and the ubnt, where we have confirmed test reports for >>> the upcoming release ? >> I think it's quite unlikely that these issues are hardware specific. >> It's probably more related to the environment, types of clients, or even >> traffic patterns. > > Some people are complaining ath10k is unstable for them when > wake_tx_queue is enabled. I suspect the ATF problem in ath9k might be > providing extra opportunities to hit the same bug. Hmm. I would assume most ath10k users are on a multi-core? > I think RCU is not properly handled. txq_info shares lifecycle of > sta_info and should therefore be protected in the same manner. When > you queue up ieee80211_txq in a driver and use it later you > effectively break RCU. Grabbing rcu_read_lock() *later*, e.g. when > re-scheduling tx is not sufficient to protect from the possible race > of part1/part2 of station destroying logic and driver accessing its > internal txq list. Sounds like a promising theory. Most of our testing was on single-core devices, with the multi-core x86 version being kernel mainline (4.8ish), and not the lede backport. I long had mildly poor results in terms of throughput on the apu2 (x86 dual core), but assumed it was due to poor antennas. (no crashes) The omnia is a dual core arm, but I don't have one of those. As it turns out the UAP-lite I flashed ~2 days back is crashed right now, and another box was failing to get dhcp addresses (why I was looking at multicast), not even over ethernet. (someone remind me to not take a vacation over the holidays, next time there's holidays) > There seems to be a mechanism to hook up with to fix that already - > drv_sta_pre_rcu_remove(). > > I've been seldom looking at the ath10k problem and noticed this bit. I > didn't get a chance (and probably won't, any time soon) to take a > closer look, nor test/verify it for that matter. > > > Micha=C5=82 --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org