[PATCH 1/2] mac80211: do not iterate active interfaces when in re-configure

From: Ben Greear This appears to fix a problem where ath10k firmware would crash, mac80211 would start re-adding interfaces to the driver, but the iterate-active-interfaces logic would then try to use the half-built interfaces. With a bit of extra debug to catch the

[PATCH 2/2] ath10k: work-around for stale txq in ar->txqs

From: Ben Greear Due to reasons I do not fully understand, when ath10k firmware crashes when trying to bring up lots of vdevs, the ar->txqs may still have references to the txq struct when mac80211 re-adds the network devices. The device add logic was re-initializing

Re: [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.

On 12/01/2016 02:52 PM, Ben Greear wrote: On 08/19/2016 06:34 AM, Ben Greear wrote: On 08/18/2016 11:59 PM, Michal Kazior wrote: On 19 August 2016 at 03:26, wrote: From: Ben Greear I was seeing kernel crashes due to accessing freed

Re: [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.

On 08/19/2016 06:34 AM, Ben Greear wrote: On 08/18/2016 11:59 PM, Michal Kazior wrote: On 19 August 2016 at 03:26, wrote: From: Ben Greear I was seeing kernel crashes due to accessing freed memory while debugging a 9984 firmware that was

Re: Client station sends probes on DFS channels

Hi, So to be clear: * if you get a CSA, the STA should move and not use the air * if you just start another AP And then kill the APs, there's nothing above that says when the STA should stop talking? Thanks, -adrian ___ ath10k mailing list

Re: ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONAL.

Ben Greear wrote: > From: Ben Greear > > These memory chunks are often used as 'swap' by the NIC, > so it will be both reading and writing to these areas. > > This seems to fix errors like this on my x86-64 machine: > > kernel: DMAR: DMAR:[DMA

Re: ath10k: Fix Tx DMA alloc failure during continuous wifi down/up

Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > With maximum number of vap's configured in a two radio supported > systems of ~256 Mb RAM, doing a continuous wifi down/up and > intermittent traffic streaming from the

Re: [v2] ath10k: Fix soft lockup during firmware crash/hw-restart

Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > During firmware crash (or) user requested manual restart > the system gets into a soft lock up state because of the > below root cause. > > During user requested hardware

Re: [PATCH v2] ath10k: Fix soft lockup during firmware crash/hw-restart

On Thu, Dec 01, 2016 at 10:35:38AM +, Valo, Kalle wrote: > Mohammed Shafi Shajakhan writes: > > > From: Mohammed Shafi Shajakhan > > > > During firmware crash (or) user requested manual restart > > the system gets into a soft lock up

Re: ath10k: fix TLV set regdomain command

Erik Stromdahl wrote: > There is a typo bug in the current implementation of > ath10k_wmi_tlv_op_gen_pdev_set_rd. > The conformance test limits are not set up properly. > > The two arguments ctl2g and ctl5g were not used at all. > Instead, the regdomain arguments rd2g

Re: ath10k: Fix soft lockup during firmware crash/hw-restart

Mohammed Shafi Shajakhan writes: > On Tue, Nov 29, 2016 at 10:16:50AM -0800, Ben Greear wrote: >> Is this something for stable? And if so, how far back should it be applied? > > @Kalle, > > [shafi] kindly suggest. If i am not wrong this is only needed for 4.9 Correct,

Re: [PATCH v2] ath10k: Fix soft lockup during firmware crash/hw-restart

Mohammed Shafi Shajakhan writes: > From: Mohammed Shafi Shajakhan > > During firmware crash (or) user requested manual restart > the system gets into a soft lock up state because of the > below root cause. > > During user requested hardware

RE: Client station sends probes on DFS channels

Hi Adrian, > What's the etsi spec say about once a station hears beacons? What ETSI EN301893 v1.8.1 [1] says is: 1) ETSI distinguishes "master" devices and "slave" devices (section 4.7.1.3) 2) "Slaves shall only operate in a network controlled by (...) a master" (section 4.7.1.3) 3) "A