On 5 January 2017 at 14:23, Felix Fietkau <n...@nbd.name> wrote: > On 2017-01-05 14:22, Loganaden Velvindron wrote: >> On Thu, Jan 5, 2017 at 4:59 PM, Dave Taht <dave.t...@gmail.com> 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 <dave.t...@gmail.com> wrote: >>>> https://github.com/lede-project/source/commit/c296ba834db4ce8c71e0ad7030aab188fe60b27b >>> >>> >> >> 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. 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. 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ł _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
