From michal.kazior at tieto.com  Tue Apr  1 01:32:46 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 1 Apr 2014 07:32:46 +0200
Subject: ath10k: ieee80211_restart_work called with hardware scan in
 progress
In-Reply-To: <53399E42.2090504@candelatech.com>
References: <53399E42.2090504@candelatech.com>
Message-ID: <CA+BoTQmfBGJxwFnpq+7dE7MgL_db5gkCvRVfhk9YFAAPLZQwHQ@mail.gmail.com>

On 31 March 2014 18:56, Ben Greear <greearb at candelatech.com> wrote:
> This came from a customer (demo) system.  Firmware is 10.1.389 based, modified
> by us.  It has lots of known issues, but I haven't seen the warning
> below before, and not sure it is specifically a bug with ath10k or not.

Hmm..


> Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108)
> Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108)
> Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108)
> Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108)
> Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108)
> Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108)

-108 = ESHUTDOWN. This can be a result of calling ath10k_halt() IOW
driver is stopping by mac80211 request or ath10k_core_restart() was
called. I suppose the latter is the case here.

ath10k_halt() calls ieee80211_scan_completed(hw, true) if necessary.
But since it only sets 1 or 2 bits in local->scanning in mac80211 and
schedules local->scan_work I suspect you can end up having
local->restart_work scheduled sooner in some cases (both use different
workqueues: scan_work uses per-hw queue, restart_work uses global
system queue) and see the following:

> Mar 31 13:49:54 ct521-5332 kernel: ieee80211_restart_work called with hardware scan in progress
> Mar 31 13:49:54 ct521-5332 kernel: Modules linked in: nf_nat_ipv4 nf_nat fuse 8021q mrp garp stp llc macvlan pktgen coretemp hwmon sunrpc ipv6 uinput
> snd_hda_codec_realtek snd_hda_codec_generic ath10k_pci ath10k_core snd_hda_intel mac80211 snd_hda_codec snd_hwdep snd_seq snd_seq_device iTCO_wdt e1000e
> microcode ath gpio_ich snd_pcm iTCO_vendor_support ppdev ptp snd_timer parport_pc snd cfg80211 parport serio_raw pps_core soundcore pcspkr i2c_i801 lpc_ich i915
> drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: iptable_nat]
> Mar 31 13:49:54 ct521-5332 kernel: CPU: 0 PID: 11818 Comm: kworker/0:0 Tainted: G        WC   3.14.0-rc7-wl-ath+ #4
> Mar 31 13:49:54 ct521-5332 kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M., BIOS 4.6.3 09/05/2011
> Mar 31 13:49:54 ct521-5332 kernel: Workqueue: events ieee80211_restart_work [mac80211]
> Mar 31 13:49:54 ct521-5332 kernel: 0000000000000009 ffff8800bd865d68 ffffffff815ab0a5 ffff88022bc0ec38
> Mar 31 13:49:54 ct521-5332 kernel: ffff8800bd865db8 ffff8800bd865da8 ffffffff810c1aa8 ffff8800bd865d88
> Mar 31 13:49:54 ct521-5332 kernel: ffffffffa03858ce ffff8802214d5650 ffff8802214d45e0 ffff8802214d5650
> Mar 31 13:49:54 ct521-5332 kernel: Call Trace:
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff815ab0a5>] dump_stack+0x4e/0x71
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810c1aa8>] warn_slowpath_common+0x77/0x91
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffffa03858ce>] ? ieee80211_restart_work+0x49/0x68 [mac80211]
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810c1b56>] warn_slowpath_fmt+0x41/0x43
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffffa03858ce>] ieee80211_restart_work+0x49/0x68 [mac80211]
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810d52af>] process_one_work+0x162/0x216
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810d5724>] worker_thread+0x12f/0x1fd
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810d55f5>] ? rescuer_thread+0x268/0x268
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810d55f5>] ? rescuer_thread+0x268/0x268
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810da37f>] kthread+0xa0/0xa8
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810da2df>] ? __kthread_parkme+0x5c/0x5c
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff815b5b4c>] ret_from_fork+0x7c/0xb0
> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810da2df>] ? __kthread_parkme+0x5c/0x5c
> Mar 31 13:49:54 ct521-5332 kernel: ---[ end trace fd8ccdaa79168e68 ]---

It seems to me that any mac80211-driver can hit this as long as it
requests a restart during a scan while something queued via
ieee80211_queue_work() blocks (that something could be driver worker)
long enough.


Micha?


From michal.kazior at tieto.com  Tue Apr  1 01:44:22 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 1 Apr 2014 07:44:22 +0200
Subject: More on ath10k_flush.
In-Reply-To: <533A0729.4030907@candelatech.com>
References: <533A0729.4030907@candelatech.com>
Message-ID: <CA+BoTQm8YEaz7B0jF1GDQrfczEA3tToJPTMx0oS-oZpH25Rkrw@mail.gmail.com>

On 1 April 2014 02:24, Ben Greear <greearb at candelatech.com> wrote:
> So, I tried adding lots of debug to the ath10k_flush,
> and I think I might have found the issue.
>
> My test case is:  create 32 stations, start TCP on all of them,
> then reset (effectively ifdown;ifup) the station vifs.
>
> I get lots of spews because the ath10k_flush call thinks it is
> hanging.  But, based on the debug, I think the problem is that
> the tx logic is continuing to accept packets while the flush
> is trying to happen.
>
> If my debugging stats are correct, the NIC managed to send around 4000
> frames during the flush attempt, and the ath10k driver processed lots of
> tx completions as well.  But there are still lots of pkts
> pending tx and the tx queue was never empty.
>
> ath10k: failed to flush transmit queue (skip 0 ar-state 1 pending_tx 1009  pre-pending-tx: 1045): 0
> ath10k: pre: htc-send-tot: 3423  htt-tx 2545397  tx-compl 2544355  mgt-tx 0  mgt-compl 0
> ath10k: post: htc-send-tot: 3424  htt-tx 2630981  tx-compl 2630156  mgt-tx 0  mgt-compl 0
> ath10k: pre: hw-queued: 124395  hw-reaped: 124394
> ath10k: post: hw-queued: 128418  hw-reaped: 128417

What do these prints reflect exactly? What base upstream ath10k commit
are you on?


> Do we need to somehow shut down all tx logic during the ath10k_flush
> so that (other?) stations cannot transmit?

This seems strange. drv_flush() is called with all tx queues being
stopped in mac80211 with IEEE80211_QUEUE_STOP_REASON_FLUSH. I guess
you can still receive a few frames (due to SMP with many interfaces),
but that's it (at most num_cpus-1 I guess). You shouldn't be seeing
4000 frames being queued while you flush.


Micha?


From michal.kazior at tieto.com  Tue Apr  1 03:25:23 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue,  1 Apr 2014 09:25:23 +0200
Subject: [PATCH] ath10k: fix initial radar detection logic
In-Reply-To: <1396015934-7723-1-git-send-email-michal.kazior@tieto.com>
References: <1396015934-7723-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>

This fixes a problem of initial radar detection
(CAC) being stuck and blocking Rx in some cases
until all interfaces were brought down.

For userspace this meant first run of hostapd
would perform CAC but due to filtered Rx no
clients would associate. Subsequent runs of
hostapd would not perform CAC (as it was already
done) and would associate clients.

This also makes sure radar detection is performed
when bandwidth is widened. Before if 20MHz CAC was
performed then 40MHz CAC wouldn't start monitor
vdev effectively disabling initial radar
detection.

A driver should just start/stop radar detection
based on hw->conf.radar_enabled. However, since
ath10k needs to start a monitor vdev for the
initial radar detection special care needs to be
applied.

While at it cleanup the code a bit.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.h |  2 ++
 drivers/net/wireless/ath/ath10k/mac.c  | 56 ++++++++++++----------------------
 2 files changed, 21 insertions(+), 37 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 8edd6da..ca2abe2 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -434,6 +434,8 @@ struct ath10k {
 	unsigned int filter_flags;
 	unsigned long dev_flags;
 	u32 dfs_block_radar_events;
+	bool radar_enabled; /* protected by conf_mutex */
+	int num_started_vdevs; /* protected by conf_mutex */
 
 	struct wmi_pdev_set_wmm_params_arg wmm_params;
 	struct completion install_key_done;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 58ec5a7..024fce4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -489,6 +489,8 @@ static inline int ath10k_vdev_setup_sync(struct ath10k *ar)
 	return 0;
 }
 
+static void ath10k_recalc_radar_detection(struct ath10k *ar);
+
 static int ath10k_vdev_start(struct ath10k_vif *arvif)
 {
 	struct ath10k *ar = arvif->ar;
@@ -545,6 +547,9 @@ static int ath10k_vdev_start(struct ath10k_vif *arvif)
 		return ret;
 	}
 
+	ar->num_started_vdevs++;
+	ath10k_recalc_radar_detection(ar);
+
 	return ret;
 }
 
@@ -571,6 +576,11 @@ static int ath10k_vdev_stop(struct ath10k_vif *arvif)
 		return ret;
 	}
 
+	if (WARN_ON(ar->num_started_vdevs == 0)) {
+		ar->num_started_vdevs--;
+		ath10k_recalc_radar_detection(ar);
+	}
+
 	return ret;
 }
 
@@ -804,49 +814,18 @@ static int ath10k_stop_cac(struct ath10k *ar)
 	return 0;
 }
 
-static const char *ath10k_dfs_state(enum nl80211_dfs_state dfs_state)
-{
-	switch (dfs_state) {
-	case NL80211_DFS_USABLE:
-		return "USABLE";
-	case NL80211_DFS_UNAVAILABLE:
-		return "UNAVAILABLE";
-	case NL80211_DFS_AVAILABLE:
-		return "AVAILABLE";
-	default:
-		WARN_ON(1);
-		return "bug";
-	}
-}
-
-static void ath10k_config_radar_detection(struct ath10k *ar)
+static void ath10k_recalc_radar_detection(struct ath10k *ar)
 {
-	struct ieee80211_channel *chan = ar->hw->conf.chandef.chan;
-	bool radar = ar->hw->conf.radar_enabled;
-	bool chan_radar = !!(chan->flags & IEEE80211_CHAN_RADAR);
-	enum nl80211_dfs_state dfs_state = chan->dfs_state;
 	int ret;
 
 	lockdep_assert_held(&ar->conf_mutex);
 
-	ath10k_dbg(ATH10K_DBG_MAC,
-		   "mac radar config update: chan %dMHz radar %d chan radar %d chan state %s\n",
-		   chan->center_freq, radar, chan_radar,
-		   ath10k_dfs_state(dfs_state));
-
-	/*
-	 * It's safe to call it even if CAC is not started.
-	 * This call here guarantees changing channel, etc. will stop CAC.
-	 */
 	ath10k_stop_cac(ar);
 
-	if (!radar)
-		return;
-
-	if (!chan_radar)
+	if (!ar->radar_enabled)
 		return;
 
-	if (dfs_state != NL80211_DFS_USABLE)
+	if (ar->num_started_vdevs > 0)
 		return;
 
 	ret = ath10k_start_cac(ar);
@@ -2341,6 +2320,7 @@ static int ath10k_start(struct ieee80211_hw *hw)
 		goto exit;
 	}
 
+	ar->num_started_vdevs = 0;
 	ath10k_regd_update(ar);
 	ret = 0;
 
@@ -2490,15 +2470,17 @@ static int ath10k_config(struct ieee80211_hw *hw, u32 changed)
 
 	if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
 		ath10k_dbg(ATH10K_DBG_MAC,
-			   "mac config channel %d mhz flags 0x%x\n",
+			   "mac config channel %dMHz flags 0x%x radar %d\n",
 			   conf->chandef.chan->center_freq,
-			   conf->chandef.chan->flags);
+			   conf->chandef.chan->flags,
+			   conf->radar_enabled);
 
 		spin_lock_bh(&ar->data_lock);
 		ar->rx_channel = conf->chandef.chan;
 		spin_unlock_bh(&ar->data_lock);
 
-		ath10k_config_radar_detection(ar);
+		ar->radar_enabled = conf->radar_enabled;
+		ath10k_recalc_radar_detection(ar);
 
 		if (!cfg80211_chandef_identical(&ar->chandef, &conf->chandef)) {
 			ar->chandef = conf->chandef;
-- 
1.8.5.3



From kvalo at qca.qualcomm.com  Tue Apr  1 03:42:10 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 1 Apr 2014 10:42:10 +0300
Subject: Clean-ish rebase on top of 3.14.0 (final)?
In-Reply-To: <53399703.1060302@candelatech.com> (Ben Greear's message of "Mon, 
 31 Mar 2014 09:25:39 -0700")
References: <53399703.1060302@candelatech.com>
Message-ID: <87ioqtsdgt.fsf@kamboji.qca.qualcomm.com>

Ben Greear <greearb at candelatech.com> writes:

> Kalle:  In case you end up with your tree in a clean rebase
> on stock 3.14.0 (or as clean as is reasonable), could you let
> us know and give us a bit of time before pulling down more
> upstream stuff?
>
> The reason is that I would like to freeze a 3.14 kernel with whatever
>ath10k patches are currently in your tree and attempt to stabalize
>it...

Do you mean 3.14 plus only ath10k patches? Or are you willing to take
other wireless patches as well?

Basically I have two branches in my ath.git:

o ath-next: wireless-next + latest ath10k patches

o master: wireless-testing + ath-next (= latest ath10k patches)

I only merge latest wireless-next to ath-next seldomly, usually once
every 1-2 months. But I merge wireless-testing to master branch at least
weekly.

One idea would be that you merge 3.14 tag with ath-next. That way you
get latest wireless code on top of 3.14. Would that work?

I'm planning to merge wireless-next to ath-next once John opens his
trees again, which usually happens just after the merge window is
closed.

-- 
Kalle Valo


From janusz.dziedzic at tieto.com  Tue Apr  1 04:23:48 2014
From: janusz.dziedzic at tieto.com (Janusz Dziedzic)
Date: Tue,  1 Apr 2014 10:23:48 +0200
Subject: [PATCH] ath10k: remove not needed warning when peer unmap
Message-ID: <1396340628-4570-1-git-send-email-janusz.dziedzic@tieto.com>

Remove not needed warning when get peer unmap
event from the firmware. This is not critical
message. Instead print this as a debug message.

Signed-off-by: Janusz Dziedzic <janusz.dziedzic at tieto.com>
---
 drivers/net/wireless/ath/ath10k/txrx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/txrx.c b/drivers/net/wireless/ath/ath10k/txrx.c
index 82669a7..b7f4acc 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -200,7 +200,7 @@ void ath10k_peer_unmap_event(struct ath10k_htt *htt,
 	spin_lock_bh(&ar->data_lock);
 	peer = ath10k_peer_find_by_id(ar, ev->peer_id);
 	if (!peer) {
-		ath10k_warn("peer-unmap-event: unknown peer id %d\n",
+		ath10k_dbg(ATH10K_DBG_HTT, "peer-unmap-event: unknown peer id %d\n",
 			    ev->peer_id);
 		goto exit;
 	}
-- 
1.7.9.5



From greearb at candelatech.com  Tue Apr  1 09:12:00 2014
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 01 Apr 2014 06:12:00 -0700
Subject: More on ath10k_flush.
In-Reply-To: <CA+BoTQm8YEaz7B0jF1GDQrfczEA3tToJPTMx0oS-oZpH25Rkrw@mail.gmail.com>
References: <533A0729.4030907@candelatech.com>
 <CA+BoTQm8YEaz7B0jF1GDQrfczEA3tToJPTMx0oS-oZpH25Rkrw@mail.gmail.com>
Message-ID: <533ABB20.3000407@candelatech.com>

On 03/31/2014 10:44 PM, Michal Kazior wrote:
> On 1 April 2014 02:24, Ben Greear <greearb at candelatech.com> wrote:
>> So, I tried adding lots of debug to the ath10k_flush,
>> and I think I might have found the issue.
>>
>> My test case is:  create 32 stations, start TCP on all of them,
>> then reset (effectively ifdown;ifup) the station vifs.
>>
>> I get lots of spews because the ath10k_flush call thinks it is
>> hanging.  But, based on the debug, I think the problem is that
>> the tx logic is continuing to accept packets while the flush
>> is trying to happen.
>>
>> If my debugging stats are correct, the NIC managed to send around 4000
>> frames during the flush attempt, and the ath10k driver processed lots of
>> tx completions as well.  But there are still lots of pkts
>> pending tx and the tx queue was never empty.
>>
>> ath10k: failed to flush transmit queue (skip 0 ar-state 1 pending_tx 1009  pre-pending-tx: 1045): 0
>> ath10k: pre: htc-send-tot: 3423  htt-tx 2545397  tx-compl 2544355  mgt-tx 0  mgt-compl 0
>> ath10k: post: htc-send-tot: 3424  htt-tx 2630981  tx-compl 2630156  mgt-tx 0  mgt-compl 0
>> ath10k: pre: hw-queued: 124395  hw-reaped: 124394
>> ath10k: post: hw-queued: 128418  hw-reaped: 128417
>
> What do these prints reflect exactly? What base upstream ath10k commit
> are you on?
>
>
>> Do we need to somehow shut down all tx logic during the ath10k_flush
>> so that (other?) stations cannot transmit?
>
> This seems strange. drv_flush() is called with all tx queues being
> stopped in mac80211 with IEEE80211_QUEUE_STOP_REASON_FLUSH. I guess
> you can still receive a few frames (due to SMP with many interfaces),
> but that's it (at most num_cpus-1 I guess). You shouldn't be seeing
> 4000 frames being queued while you flush.

Subsequent debugging makes me think the extra packets are not coming
from the upper stack.  Possibly there are ath10k<->firmware management messages
being queued or something like that?

I'm out of office today, will post the debug patch when I get a chance.

Thanks,
Ben

>
>
> Micha?
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Tue Apr  1 13:55:40 2014
From: greearb at candelatech.com (greearb at candelatech.com)
Date: Tue,  1 Apr 2014 10:55:40 -0700
Subject: [PATCH 1/1] ath10k:  add helper method to grab debug stats.
Message-ID: <1396374940-21453-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb at candelatech.com>

It can be nice to update the firmware's stats while
debugging other bits of the driver, so add helper method
to do this.

Signed-off-by: Ben Greear <greearb at candelatech.com>
---
 drivers/net/wireless/ath/ath10k/debug.c | 26 +++++++++++++++++---------
 drivers/net/wireless/ath/ath10k/debug.h |  2 ++
 2 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index f562ac5..5813286 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -283,6 +283,21 @@ void ath10k_debug_read_target_stats(struct ath10k *ar,
 	complete(&ar->debug.event_stats_compl);
 }
 
+int ath10k_refresh_peer_stats(struct ath10k *ar)
+{
+	int ret = ath10k_wmi_request_stats(ar, WMI_REQUEST_PEER_STAT);
+	if (ret) {
+		ath10k_warn("could not request stats (%d)\n", ret);
+		return ret;
+	}
+
+	ret = wait_for_completion_timeout(&ar->debug.event_stats_compl, 1*HZ);
+	if (ret <= 0)
+		return ret;
+
+	return 0;
+}
+
 static ssize_t ath10k_read_fw_stats(struct file *file, char __user *user_buf,
 				    size_t count, loff_t *ppos)
 {
@@ -291,7 +306,6 @@ static ssize_t ath10k_read_fw_stats(struct file *file, char __user *user_buf,
 	char *buf = NULL;
 	unsigned int len = 0, buf_len = 8000;
 	ssize_t ret_cnt = 0;
-	long left;
 	int i;
 	int ret;
 
@@ -306,14 +320,8 @@ static ssize_t ath10k_read_fw_stats(struct file *file, char __user *user_buf,
 	if (!buf)
 		goto exit;
 
-	ret = ath10k_wmi_request_stats(ar, WMI_REQUEST_PEER_STAT);
-	if (ret) {
-		ath10k_warn("could not request stats (%d)\n", ret);
-		goto exit;
-	}
-
-	left = wait_for_completion_timeout(&ar->debug.event_stats_compl, 1*HZ);
-	if (left <= 0)
+	ret = ath10k_refresh_peer_stats(ar);
+	if (ret)
 		goto exit;
 
 	spin_lock_bh(&ar->data_lock);
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 12573fa..e5d1391 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -135,4 +135,6 @@ struct dbglog_hdr_s {
 
 void ath10k_dbg_print_fw_dbg_buffer(u8 *buffer, int len, const char* lvl);
 
+int ath10k_refresh_peer_stats(struct ath10k *ar);
+
 #endif /* _DEBUG_H_ */
-- 
1.7.11.7



From greearb at candelatech.com  Tue Apr  1 13:56:58 2014
From: greearb at candelatech.com (greearb at candelatech.com)
Date: Tue,  1 Apr 2014 10:56:58 -0700
Subject: [RFC 1/1] ath10k:  reset firmware if tx-flush hangs.
Message-ID: <1396375018-21671-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb at candelatech.com>

Seems to be no other way to recover this error.

Print out some before and after counters for both the
driver and for the firmware.  If we time-out two flushes
in a row, and are not currently restarting, then restart
the NIC.

Plz do not apply this...I think the firmware is not always
to blame..need to figure out why...but this has some decent
debugging code to help track it down...

Signed-off-by: Ben Greear <greearb at candelatech.com>
---
 drivers/net/wireless/ath/ath10k/core.h   |  8 ++++
 drivers/net/wireless/ath/ath10k/htc.c    |  2 +
 drivers/net/wireless/ath/ath10k/htt.c    |  4 ++
 drivers/net/wireless/ath/ath10k/htt_rx.c |  2 +
 drivers/net/wireless/ath/ath10k/htt_tx.c |  2 +
 drivers/net/wireless/ath/ath10k/mac.c    | 76 ++++++++++++++++++++++++++++++--
 6 files changed, 91 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index e80b2f1..55cd06f 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -345,6 +345,7 @@ struct ath10k {
 	struct ieee80211_hw *hw;
 	struct device *dev;
 	u8 mac_addr[ETH_ALEN];
+	u8 tx_flush_failed; /* failure case counter */
 
 	u32 chip_id;
 	u32 target_version;
@@ -378,6 +379,13 @@ struct ath10k {
 	struct ath10k_htc htc;
 	struct ath10k_htt htt;
 
+	/* Stats to help debug tx hang issues */
+	u64 htc_send_tot;
+	u64 htc_tx;
+	u64 htc_tx_compl;
+	u64 htc_mgt_tx;
+	u64 htc_mgt_compl;
+
 	struct ath10k_hw_params {
 		u32 id;
 		const char *name;
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index bca5c41..e4fe04d 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -191,6 +191,8 @@ int ath10k_htc_send(struct ath10k_htc *htc,
 	if (ret)
 		goto err_unmap;
 
+	htc->ar->htc_send_tot++;
+
 	return 0;
 
 err_unmap:
diff --git a/drivers/net/wireless/ath/ath10k/htt.c b/drivers/net/wireless/ath/ath10k/htt.c
index 69697af5..67d8e47 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -56,6 +56,10 @@ int ath10k_htt_attach(struct ath10k *ar)
 	htt->ar = ar;
 	htt->max_throughput_mbps = 800;
 
+	/* Clear some htc related counters */
+	ar->htc_send_tot = ar->htc_tx = ar->htc_tx_compl = ar->htc_mgt_tx = 0;
+	ar->htc_mgt_compl = 0;
+
 	/*
 	 * Connect to HTC service.
 	 * This has to be done before calling ath10k_htt_rx_attach,
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index abe5665..928bca2 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1421,6 +1421,7 @@ static void ath10k_htt_rx_frm_tx_compl(struct ath10k *ar,
 		msdu_id = resp->data_tx_completion.msdus[i];
 		tx_done.msdu_id = __le16_to_cpu(msdu_id);
 		ath10k_txrx_tx_unref(htt, &tx_done);
+		ar->htc_tx_compl++;
 	}
 }
 
@@ -1484,6 +1485,7 @@ void ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
 
 		spin_lock_bh(&htt->tx_lock);
 		ath10k_txrx_tx_unref(htt, &tx_done);
+		ar->htc_mgt_compl++;
 		spin_unlock_bh(&htt->tx_lock);
 		break;
 	}
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 22a4542..db0c04d 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -364,6 +364,7 @@ int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
 	if (res)
 		goto err_unmap_msdu;
 
+	htt->ar->htc_mgt_tx++;
 	return 0;
 
 err_unmap_msdu:
@@ -521,6 +522,7 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
 	if (res)
 		goto err_unmap_msdu;
 
+	htt->ar->htc_tx++;
 	return 0;
 
 err_unmap_msdu:
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d19022d..e4f9754 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3636,6 +3636,14 @@ static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
 	struct ath10k *ar = hw->priv;
 	bool skip;
 	int ret;
+	s32 hw_queued;
+	s32 hw_reaped;
+	int num_pending_tx;
+	u64 htc_send_tot;
+	u64 htc_tx;
+	u64 htc_tx_compl;
+	u64 htc_mgt_tx;
+	u64 htc_mgt_compl;
 
 	/* mac80211 doesn't care if we really xmit queued frames or not
 	 * we'll collect those frames either way if we stop/delete vdevs */
@@ -3647,6 +3655,19 @@ static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
 	if (ar->state == ATH10K_STATE_WEDGED)
 		goto skip;
 
+	/* Refresh firmware stats to aid debugging */
+	ath10k_refresh_peer_stats(ar);
+
+	hw_queued = ar->debug.target_stats.hw_queued;
+	hw_reaped = ar->debug.target_stats.hw_reaped;
+	num_pending_tx = ar->htt.num_pending_tx;
+
+	htc_send_tot = ar->htc_send_tot;
+	htc_tx = ar->htc_tx;
+	htc_tx_compl = ar->htc_tx_compl;
+	htc_mgt_tx = ar->htc_mgt_tx;
+	htc_mgt_compl = ar->htc_mgt_compl;
+
 	ret = wait_event_timeout(ar->htt.empty_tx_wq, ({
 			bool empty;
 
@@ -3659,9 +3680,58 @@ static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
 			(empty || skip);
 		}), ATH10K_FLUSH_TIMEOUT_HZ);
 
-	if (ret <= 0 || skip)
-		ath10k_warn("failed to flush transmit queue (skip %i ar-state %i): %i\n",
-			    skip, ar->state, ret);
+	if (ret <= 0 || skip) {
+		int i;
+		/* Refresh firmware stats to aid debugging */
+		ath10k_refresh_peer_stats(ar);
+
+		ath10k_err("failed to flush transmit queue (skip %i ar-state %i pending_tx %i  pre-pending-tx: %i): %i\n",
+			   skip, ar->state, ar->htt.num_pending_tx,
+			   num_pending_tx, ret);
+		ath10k_err("pre: htc-send-tot: %llu  htt-tx %llu  tx-compl %llu  mgt-tx %llu  mgt-compl %llu\n",
+			   htc_send_tot, htc_tx, htc_tx_compl,
+			   htc_mgt_tx, htc_mgt_compl);
+		ath10k_err("post: htc-send-tot: %llu  htt-tx %llu  tx-compl %llu  mgt-tx %llu  mgt-compl %llu\n",
+			   ar->htc_send_tot, ar->htc_tx, ar->htc_tx_compl,
+			   ar->htc_mgt_tx, ar->htc_mgt_compl);
+		ath10k_err("pre: hw-queued: %d  hw-reaped: %d\n",
+			   hw_queued, hw_reaped);
+		ath10k_err("post: hw-queued: %d  hw-reaped: %d\n",
+			   ar->debug.target_stats.hw_queued,
+			   ar->debug.target_stats.hw_reaped);
+
+		for (i = 0; i < ar->htt.max_num_pending_tx; i++) {
+			int q;
+
+			if (!ar->htt.pending_tx[i])
+				continue;
+
+			ath10k_err("stuck-skb: %p len %d tx-id %d\n",
+				   ar->htt.pending_tx[i],
+				   ar->htt.pending_tx[i]->len, i);
+			/* Only print skb contents if debug data is
+			 * enabled.
+			 */
+			if (!(ath10k_debug_mask & ATH10K_DBG_DATA))
+				continue;
+			for (q = 0; q < ar->htt.pending_tx[i]->len; q++) {
+				printk("%02hx ",
+				       ar->htt.pending_tx[i]->data[q]);
+				if (((q + 1) & 0x1f) == 0x1f)
+					printk("\n");
+			}
+		}
+		if ((++ar->tx_flush_failed > 1) &&
+		    (ar->state != ATH10K_STATE_RESTARTING)) {
+			/* This does not appear recoverable, attempt reset. */
+			ath10k_err("failed to flush transmit queue %d times, attempting hardware reset.\n",
+				ar->tx_flush_failed);
+			ar->tx_flush_failed = 0;
+			queue_work(ar->workqueue, &ar->restart_work);
+		}
+	} else {
+		ar->tx_flush_failed = 0;
+	}
 
 skip:
 	mutex_unlock(&ar->conf_mutex);
-- 
1.7.11.7



From michal.kazior at tieto.com  Wed Apr  2 01:00:32 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 2 Apr 2014 07:00:32 +0200
Subject: More on ath10k_flush.
In-Reply-To: <533ABB20.3000407@candelatech.com>
References: <533A0729.4030907@candelatech.com>
 <CA+BoTQm8YEaz7B0jF1GDQrfczEA3tToJPTMx0oS-oZpH25Rkrw@mail.gmail.com>
 <533ABB20.3000407@candelatech.com>
Message-ID: <CA+BoTQkn92ZOYOx37WhYpNjr0eWCW_nGSMyVX5C1p1zKV=ZPpw@mail.gmail.com>

On 1 April 2014 15:12, Ben Greear <greearb at candelatech.com> wrote:
> On 03/31/2014 10:44 PM, Michal Kazior wrote:
>> On 1 April 2014 02:24, Ben Greear <greearb at candelatech.com> wrote:

[...]

>>> Do we need to somehow shut down all tx logic during the ath10k_flush
>>> so that (other?) stations cannot transmit?
>>
>>
>> This seems strange. drv_flush() is called with all tx queues being
>> stopped in mac80211 with IEEE80211_QUEUE_STOP_REASON_FLUSH. I guess
>> you can still receive a few frames (due to SMP with many interfaces),
>> but that's it (at most num_cpus-1 I guess). You shouldn't be seeing
>> 4000 frames being queued while you flush.
>
>
> Subsequent debugging makes me think the extra packets are not coming
> from the upper stack.  Possibly there are ath10k<->firmware management
> messages
> being queued or something like that?

ath10k_flush() waits only for HTT Tx. It doesn't even wait for
management Tx (it probably should..).

There's a limit to the number of outstanding HTT Tx requests - it is
1424 (+n_cpus - 1). So it is possible to see at most this much frames
being completed while waiting for a flush.


Micha?


From kvalo at qca.qualcomm.com  Wed Apr  2 01:27:48 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 2 Apr 2014 08:27:48 +0300
Subject: [PATCH] ath10k: fix initial radar detection logic
In-Reply-To: <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Tue, 1 Apr 2014 09:25:23 +0200")
References: <1396015934-7723-1-git-send-email-michal.kazior@tieto.com>
 <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87eh1gs3l7.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> This fixes a problem of initial radar detection
> (CAC) being stuck and blocking Rx in some cases
> until all interfaces were brought down.

It would be good to describe more about the cases where this problem
happened.

> For userspace this meant first run of hostapd
> would perform CAC but due to filtered Rx no
> clients would associate. Subsequent runs of
> hostapd would not perform CAC (as it was already
> done) and would associate clients.
>
> This also makes sure radar detection is performed
> when bandwidth is widened. Before if 20MHz CAC was
> performed then 40MHz CAC wouldn't start monitor
> vdev effectively disabling initial radar
> detection.
>
> A driver should just start/stop radar detection
> based on hw->conf.radar_enabled. However, since
> ath10k needs to start a monitor vdev for the
> initial radar detection special care needs to be
> applied.
>
> While at it cleanup the code a bit.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

[...]

> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -434,6 +434,8 @@ struct ath10k {
>  	unsigned int filter_flags;
>  	unsigned long dev_flags;
>  	u32 dfs_block_radar_events;
> +	bool radar_enabled; /* protected by conf_mutex */
> +	int num_started_vdevs; /* protected by conf_mutex */

I would prefer style like this:

        u32 dfs_block_radar_events;

        /* these are protected by conf_mutex */
        bool radar_enabled; 
        int num_started_vdevs;

> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -489,6 +489,8 @@ static inline int ath10k_vdev_setup_sync(struct ath10k *ar)
>  	return 0;
>  }
>  
> +static void ath10k_recalc_radar_detection(struct ath10k *ar);

Forward declarations should be avoided if possible. Can you add a new
patch which just moves ath10k_recalc_radar_detection() and in this patch
you do the modifications in the function?

> @@ -571,6 +576,11 @@ static int ath10k_vdev_stop(struct ath10k_vif *arvif)
>  		return ret;
>  	}
>  
> +	if (WARN_ON(ar->num_started_vdevs == 0)) {
> +		ar->num_started_vdevs--;
> +		ath10k_recalc_radar_detection(ar);

Now num_started_vdevs will be -1, what does that mean? It would be good
to document that in struct ath10k.

-- 
Kalle Valo


From michal.kazior at tieto.com  Wed Apr  2 01:48:53 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 2 Apr 2014 07:48:53 +0200
Subject: [PATCH] ath10k: fix initial radar detection logic
In-Reply-To: <87eh1gs3l7.fsf@kamboji.qca.qualcomm.com>
References: <1396015934-7723-1-git-send-email-michal.kazior@tieto.com>
 <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
 <87eh1gs3l7.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CA+BoTQmbQ0qAO-HGgwjvcZFSVom+QrX+J9pwnb-QUE4QMUBUcQ@mail.gmail.com>

On 2 April 2014 07:27, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> This fixes a problem of initial radar detection
>> (CAC) being stuck and blocking Rx in some cases
>> until all interfaces were brought down.
>
> It would be good to describe more about the cases where this problem
> happened.

Ok.


>> For userspace this meant first run of hostapd
>> would perform CAC but due to filtered Rx no
>> clients would associate. Subsequent runs of
>> hostapd would not perform CAC (as it was already
>> done) and would associate clients.
>>
>> This also makes sure radar detection is performed
>> when bandwidth is widened. Before if 20MHz CAC was
>> performed then 40MHz CAC wouldn't start monitor
>> vdev effectively disabling initial radar
>> detection.
>>
>> A driver should just start/stop radar detection
>> based on hw->conf.radar_enabled. However, since
>> ath10k needs to start a monitor vdev for the
>> initial radar detection special care needs to be
>> applied.
>>
>> While at it cleanup the code a bit.
>>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>
> [...]
>
>> --- a/drivers/net/wireless/ath/ath10k/core.h
>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>> @@ -434,6 +434,8 @@ struct ath10k {
>>       unsigned int filter_flags;
>>       unsigned long dev_flags;
>>       u32 dfs_block_radar_events;
>> +     bool radar_enabled; /* protected by conf_mutex */
>> +     int num_started_vdevs; /* protected by conf_mutex */
>
> I would prefer style like this:
>
>         u32 dfs_block_radar_events;
>
>         /* these are protected by conf_mutex */
>         bool radar_enabled;
>         int num_started_vdevs;

Ok.


>
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -489,6 +489,8 @@ static inline int ath10k_vdev_setup_sync(struct ath10k *ar)
>>       return 0;
>>  }
>>
>> +static void ath10k_recalc_radar_detection(struct ath10k *ar);
>
> Forward declarations should be avoided if possible. Can you add a new
> patch which just moves ath10k_recalc_radar_detection() and in this patch
> you do the modifications in the function?

The we need to move ath10k_cac_start/stop and possibly a few other
functions as well. I'll check that out.


>> @@ -571,6 +576,11 @@ static int ath10k_vdev_stop(struct ath10k_vif *arvif)
>>               return ret;
>>       }
>>
>> +     if (WARN_ON(ar->num_started_vdevs == 0)) {
>> +             ar->num_started_vdevs--;
>> +             ath10k_recalc_radar_detection(ar);
>
> Now num_started_vdevs will be -1, what does that mean? It would be good
> to document that in struct ath10k.

Ah, it's missing "!" in front of the WARN_ON..


Micha?


From kvalo at qca.qualcomm.com  Wed Apr  2 03:31:31 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 2 Apr 2014 10:31:31 +0300
Subject: [PATCH] ath10k: remove not needed warning when peer unmap
In-Reply-To: <1396340628-4570-1-git-send-email-janusz.dziedzic@tieto.com>
 (Janusz Dziedzic's message of "Tue, 1 Apr 2014 10:23:48 +0200")
References: <1396340628-4570-1-git-send-email-janusz.dziedzic@tieto.com>
Message-ID: <877g78rxv0.fsf@kamboji.qca.qualcomm.com>

Janusz Dziedzic <janusz.dziedzic at tieto.com> writes:

> Remove not needed warning when get peer unmap
> event from the firmware. This is not critical
> message. Instead print this as a debug message.

I don't agree with that statement. If that would be true, we could
remove a lot of warnings from ath10k. We have these warnings to catch
problems early, which again improves the quality of the driver.

Your commit log was again missing the "why?" part. I assume the reason
for this patch is the problem of seeing the warning "unknown peer id 2"
when putting the interface is down, which again is a spurious event from
the firmware? You should document that in the commit log as well as add
a short comment to the code explaining why we only print a debug message
when that happens.

Other idea I had would be to keep the warning message but add a new test
to detect this problematic case, but I guess for that we would need to
add a new state "stopping" to catch that? For example, something like
this:

if state == stopping and event->id == 2
        dbg("foo")
else
        warn("bar")

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  2 03:32:55 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 2 Apr 2014 10:32:55 +0300
Subject: [PATCH 1/1] ath10k:  add helper method to grab debug stats.
In-Reply-To: <1396374940-21453-1-git-send-email-greearb@candelatech.com>
 (greearb@candelatech.com's message of "Tue, 1 Apr 2014 10:55:40
 -0700")
References: <1396374940-21453-1-git-send-email-greearb@candelatech.com>
Message-ID: <8738hwrxso.fsf@kamboji.qca.qualcomm.com>

greearb at candelatech.com writes:

> From: Ben Greear <greearb at candelatech.com>
>
> It can be nice to update the firmware's stats while
> debugging other bits of the driver, so add helper method
> to do this.
>
> Signed-off-by: Ben Greear <greearb at candelatech.com>

[...]

> --- a/drivers/net/wireless/ath/ath10k/debug.h
> +++ b/drivers/net/wireless/ath/ath10k/debug.h
> @@ -135,4 +135,6 @@ struct dbglog_hdr_s {
>  
>  void ath10k_dbg_print_fw_dbg_buffer(u8 *buffer, int len, const char* lvl);
>  
> +int ath10k_refresh_peer_stats(struct ath10k *ar);

I don't see anyone calling this. How are you planning to use it?

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  2 03:37:58 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 2 Apr 2014 10:37:58 +0300
Subject: [PATCH] ath10k: remove not needed warning when peer unmap
In-Reply-To: <1396340628-4570-1-git-send-email-janusz.dziedzic@tieto.com>
 (Janusz Dziedzic's message of "Tue, 1 Apr 2014 10:23:48 +0200")
References: <1396340628-4570-1-git-send-email-janusz.dziedzic@tieto.com>
Message-ID: <87vbusqizt.fsf@kamboji.qca.qualcomm.com>

Janusz Dziedzic <janusz.dziedzic at tieto.com> writes:

> Remove not needed warning when get peer unmap
> event from the firmware. This is not critical
> message. Instead print this as a debug message.
>
> Signed-off-by: Janusz Dziedzic <janusz.dziedzic at tieto.com>

This one has a new checkpatch warning:

drivers/net/wireless/ath/ath10k/txrx.c:204: CHECK: Alignment should match open parenthesis

-- 
Kalle Valo


From greearb at candelatech.com  Wed Apr  2 10:57:47 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 02 Apr 2014 07:57:47 -0700
Subject: [PATCH 1/1] ath10k:  add helper method to grab debug stats.
In-Reply-To: <8738hwrxso.fsf@kamboji.qca.qualcomm.com>
References: <1396374940-21453-1-git-send-email-greearb@candelatech.com>
 <8738hwrxso.fsf@kamboji.qca.qualcomm.com>
Message-ID: <533C256B.9090209@candelatech.com>

On 04/02/2014 12:32 AM, Kalle Valo wrote:
> greearb at candelatech.com writes:
>
>> From: Ben Greear <greearb at candelatech.com>
>>
>> It can be nice to update the firmware's stats while
>> debugging other bits of the driver, so add helper method
>> to do this.
>>
>> Signed-off-by: Ben Greear <greearb at candelatech.com>
>
> [...]
>
>> --- a/drivers/net/wireless/ath/ath10k/debug.h
>> +++ b/drivers/net/wireless/ath/ath10k/debug.h
>> @@ -135,4 +135,6 @@ struct dbglog_hdr_s {
>>
>>   void ath10k_dbg_print_fw_dbg_buffer(u8 *buffer, int len, const char* lvl);
>>
>> +int ath10k_refresh_peer_stats(struct ath10k *ar);
>
> I don't see anyone calling this. How are you planning to use it?


The RFC patch that debugs tx-hang calls it..nice to see he firmware's
buffer reap stats and such before/after trying to flush the buffers.

I figure it will be useful for other such uses as well, now that stats
actually work.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Wed Apr  2 10:59:07 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 02 Apr 2014 07:59:07 -0700
Subject: [PATCH] ath10k: remove not needed warning when peer unmap
In-Reply-To: <877g78rxv0.fsf@kamboji.qca.qualcomm.com>
References: <1396340628-4570-1-git-send-email-janusz.dziedzic@tieto.com>
 <877g78rxv0.fsf@kamboji.qca.qualcomm.com>
Message-ID: <533C25BB.7080803@candelatech.com>

On 04/02/2014 12:31 AM, Kalle Valo wrote:
> Janusz Dziedzic <janusz.dziedzic at tieto.com> writes:
>
>> Remove not needed warning when get peer unmap
>> event from the firmware. This is not critical
>> message. Instead print this as a debug message.
>
> I don't agree with that statement. If that would be true, we could
> remove a lot of warnings from ath10k. We have these warnings to catch
> problems early, which again improves the quality of the driver.

I see this message all the time, by the way...  I have been ignoring
it so far, but if it's  real issue then I can pay more attention.

Thanks,
Ben

>
> Your commit log was again missing the "why?" part. I assume the reason
> for this patch is the problem of seeing the warning "unknown peer id 2"
> when putting the interface is down, which again is a spurious event from
> the firmware? You should document that in the commit log as well as add
> a short comment to the code explaining why we only print a debug message
> when that happens.
>
> Other idea I had would be to keep the warning message but add a new test
> to detect this problematic case, but I guess for that we would need to
> add a new state "stopping" to catch that? For example, something like
> this:
>
> if state == stopping and event->id == 2
>          dbg("foo")
> else
>          warn("bar")
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Wed Apr  2 17:57:21 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 02 Apr 2014 14:57:21 -0700
Subject: Clean-ish rebase on top of 3.14.0 (final)?
In-Reply-To: <87ioqtsdgt.fsf@kamboji.qca.qualcomm.com>
References: <53399703.1060302@candelatech.com>
 <87ioqtsdgt.fsf@kamboji.qca.qualcomm.com>
Message-ID: <533C87C1.2090908@candelatech.com>

On 04/01/2014 12:42 AM, Kalle Valo wrote:
> Ben Greear <greearb at candelatech.com> writes:
>
>> Kalle:  In case you end up with your tree in a clean rebase
>> on stock 3.14.0 (or as clean as is reasonable), could you let
>> us know and give us a bit of time before pulling down more
>> upstream stuff?
>>
>> The reason is that I would like to freeze a 3.14 kernel with whatever
>> ath10k patches are currently in your tree and attempt to stabalize
>> it...
>
> Do you mean 3.14 plus only ath10k patches? Or are you willing to take
> other wireless patches as well?

Other wireless patches would be fine.  I just don't want all of 3.15.0-rc1,
at least until I can snapshot a 3.14 to try to stabalize.

> Basically I have two branches in my ath.git:
>
> o ath-next: wireless-next + latest ath10k patches
>
> o master: wireless-testing + ath-next (= latest ath10k patches)
>
> I only merge latest wireless-next to ath-next seldomly, usually once
> every 1-2 months. But I merge wireless-testing to master branch at least
> weekly.
>
> One idea would be that you merge 3.14 tag with ath-next. That way you
> get latest wireless code on top of 3.14. Would that work?

That sounds like a good thing to try..I'll see how that works.

Thanks,
Ben

>
> I'm planning to merge wireless-next to ath-next once John opens his
> trees again, which usually happens just after the merge window is
> closed.
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From michal.kazior at tieto.com  Fri Apr  4 07:18:25 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri,  4 Apr 2014 13:18:25 +0200
Subject: [PATCH] ath10k: refactor monitor code
Message-ID: <1396610305-5229-1-git-send-email-michal.kazior@tieto.com>

It was possible to create/delete/start/stop
monitor vdev from a few places that were not
exclusively protected against each other. This
resulted in monitor vdev being stopped/removed by
one call origin while another one was expecting it
to continue running.

For example if CAC was started and interface's
promiscuous mode was toggled monitor vdev was
removed from the driver meaning no radar would be
detected. In additional a warning would be printed
upon CAC completion complaining it tried to stop
non-running monitor vdev.

The patch simplifies monitor code by removing
IEEE80211_HW_WANT_MONITOR_VIF (which wasn't really
ever needed) and improves state tracking. It also
unifies prints.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.h   |   5 +-
 drivers/net/wireless/ath/ath10k/htt_rx.c |   2 +-
 drivers/net/wireless/ath/ath10k/mac.c    | 224 ++++++++++++++++++-------------
 3 files changed, 133 insertions(+), 98 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 8edd6da..3302976 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -428,9 +428,10 @@ struct ath10k {
 	struct cfg80211_chan_def chandef;
 
 	int free_vdev_map;
+	bool promisc;
+	bool monitor;
 	int monitor_vdev_id;
-	bool monitor_enabled;
-	bool monitor_present;
+	bool monitor_started;
 	unsigned int filter_flags;
 	unsigned long dev_flags;
 	u32 dfs_block_radar_events;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index f7ecc10..f85a3cf 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1120,7 +1120,7 @@ static bool ath10k_htt_rx_amsdu_allowed(struct ath10k_htt *htt,
 	if (status != HTT_RX_IND_MPDU_STATUS_OK &&
 	    status != HTT_RX_IND_MPDU_STATUS_TKIP_MIC_ERR &&
 	    status != HTT_RX_IND_MPDU_STATUS_ERR_INV_PEER &&
-	    !htt->ar->monitor_enabled) {
+	    !htt->ar->monitor_started) {
 		ath10k_dbg(ATH10K_DBG_HTT,
 			   "htt rx ignoring frame w/ status %d\n",
 			   status);
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 58ec5a7..3c99803 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -574,7 +574,20 @@ static int ath10k_vdev_stop(struct ath10k_vif *arvif)
 	return ret;
 }
 
-static int ath10k_monitor_start(struct ath10k *ar, int vdev_id)
+static bool ath10k_monitor_is_enabled(struct ath10k *ar)
+{
+	lockdep_assert_held(&ar->conf_mutex);
+
+	ath10k_dbg(ATH10K_DBG_MAC,
+		   "mac monitor refs: promisc %d monitor %d cac %d\n",
+		   ar->promisc, ar->monitor,
+		   test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags));
+
+	return ar->promisc || ar->monitor ||
+	       test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags);
+}
+
+static int ath10k_monitor_vdev_start(struct ath10k *ar, int vdev_id)
 {
 	struct cfg80211_chan_def *chandef = &ar->chandef;
 	struct ieee80211_channel *channel = chandef->chan;
@@ -583,11 +596,6 @@ static int ath10k_monitor_start(struct ath10k *ar, int vdev_id)
 
 	lockdep_assert_held(&ar->conf_mutex);
 
-	if (!ar->monitor_present) {
-		ath10k_warn("mac monitor stop -- monitor is not present\n");
-		return -EINVAL;
-	}
-
 	arg.vdev_id = vdev_id;
 	arg.channel.freq = channel->center_freq;
 	arg.channel.band_center_freq1 = chandef->center_freq1;
@@ -605,14 +613,14 @@ static int ath10k_monitor_start(struct ath10k *ar, int vdev_id)
 
 	ret = ath10k_wmi_vdev_start(ar, &arg);
 	if (ret) {
-		ath10k_warn("failed to start Monitor vdev %i: %d\n",
+		ath10k_warn("failed to request monitor vdev %i start: %d\n",
 			    vdev_id, ret);
 		return ret;
 	}
 
 	ret = ath10k_vdev_setup_sync(ar);
 	if (ret) {
-		ath10k_warn("failed to syncronise setup for monitor vdev %i: %d\n",
+		ath10k_warn("failed to synchronize setup for monitor vdev %i: %d\n",
 			    vdev_id, ret);
 		return ret;
 	}
@@ -625,8 +633,9 @@ static int ath10k_monitor_start(struct ath10k *ar, int vdev_id)
 	}
 
 	ar->monitor_vdev_id = vdev_id;
-	ar->monitor_enabled = true;
 
+	ath10k_dbg(ATH10K_DBG_MAC, "mac monitor vdev %i started\n",
+		   ar->monitor_vdev_id);
 	return 0;
 
 vdev_stop:
@@ -638,22 +647,12 @@ vdev_stop:
 	return ret;
 }
 
-static int ath10k_monitor_stop(struct ath10k *ar)
+static int ath10k_monitor_vdev_stop(struct ath10k *ar)
 {
 	int ret = 0;
 
 	lockdep_assert_held(&ar->conf_mutex);
 
-	if (!ar->monitor_present) {
-		ath10k_warn("mac monitor stop -- monitor is not present\n");
-		return -EINVAL;
-	}
-
-	if (!ar->monitor_enabled) {
-		ath10k_warn("mac monitor stop -- monitor is not enabled\n");
-		return -EINVAL;
-	}
-
 	ret = ath10k_wmi_vdev_down(ar, ar->monitor_vdev_id);
 	if (ret)
 		ath10k_warn("failed to put down monitor vdev %i: %d\n",
@@ -661,7 +660,7 @@ static int ath10k_monitor_stop(struct ath10k *ar)
 
 	ret = ath10k_wmi_vdev_stop(ar, ar->monitor_vdev_id);
 	if (ret)
-		ath10k_warn("failed to stop monitor vdev %i: %d\n",
+		ath10k_warn("failed to to request monitor vdev %i stop: %d\n",
 			    ar->monitor_vdev_id, ret);
 
 	ret = ath10k_vdev_setup_sync(ar);
@@ -669,24 +668,20 @@ static int ath10k_monitor_stop(struct ath10k *ar)
 		ath10k_warn("failed to synchronise monitor vdev %i: %d\n",
 			    ar->monitor_vdev_id, ret);
 
-	ar->monitor_enabled = false;
+	ath10k_dbg(ATH10K_DBG_MAC, "mac monitor vdev %i stopped\n",
+		   ar->monitor_vdev_id);
 	return ret;
 }
 
-static int ath10k_monitor_create(struct ath10k *ar)
+static int ath10k_monitor_vdev_create(struct ath10k *ar)
 {
 	int bit, ret = 0;
 
 	lockdep_assert_held(&ar->conf_mutex);
 
-	if (ar->monitor_present) {
-		ath10k_warn("monitor mode already enabled\n");
-		return 0;
-	}
-
 	bit = ffs(ar->free_vdev_map);
 	if (bit == 0) {
-		ath10k_warn("no free vdev slots\n");
+		ath10k_warn("failed to find free vdev id for monitor vdev\n");
 		return -ENOMEM;
 	}
 
@@ -697,7 +692,7 @@ static int ath10k_monitor_create(struct ath10k *ar)
 				     WMI_VDEV_TYPE_MONITOR,
 				     0, ar->mac_addr);
 	if (ret) {
-		ath10k_warn("failed to create WMI monitor vdev %i: %d\n",
+		ath10k_warn("failed to request monitor vdev %i creation: %d\n",
 			    ar->monitor_vdev_id, ret);
 		goto vdev_fail;
 	}
@@ -705,7 +700,6 @@ static int ath10k_monitor_create(struct ath10k *ar)
 	ath10k_dbg(ATH10K_DBG_MAC, "mac monitor vdev %d created\n",
 		   ar->monitor_vdev_id);
 
-	ar->monitor_present = true;
 	return 0;
 
 vdev_fail:
@@ -716,30 +710,91 @@ vdev_fail:
 	return ret;
 }
 
-static int ath10k_monitor_destroy(struct ath10k *ar)
+static int ath10k_monitor_vdev_delete(struct ath10k *ar)
 {
 	int ret = 0;
 
 	lockdep_assert_held(&ar->conf_mutex);
 
-	if (!ar->monitor_present)
-		return 0;
-
 	ret = ath10k_wmi_vdev_delete(ar, ar->monitor_vdev_id);
 	if (ret) {
-		ath10k_warn("failed to delete WMI vdev %i: %d\n",
+		ath10k_warn("failed to request wmi monitor vdev %i removal: %d\n",
 			    ar->monitor_vdev_id, ret);
 		return ret;
 	}
 
 	ar->free_vdev_map |= 1 << (ar->monitor_vdev_id);
-	ar->monitor_present = false;
 
 	ath10k_dbg(ATH10K_DBG_MAC, "mac monitor vdev %d deleted\n",
 		   ar->monitor_vdev_id);
 	return ret;
 }
 
+static int ath10k_monitor_start(struct ath10k *ar)
+{
+	int ret;
+
+	lockdep_assert_held(&ar->conf_mutex);
+
+	if (!ath10k_monitor_is_enabled(ar)) {
+		ath10k_warn("trying to start monitor with no references\n");
+		return 0;
+	}
+
+	if (ar->monitor_started) {
+		ath10k_dbg(ATH10K_DBG_MAC, "mac monitor already started\n");
+		return 0;
+	}
+
+	ret = ath10k_monitor_vdev_create(ar);
+	if (ret) {
+		ath10k_warn("failed to create monitor vdev: %d\n", ret);
+		return ret;
+	}
+
+	ret = ath10k_monitor_vdev_start(ar, ar->monitor_vdev_id);
+	if (ret) {
+		ath10k_warn("failed to start monitor vdev: %d\n", ret);
+		ath10k_monitor_vdev_delete(ar);
+		return ret;
+	}
+
+	ar->monitor_started = true;
+	ath10k_dbg(ATH10K_DBG_MAC, "mac monitor started\n");
+
+	return 0;
+}
+
+static void ath10k_monitor_stop(struct ath10k *ar)
+{
+	int ret;
+
+	lockdep_assert_held(&ar->conf_mutex);
+
+	if (ath10k_monitor_is_enabled(ar)) {
+		ath10k_dbg(ATH10K_DBG_MAC,
+			   "mac monitor will be stopped later\n");
+		return;
+	}
+
+	if (!ar->monitor_started) {
+		ath10k_dbg(ATH10K_DBG_MAC,
+			   "mac monitor probably failed to start earlier\n");
+		return;
+	}
+
+	ret = ath10k_monitor_vdev_stop(ar);
+	if (ret)
+		ath10k_warn("failed to stop monitor vdev: %d\n", ret);
+
+	ret = ath10k_monitor_vdev_delete(ar);
+	if (ret)
+		ath10k_warn("failed to delete monitor vdev: %d\n", ret);
+
+	ar->monitor_started = false;
+	ath10k_dbg(ATH10K_DBG_MAC, "mac monitor stopped\n");
+}
+
 static int ath10k_recalc_rtscts_prot(struct ath10k_vif *arvif)
 {
 	struct ath10k *ar = arvif->ar;
@@ -768,19 +823,13 @@ static int ath10k_start_cac(struct ath10k *ar)
 
 	set_bit(ATH10K_CAC_RUNNING, &ar->dev_flags);
 
-	ret = ath10k_monitor_create(ar);
+	ret = ath10k_monitor_start(ar);
 	if (ret) {
+		ath10k_warn("failed to start monitor (cac): %d\n", ret);
 		clear_bit(ATH10K_CAC_RUNNING, &ar->dev_flags);
 		return ret;
 	}
 
-	ret = ath10k_monitor_start(ar, ar->monitor_vdev_id);
-	if (ret) {
-		clear_bit(ATH10K_CAC_RUNNING, &ar->dev_flags);
-		ath10k_monitor_destroy(ar);
-		return ret;
-	}
-
 	ath10k_dbg(ATH10K_DBG_MAC, "mac cac start monitor vdev %d\n",
 		   ar->monitor_vdev_id);
 
@@ -795,9 +844,8 @@ static int ath10k_stop_cac(struct ath10k *ar)
 	if (!test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags))
 		return 0;
 
-	ath10k_monitor_stop(ar);
-	ath10k_monitor_destroy(ar);
 	clear_bit(ATH10K_CAC_RUNNING, &ar->dev_flags);
+	ath10k_monitor_stop(ar);
 
 	ath10k_dbg(ATH10K_DBG_MAC, "mac cac finished\n");
 
@@ -1828,7 +1876,7 @@ static u8 ath10k_tx_h_get_vdev_id(struct ath10k *ar,
 	if (info->control.vif)
 		return ath10k_vif_to_arvif(info->control.vif)->vdev_id;
 
-	if (ar->monitor_enabled)
+	if (ar->monitor_started)
 		return ar->monitor_vdev_id;
 
 	ath10k_warn("failed to resolve vdev id\n");
@@ -2266,7 +2314,13 @@ void ath10k_halt(struct ath10k *ar)
 {
 	lockdep_assert_held(&ar->conf_mutex);
 
-	ath10k_stop_cac(ar);
+	if (ath10k_monitor_is_enabled(ar)) {
+		clear_bit(ATH10K_CAC_RUNNING, &ar->dev_flags);
+		ar->promisc = false;
+		ar->monitor = false;
+		ath10k_monitor_stop(ar);
+	}
+
 	del_timer_sync(&ar->scan.timeout);
 	ath10k_offchan_tx_purge(ar);
 	ath10k_mgmt_over_wmi_tx_purge(ar);
@@ -2413,7 +2467,6 @@ static const char *chandef_get_width(enum nl80211_chan_width width)
 static void ath10k_config_chan(struct ath10k *ar)
 {
 	struct ath10k_vif *arvif;
-	bool monitor_was_enabled;
 	int ret;
 
 	lockdep_assert_held(&ar->conf_mutex);
@@ -2427,10 +2480,8 @@ static void ath10k_config_chan(struct ath10k *ar)
 
 	/* First stop monitor interface. Some FW versions crash if there's a
 	 * lone monitor interface. */
-	monitor_was_enabled = ar->monitor_enabled;
-
-	if (ar->monitor_enabled)
-		ath10k_monitor_stop(ar);
+	if (ar->monitor_started)
+		ath10k_monitor_vdev_stop(ar);
 
 	list_for_each_entry(arvif, &ar->arvifs, list) {
 		if (!arvif->is_started)
@@ -2475,8 +2526,8 @@ static void ath10k_config_chan(struct ath10k *ar)
 		}
 	}
 
-	if (monitor_was_enabled)
-		ath10k_monitor_start(ar, ar->monitor_vdev_id);
+	if (ath10k_monitor_is_enabled(ar))
+		ath10k_monitor_vdev_start(ar, ar->monitor_vdev_id);
 }
 
 static int ath10k_config(struct ieee80211_hw *hw, u32 changed)
@@ -2529,10 +2580,18 @@ static int ath10k_config(struct ieee80211_hw *hw, u32 changed)
 		ath10k_config_ps(ar);
 
 	if (changed & IEEE80211_CONF_CHANGE_MONITOR) {
-		if (conf->flags & IEEE80211_CONF_MONITOR)
-			ret = ath10k_monitor_create(ar);
-		else
-			ret = ath10k_monitor_destroy(ar);
+		if (conf->flags & IEEE80211_CONF_MONITOR && !ar->monitor) {
+			ar->monitor = true;
+			ret = ath10k_monitor_start(ar);
+			if (ret) {
+				ath10k_warn("failed to start monitor (config): %d\n", ret);
+				ar->monitor = false;
+			}
+		} else if (!(conf->flags & IEEE80211_CONF_MONITOR) &&
+			   ar->monitor) {
+			ar->monitor = false;
+			ath10k_monitor_stop(ar);
+		}
 	}
 
 	mutex_unlock(&ar->conf_mutex);
@@ -2567,12 +2626,6 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
 	INIT_WORK(&arvif->wep_key_work, ath10k_tx_wep_key_work);
 	INIT_LIST_HEAD(&arvif->list);
 
-	if ((vif->type == NL80211_IFTYPE_MONITOR) && ar->monitor_present) {
-		ath10k_warn("only one monitor interface allowed\n");
-		ret = -EBUSY;
-		goto err;
-	}
-
 	bit = ffs(ar->free_vdev_map);
 	if (bit == 0) {
 		ret = -EBUSY;
@@ -2704,9 +2757,6 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
 		goto err_peer_delete;
 	}
 
-	if (arvif->vdev_type == WMI_VDEV_TYPE_MONITOR)
-		ar->monitor_present = true;
-
 	mutex_unlock(&ar->conf_mutex);
 	return 0;
 
@@ -2763,9 +2813,6 @@ static void ath10k_remove_interface(struct ieee80211_hw *hw,
 		ath10k_warn("failed to delete WMI vdev %i: %d\n",
 			    arvif->vdev_id, ret);
 
-	if (arvif->vdev_type == WMI_VDEV_TYPE_MONITOR)
-		ar->monitor_present = false;
-
 	ath10k_peer_cleanup(ar, arvif->vdev_id);
 
 	mutex_unlock(&ar->conf_mutex);
@@ -2798,28 +2845,16 @@ static void ath10k_configure_filter(struct ieee80211_hw *hw,
 	*total_flags &= SUPPORTED_FILTERS;
 	ar->filter_flags = *total_flags;
 
-	/* Monitor must not be started if it wasn't created first.
-	 * Promiscuous mode may be started on a non-monitor interface - in
-	 * such case the monitor vdev is not created so starting the
-	 * monitor makes no sense. Since ath10k uses no special RX filters
-	 * (only BSS filter in STA mode) there's no need for any special
-	 * action here. */
-	if ((ar->filter_flags & FIF_PROMISC_IN_BSS) &&
-	    !ar->monitor_enabled && ar->monitor_present) {
-		ath10k_dbg(ATH10K_DBG_MAC, "mac monitor %d start\n",
-			   ar->monitor_vdev_id);
-
-		ret = ath10k_monitor_start(ar, ar->monitor_vdev_id);
-		if (ret)
-			ath10k_warn("failed to start monitor mode: %d\n", ret);
-	} else if (!(ar->filter_flags & FIF_PROMISC_IN_BSS) &&
-		   ar->monitor_enabled && ar->monitor_present) {
-		ath10k_dbg(ATH10K_DBG_MAC, "mac monitor %d stop\n",
-			   ar->monitor_vdev_id);
-
-		ret = ath10k_monitor_stop(ar);
-		if (ret)
-			ath10k_warn("failed to stop monitor mode: %d\n", ret);
+	if (ar->filter_flags & FIF_PROMISC_IN_BSS && !ar->promisc) {
+		ar->promisc = true;
+		ret = ath10k_monitor_start(ar);
+		if (ret) {
+			ath10k_warn("failed to start monitor (promisc): %d\n", ret);
+			ar->promisc = false;
+		}
+	} else if (!(ar->filter_flags & FIF_PROMISC_IN_BSS) && ar->promisc) {
+		ar->promisc = false;
+		ath10k_monitor_stop(ar);
 	}
 
 	mutex_unlock(&ar->conf_mutex);
@@ -4579,7 +4614,6 @@ int ath10k_mac_register(struct ath10k *ar)
 			IEEE80211_HW_REPORTS_TX_ACK_STATUS |
 			IEEE80211_HW_HAS_RATE_CONTROL |
 			IEEE80211_HW_SUPPORTS_STATIC_SMPS |
-			IEEE80211_HW_WANT_MONITOR_VIF |
 			IEEE80211_HW_AP_LINK_PS |
 			IEEE80211_HW_SPECTRUM_MGMT;
 
-- 
1.8.5.3



From michal.kazior at tieto.com  Fri Apr  4 07:28:46 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri,  4 Apr 2014 13:28:46 +0200
Subject: [PATCH v2 2/2] ath10k: refactor radar detection code
In-Reply-To: <1396610926-5787-1-git-send-email-michal.kazior@tieto.com>
References: <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1396610926-5787-3-git-send-email-michal.kazior@tieto.com>

If 20MHz CAC completed successfully then
subsequent CAC with wider bandwidth (40Mhz, 80Mhz)
with identical control frequency did not start
monitor vdev making it impossible to detect any
radar pulses during intended CAC.

It also was incorrect to assume ath10k_config() will
be called after CAC is finished. Theoretically for
non-HT channels nothing changes between CAC and
start_ap() (albeit in practice this can be
different). The incorrect assumption led to CAC
not being stopped on non-HT chandefs leading to
all Rx being drooped making it impossible for
clients to associate.

While at it clean up the code a bit.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
v2:
 * change locking comment style [Kalle]
 * get rid of forward declaration [Kalle]
 * fix vdev_stop / WARN_ON (missing !) [Kalle]
 * change commit message
   (the original issue found was CAC not being
    stopped for non-HT channels but this was a
    side-effect of a mac80211 bug, although the
    use of hw->conf.radar_enabled in ath10k was
    also incorrect either way)

 drivers/net/wireless/ath/ath10k/core.h |  4 +++
 drivers/net/wireless/ath/ath10k/mac.c  | 54 +++++++++++-----------------------
 2 files changed, 21 insertions(+), 37 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 8edd6da..5cb9903 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -435,6 +435,10 @@ struct ath10k {
 	unsigned long dev_flags;
 	u32 dfs_block_radar_events;
 
+	/* protected by conf_mutex */
+	bool radar_enabled;
+	int num_started_vdevs;
+
 	struct wmi_pdev_set_wmm_params_arg wmm_params;
 	struct completion install_key_done;
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e1f4227..3333b1f 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -719,49 +719,18 @@ static int ath10k_stop_cac(struct ath10k *ar)
 	return 0;
 }
 
-static const char *ath10k_dfs_state(enum nl80211_dfs_state dfs_state)
+static void ath10k_recalc_radar_detection(struct ath10k *ar)
 {
-	switch (dfs_state) {
-	case NL80211_DFS_USABLE:
-		return "USABLE";
-	case NL80211_DFS_UNAVAILABLE:
-		return "UNAVAILABLE";
-	case NL80211_DFS_AVAILABLE:
-		return "AVAILABLE";
-	default:
-		WARN_ON(1);
-		return "bug";
-	}
-}
-
-static void ath10k_config_radar_detection(struct ath10k *ar)
-{
-	struct ieee80211_channel *chan = ar->hw->conf.chandef.chan;
-	bool radar = ar->hw->conf.radar_enabled;
-	bool chan_radar = !!(chan->flags & IEEE80211_CHAN_RADAR);
-	enum nl80211_dfs_state dfs_state = chan->dfs_state;
 	int ret;
 
 	lockdep_assert_held(&ar->conf_mutex);
 
-	ath10k_dbg(ATH10K_DBG_MAC,
-		   "mac radar config update: chan %dMHz radar %d chan radar %d chan state %s\n",
-		   chan->center_freq, radar, chan_radar,
-		   ath10k_dfs_state(dfs_state));
-
-	/*
-	 * It's safe to call it even if CAC is not started.
-	 * This call here guarantees changing channel, etc. will stop CAC.
-	 */
 	ath10k_stop_cac(ar);
 
-	if (!radar)
-		return;
-
-	if (!chan_radar)
+	if (!ar->radar_enabled)
 		return;
 
-	if (dfs_state != NL80211_DFS_USABLE)
+	if (ar->num_started_vdevs > 0)
 		return;
 
 	ret = ath10k_start_cac(ar);
@@ -832,6 +801,9 @@ static int ath10k_vdev_start(struct ath10k_vif *arvif)
 		return ret;
 	}
 
+	ar->num_started_vdevs++;
+	ath10k_recalc_radar_detection(ar);
+
 	return ret;
 }
 
@@ -858,6 +830,11 @@ static int ath10k_vdev_stop(struct ath10k_vif *arvif)
 		return ret;
 	}
 
+	if (!WARN_ON(ar->num_started_vdevs == 0)) {
+		ar->num_started_vdevs--;
+		ath10k_recalc_radar_detection(ar);
+	}
+
 	return ret;
 }
 
@@ -2341,6 +2318,7 @@ static int ath10k_start(struct ieee80211_hw *hw)
 		goto exit;
 	}
 
+	ar->num_started_vdevs = 0;
 	ath10k_regd_update(ar);
 	ret = 0;
 
@@ -2490,15 +2468,17 @@ static int ath10k_config(struct ieee80211_hw *hw, u32 changed)
 
 	if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
 		ath10k_dbg(ATH10K_DBG_MAC,
-			   "mac config channel %d mhz flags 0x%x\n",
+			   "mac config channel %dMHz flags 0x%x radar %d\n",
 			   conf->chandef.chan->center_freq,
-			   conf->chandef.chan->flags);
+			   conf->chandef.chan->flags,
+			   conf->radar_enabled);
 
 		spin_lock_bh(&ar->data_lock);
 		ar->rx_channel = conf->chandef.chan;
 		spin_unlock_bh(&ar->data_lock);
 
-		ath10k_config_radar_detection(ar);
+		ar->radar_enabled = conf->radar_enabled;
+		ath10k_recalc_radar_detection(ar);
 
 		if (!cfg80211_chandef_identical(&ar->chandef, &conf->chandef)) {
 			ar->chandef = conf->chandef;
-- 
1.8.5.3



From michal.kazior at tieto.com  Fri Apr  4 07:28:45 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri,  4 Apr 2014 13:28:45 +0200
Subject: [PATCH v2 1/2] ath10k: reorder functions
In-Reply-To: <1396610926-5787-1-git-send-email-michal.kazior@tieto.com>
References: <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1396610926-5787-2-git-send-email-michal.kazior@tieto.com>

This is done to avoid forward declarations with
upcomming patches.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
v2:
 * introduced to avoid forward declaration

 drivers/net/wireless/ath/ath10k/mac.c | 170 +++++++++++++++++-----------------
 1 file changed, 85 insertions(+), 85 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 58ec5a7..e1f4227 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -489,91 +489,6 @@ static inline int ath10k_vdev_setup_sync(struct ath10k *ar)
 	return 0;
 }
 
-static int ath10k_vdev_start(struct ath10k_vif *arvif)
-{
-	struct ath10k *ar = arvif->ar;
-	struct cfg80211_chan_def *chandef = &ar->chandef;
-	struct wmi_vdev_start_request_arg arg = {};
-	int ret = 0;
-
-	lockdep_assert_held(&ar->conf_mutex);
-
-	reinit_completion(&ar->vdev_setup_done);
-
-	arg.vdev_id = arvif->vdev_id;
-	arg.dtim_period = arvif->dtim_period;
-	arg.bcn_intval = arvif->beacon_interval;
-
-	arg.channel.freq = chandef->chan->center_freq;
-	arg.channel.band_center_freq1 = chandef->center_freq1;
-	arg.channel.mode = chan_to_phymode(chandef);
-
-	arg.channel.min_power = 0;
-	arg.channel.max_power = chandef->chan->max_power * 2;
-	arg.channel.max_reg_power = chandef->chan->max_reg_power * 2;
-	arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain * 2;
-
-	if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
-		arg.ssid = arvif->u.ap.ssid;
-		arg.ssid_len = arvif->u.ap.ssid_len;
-		arg.hidden_ssid = arvif->u.ap.hidden_ssid;
-
-		/* For now allow DFS for AP mode */
-		arg.channel.chan_radar =
-			!!(chandef->chan->flags & IEEE80211_CHAN_RADAR);
-	} else if (arvif->vdev_type == WMI_VDEV_TYPE_IBSS) {
-		arg.ssid = arvif->vif->bss_conf.ssid;
-		arg.ssid_len = arvif->vif->bss_conf.ssid_len;
-	}
-
-	ath10k_dbg(ATH10K_DBG_MAC,
-		   "mac vdev %d start center_freq %d phymode %s\n",
-		   arg.vdev_id, arg.channel.freq,
-		   ath10k_wmi_phymode_str(arg.channel.mode));
-
-	ret = ath10k_wmi_vdev_start(ar, &arg);
-	if (ret) {
-		ath10k_warn("failed to start WMI vdev %i: %d\n",
-			    arg.vdev_id, ret);
-		return ret;
-	}
-
-	ret = ath10k_vdev_setup_sync(ar);
-	if (ret) {
-		ath10k_warn("failed to synchronise setup for vdev %i: %d\n",
-			    arg.vdev_id, ret);
-		return ret;
-	}
-
-	return ret;
-}
-
-static int ath10k_vdev_stop(struct ath10k_vif *arvif)
-{
-	struct ath10k *ar = arvif->ar;
-	int ret;
-
-	lockdep_assert_held(&ar->conf_mutex);
-
-	reinit_completion(&ar->vdev_setup_done);
-
-	ret = ath10k_wmi_vdev_stop(ar, arvif->vdev_id);
-	if (ret) {
-		ath10k_warn("failed to stop WMI vdev %i: %d\n",
-			    arvif->vdev_id, ret);
-		return ret;
-	}
-
-	ret = ath10k_vdev_setup_sync(ar);
-	if (ret) {
-		ath10k_warn("failed to syncronise setup for vdev %i: %d\n",
-			    arvif->vdev_id, ret);
-		return ret;
-	}
-
-	return ret;
-}
-
 static int ath10k_monitor_start(struct ath10k *ar, int vdev_id)
 {
 	struct cfg80211_chan_def *chandef = &ar->chandef;
@@ -861,6 +776,91 @@ static void ath10k_config_radar_detection(struct ath10k *ar)
 	}
 }
 
+static int ath10k_vdev_start(struct ath10k_vif *arvif)
+{
+	struct ath10k *ar = arvif->ar;
+	struct cfg80211_chan_def *chandef = &ar->chandef;
+	struct wmi_vdev_start_request_arg arg = {};
+	int ret = 0;
+
+	lockdep_assert_held(&ar->conf_mutex);
+
+	reinit_completion(&ar->vdev_setup_done);
+
+	arg.vdev_id = arvif->vdev_id;
+	arg.dtim_period = arvif->dtim_period;
+	arg.bcn_intval = arvif->beacon_interval;
+
+	arg.channel.freq = chandef->chan->center_freq;
+	arg.channel.band_center_freq1 = chandef->center_freq1;
+	arg.channel.mode = chan_to_phymode(chandef);
+
+	arg.channel.min_power = 0;
+	arg.channel.max_power = chandef->chan->max_power * 2;
+	arg.channel.max_reg_power = chandef->chan->max_reg_power * 2;
+	arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain * 2;
+
+	if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
+		arg.ssid = arvif->u.ap.ssid;
+		arg.ssid_len = arvif->u.ap.ssid_len;
+		arg.hidden_ssid = arvif->u.ap.hidden_ssid;
+
+		/* For now allow DFS for AP mode */
+		arg.channel.chan_radar =
+			!!(chandef->chan->flags & IEEE80211_CHAN_RADAR);
+	} else if (arvif->vdev_type == WMI_VDEV_TYPE_IBSS) {
+		arg.ssid = arvif->vif->bss_conf.ssid;
+		arg.ssid_len = arvif->vif->bss_conf.ssid_len;
+	}
+
+	ath10k_dbg(ATH10K_DBG_MAC,
+		   "mac vdev %d start center_freq %d phymode %s\n",
+		   arg.vdev_id, arg.channel.freq,
+		   ath10k_wmi_phymode_str(arg.channel.mode));
+
+	ret = ath10k_wmi_vdev_start(ar, &arg);
+	if (ret) {
+		ath10k_warn("failed to start WMI vdev %i: %d\n",
+			    arg.vdev_id, ret);
+		return ret;
+	}
+
+	ret = ath10k_vdev_setup_sync(ar);
+	if (ret) {
+		ath10k_warn("failed to synchronise setup for vdev %i: %d\n",
+			    arg.vdev_id, ret);
+		return ret;
+	}
+
+	return ret;
+}
+
+static int ath10k_vdev_stop(struct ath10k_vif *arvif)
+{
+	struct ath10k *ar = arvif->ar;
+	int ret;
+
+	lockdep_assert_held(&ar->conf_mutex);
+
+	reinit_completion(&ar->vdev_setup_done);
+
+	ret = ath10k_wmi_vdev_stop(ar, arvif->vdev_id);
+	if (ret) {
+		ath10k_warn("failed to stop WMI vdev %i: %d\n",
+			    arvif->vdev_id, ret);
+		return ret;
+	}
+
+	ret = ath10k_vdev_setup_sync(ar);
+	if (ret) {
+		ath10k_warn("failed to syncronise setup for vdev %i: %d\n",
+			    arvif->vdev_id, ret);
+		return ret;
+	}
+
+	return ret;
+}
+
 static void ath10k_control_beaconing(struct ath10k_vif *arvif,
 				struct ieee80211_bss_conf *info)
 {
-- 
1.8.5.3



From michal.kazior at tieto.com  Fri Apr  4 07:28:44 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri,  4 Apr 2014 13:28:44 +0200
Subject: [PATCH v2 0/2] ath10k: fix radar/cac
In-Reply-To: <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
References: <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1396610926-5787-1-git-send-email-michal.kazior@tieto.com>

Hi,

This loosely depends on `ath10k: refactor monitor
code`. Without it patch this patchset introduces
some (harmless) runtime warnings.

This v2 introduces a non-functional patch to avoid
forward declaration. The [1/2] has a little
conflict with `ath10k: refactor monitor code`
which renames ath10k_monitor_stop() to
ath10k_monitor_vdev_stop().

Part of the original CAC problem is also addressed
in `mac80211: fix radar_enabled propagation`.


Michal Kazior (2):
  ath10k: reorder functions
  ath10k: refactor radar detection code

 drivers/net/wireless/ath/ath10k/core.h |   4 +
 drivers/net/wireless/ath/ath10k/mac.c  | 224 +++++++++++++++------------------
 2 files changed, 106 insertions(+), 122 deletions(-)

-- 
1.8.5.3



From michal.kazior at tieto.com  Fri Apr  4 07:37:40 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri,  4 Apr 2014 13:37:40 +0200
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
Message-ID: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>

Hi,

After digging around I've found what seems to be
the problem with WMI Tx credit starvation and
inability to properly flush Tx in ath10k_flush().

Long story short: if a client that was asleep (as
per what firmware thinks) goes out of range (or
just stops responding) then Tx rots in FW/HW
queues for a few seconds before it's discarded.
For WMI Tx credits this means management frames
eat up Tx credits for a few seconds (causing other
WMI commands to timeout and return -EAGAIN/-11).
For HTT Tx this means NullFunc frames would get
stuck for a few seconds before completion was
received.

@Ben: Can you check if this helps you? I tested
this briefly and at least [1/4] seems fixes the
WMI Tx starvation. I'm hoping patches 2-4 help
with your ath10k_flush() failures which I haven't
been successfull in reproducing (but have observed
improvement with purging some frames out of FW/HW
queues).


Michal Kazior (4):
  ath10k: fix wmi-htc tx credit starvation
  ath10k: rework peer accounting
  ath10k: wait for mgmt tx when flushing too
  ath10k: improve tx flushing

 drivers/net/wireless/ath/ath10k/core.h |   7 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 254 +++++++++++++++++++++++++++++----
 drivers/net/wireless/ath/ath10k/txrx.c |  29 ++--
 drivers/net/wireless/ath/ath10k/wmi.c  |   5 -
 drivers/net/wireless/ath/ath10k/wmi.h  |   4 +
 5 files changed, 253 insertions(+), 46 deletions(-)

-- 
1.8.5.3



From michal.kazior at tieto.com  Fri Apr  4 07:37:43 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri,  4 Apr 2014 13:37:43 +0200
Subject: [RFT 3/4] ath10k: wait for mgmt tx when flushing too
In-Reply-To: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1396611464-5940-4-git-send-email-michal.kazior@tieto.com>

The 10.1 firmware uses WMI to Tx management frames
but ath10k_flush() didn't care. This could lead to
some frames not being sent.

Although there are no Tx completions for WMI
mangement frames it's still better to at least
wait for ath10k queue to be drained.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 9af3ed5..47b3574 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3766,19 +3766,27 @@ static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
 
 	mutex_lock(&ar->conf_mutex);
 
-	if (ar->state == ATH10K_STATE_WEDGED)
+	if (ar->state == ATH10K_STATE_WEDGED) {
+		ret = -EBUSY;
 		goto skip;
+	}
 
 	ret = wait_event_timeout(ar->htt.empty_tx_wq, ({
-			bool empty;
+			bool htt_empty, wmi_empty;
+			unsigned long flags;
 
 			spin_lock_bh(&ar->htt.tx_lock);
-			empty = (ar->htt.num_pending_tx == 0);
+			htt_empty = (ar->htt.num_pending_tx == 0);
 			spin_unlock_bh(&ar->htt.tx_lock);
 
+			spin_lock_irqsave(&ar->wmi_mgmt_tx_queue.lock, flags);
+			wmi_empty = skb_queue_len(&ar->wmi_mgmt_tx_queue) == 0;
+			spin_unlock_irqrestore(&ar->wmi_mgmt_tx_queue.lock,
+					       flags);
+
 			skip = (ar->state == ATH10K_STATE_WEDGED);
 
-			(empty || skip);
+			((htt_empty && wmi_empty) || skip);
 		}), ATH10K_FLUSH_TIMEOUT_HZ);
 
 	if (ret <= 0 || skip)
@@ -3787,6 +3795,11 @@ static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
 
 skip:
 	mutex_unlock(&ar->conf_mutex);
+
+	/* empty mgmt tx queue doesn't mean mgmt tx is flushed because the last
+	 * frame still may be processed by a worker */
+	if (ret > 0)
+		cancel_work_sync(&ar->wmi_mgmt_tx_work);
 }
 
 /* TODO: Implement this function properly
-- 
1.8.5.3



From michal.kazior at tieto.com  Fri Apr  4 07:37:41 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri,  4 Apr 2014 13:37:41 +0200
Subject: [RFT 1/4] ath10k: fix wmi-htc tx credit starvation
In-Reply-To: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1396611464-5940-2-git-send-email-michal.kazior@tieto.com>

Each WMI management Tx consumes 1 HTC Tx credit
and doesn't replenish it until the frame is
actually transmitted out of firmware's Tx queues.

If associated client was asleep and has gone out
of range then unicast frames won't be released for
FW/HW queues for a while (10 seconds per
observation). This means that if more management
frames are queued then HTC Tx credits are drained
to 0 and no other commands can be submitted
including beacons and peer removal.

This could in turn result in clients disconnecting
due to their beacon loss and may trigger spurious
sta kickouts because wmi peer removal command may
never reach firmware during disassociation.

This could happen, e.g. when disconnecting client
that has gone away while asleep.

As a workaround flush unicast management frames
that can possibly be buffered.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 80 +++++++++++++++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/wmi.c |  5 ---
 drivers/net/wireless/ath/ath10k/wmi.h |  3 ++
 3 files changed, 83 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 58ec5a7..25362ef 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2076,9 +2076,56 @@ void ath10k_mgmt_over_wmi_tx_purge(struct ath10k *ar)
 	}
 }
 
+static void ath10k_mgmt_tx_flush(struct ath10k *ar, struct sk_buff *skb)
+{
+	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
+	struct ath10k_vif *arvif = NULL, *arvif_iter;
+	u8 *da = ieee80211_get_DA(hdr);
+	u8 vdev_id = ATH10K_SKB_CB(skb)->vdev_id;
+	int ret;
+
+	if (!is_unicast_ether_addr(da))
+		return;
+
+	if (!ieee80211_is_disassoc(hdr->frame_control) &&
+	    !ieee80211_is_deauth(hdr->frame_control) &&
+	    !ieee80211_is_action(hdr->frame_control))
+		return;
+
+	mutex_lock(&ar->conf_mutex);
+	list_for_each_entry(arvif_iter, &ar->arvifs, list) {
+		if (arvif_iter->vdev_id == vdev_id) {
+			arvif = arvif_iter;
+			break;
+		}
+	}
+	mutex_unlock(&ar->conf_mutex);
+
+	if (!arvif)
+		return;
+
+	ath10k_dbg(ATH10K_DBG_MAC,
+		   "mac flushing peer %pM on vdev %i mgmt tid for unicast mgmt\n",
+		   da, vdev_id);
+
+	/*
+	 * Wait 2 beacon intervals before flushing so stations that are
+	 * asleep but are actually still in range have a chance to see
+	 * updated PVB, wake up and fetch the frame.
+	 */
+	msleep(2 * arvif->beacon_interval * 1024 / 1000);
+
+	ret = ath10k_wmi_peer_flush(ar, vdev_id, da,
+				    WMI_PEER_TID_MGMT_MASK);
+	if (ret)
+		ath10k_warn("failed to flush peer %pM mgmt tid: %d\n",
+			    da, ret);
+}
+
 void ath10k_mgmt_over_wmi_tx_work(struct work_struct *work)
 {
 	struct ath10k *ar = container_of(work, struct ath10k, wmi_mgmt_tx_work);
+	struct ieee80211_tx_info *info;
 	struct sk_buff *skb;
 	int ret;
 
@@ -2092,7 +2139,40 @@ void ath10k_mgmt_over_wmi_tx_work(struct work_struct *work)
 			ath10k_warn("failed to transmit management frame via WMI: %d\n",
 				    ret);
 			ieee80211_free_txskb(ar->hw, skb);
+			continue;
 		}
+
+		/*
+		 * Each WMI management Tx consumes 1 HTC Tx credit and doesn't
+		 * replenish it until the frame is actually transmitted out of
+		 * firmware's Tx queues.
+		 *
+		 * If associated client was asleep and has gone out of range
+		 * then unicast frames won't be released for FW/HW queues for a
+		 * while (10 seconds per observation). This means that if more
+		 * management frames are queued then HTC Tx credits are drained
+		 * to 0 and no other commands can be submitted including
+		 * beacons and peer removal.
+		 *
+		 * This could in turn result in clients disconnecting due to
+		 * their beacon loss and may trigger spurious sta kickouts
+		 * because wmi peer removal command may never reach firmware
+		 * during disassociation.
+		 *
+		 * This could happen, e.g. when disconnecting client that has
+		 * gone away while asleep.
+		 *
+		 * As a workaround flush unicast management frames that can
+		 * possibly be buffered.
+		 *
+		 * Note: This is a deficiency in design of WMI_MGMT_TX command.
+		 */
+		ath10k_mgmt_tx_flush(ar, skb);
+
+		/* there's no way to get ACK so just assume it's acked */
+		info = IEEE80211_SKB_CB(skb);
+		info->flags |= IEEE80211_TX_STAT_ACK;
+		ieee80211_tx_status(ar->hw, skb);
 	}
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index d4b48ef..3b270a4 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -637,7 +637,6 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 	struct wmi_mgmt_tx_cmd *cmd;
 	struct ieee80211_hdr *hdr;
 	struct sk_buff *wmi_skb;
-	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	int len;
 	u16 fc;
 
@@ -673,10 +672,6 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 	if (ret)
 		return ret;
 
-	/* TODO: report tx status to mac80211 - temporary just ACK */
-	info->flags |= IEEE80211_TX_STAT_ACK;
-	ieee80211_tx_status_irqsafe(ar->hw, skb);
-
 	return ret;
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index ae83822..90fe2e9 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -3844,6 +3844,9 @@ struct wmi_peer_delete_cmd {
 	struct wmi_mac_addr peer_macaddr;
 } __packed;
 
+#define WMI_PEER_TID_MGMT 17
+#define WMI_PEER_TID_MGMT_MASK BIT(WMI_PEER_TID_MGMT)
+
 struct wmi_peer_flush_tids_cmd {
 	__le32 vdev_id;
 	struct wmi_mac_addr peer_macaddr;
-- 
1.8.5.3



From michal.kazior at tieto.com  Fri Apr  4 07:37:44 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri,  4 Apr 2014 13:37:44 +0200
Subject: [RFT 4/4] ath10k: improve tx flushing
In-Reply-To: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1396611464-5940-5-git-send-email-michal.kazior@tieto.com>

Flushing was prone to timeouts when powersaving
clients were involved that went missing while
asleep. The common culprit was NullFunc frame
being stuck in FW/HW queues.

Introduce a two-pass flushing with WMI flush
commands interleaved to force frame drops if
necessary. This allows for a decreased flush
timeout time and should get rid of some warnings.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.h |  2 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 92 +++++++++++++++++++++++++++-------
 drivers/net/wireless/ath/ath10k/wmi.h  |  1 +
 3 files changed, 76 insertions(+), 19 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 61e325a..0d60e70 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -38,7 +38,7 @@
 
 #define ATH10K_SCAN_ID 0
 #define WMI_READY_TIMEOUT (5 * HZ)
-#define ATH10K_FLUSH_TIMEOUT_HZ (5*HZ)
+#define ATH10K_FLUSH_TIMEOUT_HZ (1*HZ)
 #define ATH10K_NUM_CHANS 38
 
 /* Antenna noise floor */
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 47b3574..77e1370 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3753,25 +3753,30 @@ static int ath10k_set_frag_threshold(struct ieee80211_hw *hw, u32 value)
 	return ret;
 }
 
-static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
+static int ath10k_flush_all_peer_tids(struct ath10k *ar)
 {
-	struct ath10k *ar = hw->priv;
-	bool skip;
+	struct ath10k_peer *peer;
 	int ret;
 
-	/* mac80211 doesn't care if we really xmit queued frames or not
-	 * we'll collect those frames either way if we stop/delete vdevs */
-	if (drop)
-		return;
-
-	mutex_lock(&ar->conf_mutex);
+	lockdep_assert_held(&ar->conf_mutex);
 
-	if (ar->state == ATH10K_STATE_WEDGED) {
-		ret = -EBUSY;
-		goto skip;
+	list_for_each_entry(peer, &ar->peers, list) {
+		ret = ath10k_wmi_peer_flush(ar, peer->vdev_id, peer->addr,
+					    WMI_PEER_TID_ALL_MASK);
+		if (ret) {
+			ath10k_warn("failed to request peer %pM on vdev %i to flush %08x: %d\n",
+				    peer->addr, peer->vdev_id, WMI_PEER_TID_ALL_MASK, ret);
+			return ret;
+		}
 	}
 
-	ret = wait_event_timeout(ar->htt.empty_tx_wq, ({
+	return 0;
+}
+
+static int ath10k_flush_wait(struct ath10k *ar)
+{
+	bool skip;
+	int ret = wait_event_timeout(ar->htt.empty_tx_wq, ({
 			bool htt_empty, wmi_empty;
 			unsigned long flags;
 
@@ -3789,16 +3794,67 @@ static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
 			((htt_empty && wmi_empty) || skip);
 		}), ATH10K_FLUSH_TIMEOUT_HZ);
 
-	if (ret <= 0 || skip)
-		ath10k_warn("failed to flush transmit queue (skip %i ar-state %i): %i\n",
-			    skip, ar->state, ret);
+	if (ret == 0)
+		ret = -ETIMEDOUT;
+	else if (ret > 0)
+		ret = 0;
+
+	if (skip) {
+		ath10k_warn("ignoring flushing result because hardware is wedged\n");
+		ret = -EBUSY;
+	}
+
+	return ret;
+}
+
+static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
+{
+	struct ath10k *ar = hw->priv;
+	int ret;
+
+	mutex_lock(&ar->conf_mutex);
+
+	if (drop) {
+		ret = ath10k_flush_all_peer_tids(ar);
+		if (ret) {
+			ath10k_warn("failed to flush all peer tids: %d\n", ret);
+			goto out;
+		}
+
+		goto out;
+	}
+
+	if (ar->state == ATH10K_STATE_WEDGED) {
+		ath10k_warn("skipping flushing because hardware is wedged\n");
+		ret = -EBUSY;
+		goto out;
+	}
+
+	ret = ath10k_flush_wait(ar);
+	if (ret) {
+		ath10k_dbg(ATH10K_DBG_MAC,
+			   "failed to wait for tx to flush: %d, forcing\n",
+			   ret);
+
+		ret = ath10k_flush_all_peer_tids(ar);
+		if (ret) {
+			ath10k_warn("failed to flush all peer tids: %d\n", ret);
+			goto out;
+		}
+
+		ret = ath10k_flush_wait(ar);
+		if (ret) {
+			ath10k_warn("failed to flush tx: %d\n", ret);
+			goto out;
+		}
+	}
 
-skip:
+out:
 	mutex_unlock(&ar->conf_mutex);
 
 	/* empty mgmt tx queue doesn't mean mgmt tx is flushed because the last
 	 * frame still may be processed by a worker */
-	if (ret > 0)
+	if (ret == 0)
 		cancel_work_sync(&ar->wmi_mgmt_tx_work);
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 90fe2e9..2b37c4a 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -3846,6 +3846,7 @@ struct wmi_peer_delete_cmd {
 
 #define WMI_PEER_TID_MGMT 17
 #define WMI_PEER_TID_MGMT_MASK BIT(WMI_PEER_TID_MGMT)
+#define WMI_PEER_TID_ALL_MASK 0xFFFFFFFF
 
 struct wmi_peer_flush_tids_cmd {
 	__le32 vdev_id;
-- 
1.8.5.3



From michal.kazior at tieto.com  Fri Apr  4 07:37:42 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri,  4 Apr 2014 13:37:42 +0200
Subject: [RFT 2/4] ath10k: rework peer accounting
In-Reply-To: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1396611464-5940-3-git-send-email-michal.kazior@tieto.com>

It was troublesome to iterate over peers within a
sleepable context (e.g. while holding conf_mutex).
This will be necessary for some upcomming changes
to tx flushing.

Making peer allocation and initial setup
ar->conf_mutex bound instead ar->data_lock solves
the problem.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.h |  5 +++
 drivers/net/wireless/ath/ath10k/mac.c  | 69 +++++++++++++++++++++++++++++++---
 drivers/net/wireless/ath/ath10k/txrx.c | 29 +++++++-------
 3 files changed, 81 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 8edd6da..61e325a 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -199,9 +199,14 @@ struct ath10k_dfs_stats {
 #define ATH10K_MAX_NUM_PEER_IDS (1 << 11) /* htt rx_desc limit */
 
 struct ath10k_peer {
+	/* protected by conf_mutex + data_lock */
 	struct list_head list;
+
+	/* protected by conf_mutex */
 	int vdev_id;
 	u8 addr[ETH_ALEN];
+
+	/* protected by data_lock */
 	DECLARE_BITMAP(peer_ids, ATH10K_MAX_NUM_PEER_IDS);
 	struct ieee80211_key_conf *keys[WMI_MAX_KEY_INDEX + 1];
 };
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 25362ef..9af3ed5 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -318,28 +318,61 @@ static u8 ath10k_parse_mpdudensity(u8 mpdudensity)
 
 static int ath10k_peer_create(struct ath10k *ar, u32 vdev_id, const u8 *addr)
 {
+	struct ath10k_peer *peer;
 	int ret;
 
 	lockdep_assert_held(&ar->conf_mutex);
 
+	peer = ath10k_peer_find(ar, vdev_id, addr);
+	if (peer) {
+		ath10k_warn("peer %pM on vdev %i already exists\n",
+			    addr, vdev_id);
+		return -EINVAL;
+	}
+
+	peer = kzalloc(sizeof(*peer), GFP_KERNEL);
+	if (!peer) {
+		ath10k_warn("failed to allocate peer %pM on vdev %i: not enough memory\n",
+			    addr, vdev_id);
+		return -ENOMEM;
+	}
+
+	peer->vdev_id = vdev_id;
+	memcpy(peer->addr, addr, ETH_ALEN);
+
+	spin_lock_bh(&ar->data_lock);
+	list_add(&peer->list, &ar->peers);
+	spin_unlock_bh(&ar->data_lock);
+
 	ret = ath10k_wmi_peer_create(ar, vdev_id, addr);
 	if (ret) {
 		ath10k_warn("failed to create wmi peer %pM on vdev %i: %i\n",
 			    addr, vdev_id, ret);
-		return ret;
+		goto err_free;
 	}
 
 	ret = ath10k_wait_for_peer_created(ar, vdev_id, addr);
 	if (ret) {
 		ath10k_warn("failed to wait for created wmi peer %pM on vdev %i: %i\n",
 			    addr, vdev_id, ret);
-		return ret;
+		goto err_free;
 	}
 	spin_lock_bh(&ar->data_lock);
 	ar->num_peers++;
 	spin_unlock_bh(&ar->data_lock);
 
 	return 0;
+
+err_free:
+	spin_lock_bh(&ar->data_lock);
+	list_del(&peer->list);
+	/* very unlikely, but check anyway */
+	if (!bitmap_empty(peer->peer_ids, ATH10K_MAX_NUM_PEER_IDS))
+		ath10k_warn("removing peer %pM on vdev %i still being mapped in firmware\n",
+			    addr, vdev_id);
+	spin_unlock_bh(&ar->data_lock);
+	kfree(peer);
+	return ret;
 }
 
 static int ath10k_mac_set_kickout(struct ath10k_vif *arvif)
@@ -416,22 +449,46 @@ static int ath10k_mac_set_frag(struct ath10k_vif *arvif, u32 value)
 
 static int ath10k_peer_delete(struct ath10k *ar, u32 vdev_id, const u8 *addr)
 {
+	struct ath10k_peer *peer;
 	int ret;
 
 	lockdep_assert_held(&ar->conf_mutex);
 
+	peer = ath10k_peer_find(ar, vdev_id, addr);
+	if (!peer) {
+		ath10k_warn("failed to lookup peer %pM on vdev %i\n",
+			    addr, vdev_id);
+		return -ENOENT;
+	}
+
 	ret = ath10k_wmi_peer_delete(ar, vdev_id, addr);
-	if (ret)
-		return ret;
+	if (ret) {
+		ath10k_warn("failed to request wmi peer %pM on vdev %i removal: %d\n",
+			    addr, vdev_id, ret);
+		goto out;
+	}
 
 	ret = ath10k_wait_for_peer_deleted(ar, vdev_id, addr);
-	if (ret)
-		return ret;
+	if (ret) {
+		ath10k_warn("failed to wait for wmi peer %pM on vdev %i removal: %d\n",
+			    addr, vdev_id, ret);
+		goto out;
+	}
 
 	spin_lock_bh(&ar->data_lock);
 	ar->num_peers--;
 	spin_unlock_bh(&ar->data_lock);
 
+out:
+	spin_lock_bh(&ar->data_lock);
+	list_del(&peer->list);
+	if (!bitmap_empty(peer->peer_ids, ATH10K_MAX_NUM_PEER_IDS))
+		ath10k_warn("removing peer %pM on vdev %i still being mapped in firmware\n",
+			    addr, vdev_id);
+	spin_unlock_bh(&ar->data_lock);
+
+	kfree(peer);
+
 	return 0;
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/txrx.c b/drivers/net/wireless/ath/ath10k/txrx.c
index 82669a7..d802569 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -100,13 +100,13 @@ exit:
 		wake_up(&htt->empty_tx_wq);
 }
 
+/* hold conf_mutex for simple iteration, or conf_mutex+data_lock for
+ * modifications */
 struct ath10k_peer *ath10k_peer_find(struct ath10k *ar, int vdev_id,
 				     const u8 *addr)
 {
 	struct ath10k_peer *peer;
 
-	lockdep_assert_held(&ar->data_lock);
-
 	list_for_each_entry(peer, &ar->peers, list) {
 		if (peer->vdev_id != vdev_id)
 			continue;
@@ -139,10 +139,14 @@ static int ath10k_wait_for_peer_common(struct ath10k *ar, int vdev_id,
 	int ret;
 
 	ret = wait_event_timeout(ar->peer_mapping_wq, ({
-			bool mapped;
+			struct ath10k_peer *peer;
+			bool mapped = false;
 
 			spin_lock_bh(&ar->data_lock);
-			mapped = !!ath10k_peer_find(ar, vdev_id, addr);
+			peer = ath10k_peer_find(ar, vdev_id, addr);
+			if (peer)
+				mapped = !bitmap_empty(peer->peer_ids,
+						       ATH10K_MAX_NUM_PEER_IDS);
 			spin_unlock_bh(&ar->data_lock);
 
 			mapped == expect_mapped;
@@ -173,20 +177,16 @@ void ath10k_peer_map_event(struct ath10k_htt *htt,
 	spin_lock_bh(&ar->data_lock);
 	peer = ath10k_peer_find(ar, ev->vdev_id, ev->addr);
 	if (!peer) {
-		peer = kzalloc(sizeof(*peer), GFP_ATOMIC);
-		if (!peer)
-			goto exit;
-
-		peer->vdev_id = ev->vdev_id;
-		memcpy(peer->addr, ev->addr, ETH_ALEN);
-		list_add(&peer->list, &ar->peers);
-		wake_up(&ar->peer_mapping_wq);
+		ath10k_warn("failed to map peer %pM on vdev %i: no such entry\n",
+			    ev->addr, ev->vdev_id);
+		goto exit;
 	}
 
 	ath10k_dbg(ATH10K_DBG_HTT, "htt peer map vdev %d peer %pM id %d\n",
 		   ev->vdev_id, ev->addr, ev->peer_id);
 
 	set_bit(ev->peer_id, peer->peer_ids);
+	wake_up(&ar->peer_mapping_wq);
 exit:
 	spin_unlock_bh(&ar->data_lock);
 }
@@ -210,11 +210,8 @@ void ath10k_peer_unmap_event(struct ath10k_htt *htt,
 
 	clear_bit(ev->peer_id, peer->peer_ids);
 
-	if (bitmap_empty(peer->peer_ids, ATH10K_MAX_NUM_PEER_IDS)) {
-		list_del(&peer->list);
-		kfree(peer);
+	if (bitmap_empty(peer->peer_ids, ATH10K_MAX_NUM_PEER_IDS))
 		wake_up(&ar->peer_mapping_wq);
-	}
 
 exit:
 	spin_unlock_bh(&ar->data_lock);
-- 
1.8.5.3



From greearb at candelatech.com  Fri Apr  4 10:49:42 2014
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 04 Apr 2014 07:49:42 -0700
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <533EC686.40505@candelatech.com>

On 04/04/2014 04:37 AM, Michal Kazior wrote:
> Hi,
>
> After digging around I've found what seems to be
> the problem with WMI Tx credit starvation and
> inability to properly flush Tx in ath10k_flush().
>
> Long story short: if a client that was asleep (as
> per what firmware thinks) goes out of range (or
> just stops responding) then Tx rots in FW/HW
> queues for a few seconds before it's discarded.
> For WMI Tx credits this means management frames
> eat up Tx credits for a few seconds (causing other
> WMI commands to timeout and return -EAGAIN/-11).
> For HTT Tx this means NullFunc frames would get
> stuck for a few seconds before completion was
> received.
>
> @Ben: Can you check if this helps you? I tested
> this briefly and at least [1/4] seems fixes the
> WMI Tx starvation. I'm hoping patches 2-4 help
> with your ath10k_flush() failures which I haven't
> been successfull in reproducing (but have observed
> improvement with purging some frames out of FW/HW
> queues).

I'm out of office for a bit, but will test this as
soon as I'm back.

Thanks for looking into this!

In general, would it make more sense to have a few more tx credits
available to mitigate the slow-to-be-processed buffers?

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From dave.taht at gmail.com  Fri Apr  4 14:31:09 2014
From: dave.taht at gmail.com (Dave Taht)
Date: Fri, 4 Apr 2014 11:31:09 -0700
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <533EC686.40505@candelatech.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <533EC686.40505@candelatech.com>
Message-ID: <CAA93jw5DfY=y1b=HsDPi6zsKDSDg35+YcHJetn_XYXgWD120WQ@mail.gmail.com>

On Fri, Apr 4, 2014 at 7:49 AM, Ben Greear <greearb at candelatech.com> wrote:
> On 04/04/2014 04:37 AM, Michal Kazior wrote:
>>
>> Hi,
>>
>> After digging around I've found what seems to be
>> the problem with WMI Tx credit starvation and
>> inability to properly flush Tx in ath10k_flush().
>>
>> Long story short: if a client that was asleep (as
>> per what firmware thinks) goes out of range (or
>> just stops responding) then Tx rots in FW/HW
>> queues for a few seconds before it's discarded.
>> For WMI Tx credits this means management frames
>> eat up Tx credits for a few seconds (causing other
>> WMI commands to timeout and return -EAGAIN/-11).
>> For HTT Tx this means NullFunc frames would get
>> stuck for a few seconds before completion was
>> received.
>>
>> @Ben: Can you check if this helps you? I tested
>> this briefly and at least [1/4] seems fixes the
>> WMI Tx starvation. I'm hoping patches 2-4 help
>> with your ath10k_flush() failures which I haven't
>> been successfull in reproducing (but have observed
>> improvement with purging some frames out of FW/HW
>> queues).
>
>
> I'm out of office for a bit, but will test this as
> soon as I'm back.
>
> Thanks for looking into this!
>
> In general, would it make more sense to have a few more tx credits
> available to mitigate the slow-to-be-processed buffers?

It would help more to organize the queueing so that there is no head
of line per sta blocking, smarter (interleaved) per station retries,
and sane packet drops and congestion notifications delivered sooner -
certainly dropping packets after 250ms of delay, and preferably much,
much less when a client is not in sleep mode....

To preach:

https://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-00

https://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel/

http://www.bufferbloat.net/projects/cerowrt/wiki/Fq_Codel_on_Wireless


>
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k



-- 
Dave T?ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html


From kvalo at qca.qualcomm.com  Sat Apr  5 02:17:39 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Sat, 5 Apr 2014 09:17:39 +0300
Subject: [PATCH 1/1] ath10k:  add helper method to grab debug stats.
In-Reply-To: <533C256B.9090209@candelatech.com> (Ben Greear's message of "Wed, 
 02 Apr 2014 07:57:47 -0700")
References: <1396374940-21453-1-git-send-email-greearb@candelatech.com>
 <8738hwrxso.fsf@kamboji.qca.qualcomm.com>
 <533C256B.9090209@candelatech.com>
Message-ID: <87bnwgpaf0.fsf@kamboji.qca.qualcomm.com>

Ben Greear <greearb at candelatech.com> writes:

> On 04/02/2014 12:32 AM, Kalle Valo wrote:
>> greearb at candelatech.com writes:
>>
>>> From: Ben Greear <greearb at candelatech.com>
>>>
>>> It can be nice to update the firmware's stats while
>>> debugging other bits of the driver, so add helper method
>>> to do this.
>>>
>>> Signed-off-by: Ben Greear <greearb at candelatech.com>
>>
>> [...]
>>
>>> --- a/drivers/net/wireless/ath/ath10k/debug.h
>>> +++ b/drivers/net/wireless/ath/ath10k/debug.h
>>> @@ -135,4 +135,6 @@ struct dbglog_hdr_s {
>>>
>>>   void ath10k_dbg_print_fw_dbg_buffer(u8 *buffer, int len, const char* lvl);
>>>
>>> +int ath10k_refresh_peer_stats(struct ath10k *ar);
>>
>> I don't see anyone calling this. How are you planning to use it?
>
> The RFC patch that debugs tx-hang calls it..nice to see he firmware's
> buffer reap stats and such before/after trying to flush the buffers.
>
> I figure it will be useful for other such uses as well, now that stats
> actually work.

Ok, I'll drop this patch for now. You can resend when we have callers
for this.

-- 
Kalle Valo


From greearb at candelatech.com  Sun Apr  6 20:30:33 2014
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 06 Apr 2014 17:30:33 -0700
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <5341F1A9.2030202@candelatech.com>

On 04/04/2014 04:37 AM, Michal Kazior wrote:
> Hi,
>
> After digging around I've found what seems to be
> the problem with WMI Tx credit starvation and
> inability to properly flush Tx in ath10k_flush().

I applied all four, rebooted AP and Station machine with the
new kernel (3.14.0-wl-ath+).  I had removed my own tx-hang detection
hack.

It is not working well...though perhaps it is not directly related
to your patches...I will do some reboots and try reversing some patches.
But, 3.14.0-rc8-wl-ath+ was working mostly OK for me....

It seems my user-space app got hung, probably because rtnl was being
held too long while doing admin-down on a bunch of stations.

Out of 32 stations, maybe 5 of them managed to come up and get
an IP address through DHCP before user-space app hung and log
started filling with the errors at the end of the dmesg below.


sta218: associated
IPv6: ADDRCONF(NETDEV_CHANGE): sta218: link becomes ready
sta219: authenticate with 04:f0:21:03:38:99
ath10k: mac vdev 19 beacon_interval 100
ath10k: mac vdev 19 create peer 04:f0:21:03:38:99
ath10k: mac vdev 19 start 04:f0:21:03:38:99
ath10k: mac vdev 19 start center_freq 5180 phymode 11ac-vht80

sta219: send auth to 04:f0:21:03:38:99 (try 1/3)
sta219: authenticated
sta218: deauthenticating from 04:f0:21:03:38:99 by local choice (Reason: 3=DEAUTH_LEAVING)
ath10k: mac flushing peer 04:f0:21:03:38:99 on vdev 18 mgmt tid for unicast mgmt
ath10k: mac vdev 18 peer delete 04:f0:21:03:38:99 (sta gone)
ath10k: mac vdev 18 stop (disassociated
ath10k: mac vdev 18 down
ath10k: mac vdev 18 cts_prot 0
ath10k: mac vdev 18 slot_time 1
ath10k: mac vdev 18 preamble 1n
sta219: associate with 04:f0:21:03:38:99 (try 1/3)
sta219: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=22)
ath10k: mac vdev 19 dtim_period 2
ath10k: mac vdev 19 slot_time 2
ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
ath10k: mac vdev 19 up (associated) bssid 04:f0:21:03:38:99 aid 22
sta219: associated
IPv6: ADDRCONF(NETDEV_CHANGE): sta219: link becomes ready
sta220: authenticate with 04:f0:21:03:38:99
ath10k: mac vdev 20 beacon_interval 100
ath10k: mac vdev 20 create peer 04:f0:21:03:38:99
ath10k: mac vdev 20 start 04:f0:21:03:38:99
ath10k: mac vdev 20 start center_freq 5180 phymode 11ac-vht80
sta220: send auth to 04:f0:21:03:38:99 (try 1/3)
sta220: authenticated
sta220: associate with 04:f0:21:03:38:99 (try 1/3)
sta220: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=23)
ath10k: mac vdev 20 dtim_period 2
ath10k: mac vdev 20 slot_time 2
ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
ath10k: mac vdev 20 up (associated) bssid 04:f0:21:03:38:99 aid 23
sta220: associated
IPv6: ADDRCONF(NETDEV_CHANGE): sta220: link becomes ready
ath10k: Creating vdev id: 21  map: 4292870144
ath10k: mac vdev create 21 (add interface) type 2 subtype 0
ath10k: mac vdev 21 cts_prot 0
ath10k: mac vdev 21 slot_time 1
ath10k: mac vdev 21 preamble 1n
IPv6: ADDRCONF(NETDEV_UP): sta221: link is not ready
ath10k: mac vdev 21 delete (remove interface)
ath10k: peer-unmap-event: unknown peer id 23
ath10k: Creating vdev id: 21  map: 4292870144
ath10k: mac vdev create 21 (add interface) type 2 subtype 0
ath10k: mac vdev 21 cts_prot 0
ath10k: mac vdev 21 slot_time 1
ath10k: mac vdev 21 preamble 1n
IPv6: ADDRCONF(NETDEV_UP): sta221: link is not ready
sta217: authenticate with 04:f0:21:03:38:99
ath10k: mac vdev 17 beacon_interval 100
ath10k: mac vdev 17 create peer 04:f0:21:03:38:99
ath10k: mac vdev 17 start 04:f0:21:03:38:99
ath10k: mac vdev 17 start center_freq 5180 phymode 11ac-vht80

sta217: send auth to 04:f0:21:03:38:99 (try 1/3)
sta217: authenticated
sta217: associate with 04:f0:21:03:38:99 (try 1/3)
sta217: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=20)
ath10k: mac vdev 17 dtim_period 2
ath10k: mac vdev 17 slot_time 2
ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
ath10k: mac vdev 17 up (associated) bssid 04:f0:21:03:38:99 aid 20
sta217: associated
IPv6: ADDRCONF(NETDEV_CHANGE): sta217: link becomes ready
sta218: authenticate with 04:f0:21:03:38:99
ath10k: mac vdev 18 beacon_interval 100
ath10k: mac vdev 18 create peer 04:f0:21:03:38:99
ath10k: mac vdev 18 start 04:f0:21:03:38:99
ath10k: mac vdev 18 start center_freq 5180 phymode 11ac-vht80
sta218: send auth to 04:f0:21:03:38:99 (try 1/3)
ath10k: Creating vdev id: 22  map: 4290772992
ath10k: mac vdev create 22 (add interface) type 2 subtype 0
sta218: authenticated
ath10k: mac vdev 22 cts_prot 0
ath10k: mac vdev 22 slot_time 1
ath10k: mac vdev 22 preamble 1n
IPv6: ADDRCONF(NETDEV_UP): sta222: link is not ready
sta218: associate with 04:f0:21:03:38:99 (try 1/3)
sta218: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=18)
ath10k: mac vdev 18 dtim_period 2
ath10k: mac vdev 18 slot_time 2
ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
ath10k: mac vdev 18 up (associated) bssid 04:f0:21:03:38:99 aid 18
sta218: associated
sta222: authenticate with 04:f0:21:03:38:99
ath10k: mac vdev 22 beacon_interval 100
ath10k: mac vdev 22 create peer 04:f0:21:03:38:99
ath10k: mac vdev 22 start 04:f0:21:03:38:99
ath10k: mac vdev 22 start center_freq 5180 phymode 11ac-vht80

sta222: send auth to 04:f0:21:03:38:99 (try 1/3)
ath10k: mac vdev 22 peer delete 04:f0:21:03:38:99 (sta gone)
ath10k: mac vdev 22 stop (disassociated
ath10k: mac vdev 22 down
ath10k: mac vdev 22 delete (remove interface)
ath10k: peer-unmap-event: unknown peer id 24
ath10k: Creating vdev id: 22  map: 4290772992
ath10k: mac vdev create 22 (add interface) type 2 subtype 0
ath10k: mac vdev 22 cts_prot 0
ath10k: mac vdev 22 slot_time 1
ath10k: mac vdev 22 preamble 1n
IPv6: ADDRCONF(NETDEV_UP): sta222: link is not ready
sta221: authenticate with 04:f0:21:03:38:99
ath10k: mac vdev 21 beacon_interval 100
ath10k: mac vdev 21 create peer 04:f0:21:03:38:99
ath10k: mac vdev 21 start 04:f0:21:03:38:99
ath10k: mac vdev 21 start center_freq 5180 phymode 11ac-vht80

sta221: send auth to 04:f0:21:03:38:99 (try 1/3)
sta221: authenticated
sta221: associate with 04:f0:21:03:38:99 (try 1/3)
sta221: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=19)
ath10k: mac vdev 21 dtim_period 2
ath10k: mac vdev 21 slot_time 2
ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
ath10k: mac vdev 21 up (associated) bssid 04:f0:21:03:38:99 aid 19
sta221: associated
IPv6: ADDRCONF(NETDEV_CHANGE): sta221: link becomes ready
sta222: authenticate with 04:f0:21:03:38:99
ath10k: mac vdev 22 beacon_interval 100
ath10k: mac vdev 22 create peer 04:f0:21:03:38:99
ath10k: mac vdev 22 start 04:f0:21:03:38:99
ath10k: mac vdev 22 start center_freq 5180 phymode 11ac-vht80
sta222: send auth to 04:f0:21:03:38:99 (try 1/3)
sta222: authenticated
sta222: associate with 04:f0:21:03:38:99 (try 1/3)
sta222: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=24)
ath10k: mac vdev 22 dtim_period 2
ath10k: mac vdev 22 slot_time 2
ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
ath10k: mac vdev 22 up (associated) bssid 04:f0:21:03:38:99 aid 24
sta222: associated
IPv6: ADDRCONF(NETDEV_CHANGE): sta222: link becomes ready

sta213: deauthenticating from 04:f0:21:03:38:99 by local choice (Reason: 3=DEAUTH_LEAVING)
ath10k: mac flushing peer 04:f0:21:03:38:99 on vdev 13 mgmt tid for unicast mgmt
ath10k: mac vdev 13 peer delete 04:f0:21:03:38:99 (sta gone)
ath10k: mac vdev 13 stop (disassociated
ath10k: mac vdev 13 down
ath10k: mac vdev 13 cts_prot 0
ath10k: mac vdev 13 slot_time 1

ath10k: failed to set erp slot for vdev 13: -11
ath10k: mac vdev 13 preamble 1n
ath10k: failed to set preamble for vdev 13: -11
ath10k: failed to set wmm params: -11
ath10k: failed to set wmm params: -11
ath10k: failed to set wmm params: -11
ath10k: failed to set wmm params: -11
ath10k: mac vdev 13 delete (remove interface)
ath10k: failed to delete WMI vdev 13: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
sta219: deauthenticating from 04:f0:21:03:38:99 by local choice (Reason: 3=DEAUTH_LEAVING)
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: mac vdev 19 peer delete 04:f0:21:03:38:99 (sta gone)
ath10k: failed to request wmi peer 04:f0:21:03:38:99 on vdev 19 removal: -11
ath10k: removing peer 04:f0:21:03:38:99 on vdev 19 still being mapped in firmware
ath10k: mac vdev 19 stop (disassociated
ath10k: failed to stop WMI vdev 19: -11
ath10k: mac vdev 19 down
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: mac vdev 19 cts_prot 0
ath10k: failed to recalculate rts/cts prot for vdev 19: -11
ath10k: mac vdev 19 slot_time 1
ath10k: failed to set erp slot for vdev 19: -11
ath10k: mac vdev 19 preamble 1n
ath10k: failed to set preamble for vdev 19: -11
ath10k: failed to set wmm params: -11
ath10k: failed to set wmm params: -11
ath10k: failed to set wmm params: -11
ath10k: failed to set wmm params: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: mac vdev 19 delete (remove interface)
ath10k: failed to delete WMI vdev 19: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 22 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: mac vdev 0 peer delete 04:f0:21:03:38:99 (sta gone)
ath10k: failed to request wmi peer 04:f0:21:03:38:99 on vdev 0 removal: -11
ath10k: removing peer 04:f0:21:03:38:99 on vdev 0 still being mapped in firmware
ath10k: mac vdev 0 stop (disassociated
ath10k: failed to stop WMI vdev 0: -11
ath10k: mac vdev 0 down
ath10k: mac vdev 0 cts_prot 0
ath10k: failed to recalculate rts/cts prot for vdev 0: -11
ath10k: mac vdev 0 slot_time 1
ath10k: failed to set erp slot for vdev 0: -11
ath10k: mac vdev 0 preamble 1n
ath10k: failed to set preamble for vdev 0: -11
ath10k: failed to set wmm params: -11

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Sun Apr  6 21:05:20 2014
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 06 Apr 2014 18:05:20 -0700
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <5341F1A9.2030202@candelatech.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <5341F1A9.2030202@candelatech.com>
Message-ID: <5341F9D0.2090808@candelatech.com>

On 04/06/2014 05:30 PM, Ben Greear wrote:
> On 04/04/2014 04:37 AM, Michal Kazior wrote:
>> Hi,
>>
>> After digging around I've found what seems to be
>> the problem with WMI Tx credit starvation and
>> inability to properly flush Tx in ath10k_flush().
>
> I applied all four, rebooted AP and Station machine with the
> new kernel (3.14.0-wl-ath+).  I had removed my own tx-hang detection
> hack.

Looks like the problems start with patch 3/4.

All tests were done with all 4 patches applied on the AP machine,
and it appears that works fine.  The station machine worked fine with
the first two patches, but when third was applied, only a few stations
come up and I get behaviour similar to that described in the first email,
but I do not see anything obviously wrong in dmesg...

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From michal.kazior at tieto.com  Mon Apr  7 05:06:55 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 7 Apr 2014 11:06:55 +0200
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <533EC686.40505@candelatech.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <533EC686.40505@candelatech.com>
Message-ID: <CA+BoTQknr=Rh6izDWpsDTQM-8i=NJQA1nJomCcugD81pRPeXBw@mail.gmail.com>

On 4 April 2014 16:49, Ben Greear <greearb at candelatech.com> wrote:
> On 04/04/2014 04:37 AM, Michal Kazior wrote:
>>
>> Hi,
>>
>> After digging around I've found what seems to be
>> the problem with WMI Tx credit starvation and
>> inability to properly flush Tx in ath10k_flush().
>>
>> Long story short: if a client that was asleep (as
>> per what firmware thinks) goes out of range (or
>> just stops responding) then Tx rots in FW/HW
>> queues for a few seconds before it's discarded.
>> For WMI Tx credits this means management frames
>> eat up Tx credits for a few seconds (causing other
>> WMI commands to timeout and return -EAGAIN/-11).
>> For HTT Tx this means NullFunc frames would get
>> stuck for a few seconds before completion was
>> received.
>>
>> @Ben: Can you check if this helps you? I tested
>> this briefly and at least [1/4] seems fixes the
>> WMI Tx starvation. I'm hoping patches 2-4 help
>> with your ath10k_flush() failures which I haven't
>> been successfull in reproducing (but have observed
>> improvement with purging some frames out of FW/HW
>> queues).
>
>
> I'm out of office for a bit, but will test this as
> soon as I'm back.
>
> Thanks for looking into this!
>
> In general, would it make more sense to have a few more tx credits
> available to mitigate the slow-to-be-processed buffers?

Sure, we can disregard firmware telling us we have only 2 credits and
submit commands as we see fit. We can probably even get away with it
as long as we don't submit more than 2 WMI_MGMT_TX_CMDID commands
because it seems this is the only resource consuming command (requires
firmware to copy frame, keep it allocated and mapped for HW until
released on air). Beacons are already sent by reference. But I don't
think this is the solution.

The problem is there's no tx completion indication for
WMI_MGMT_TX_CMDID and you can't rely on tx credits replenishment for
that because (as per my observation) you have to submit an even number
of WMI_MGMT_TX_CMDID to get tx credits replenished. This means there's
no way of doing an educated timeout/flushing. This also means you can
get stuck with 2 credits and 2 frames being stuck in FW if destination
peer is unresponsive for up to 10 seconds.

Once you get stuck you can get a cascade of errors because WMI
commands time out after 3 seconds and if you're running AP you stop
beaconing because you can't even submit WMI_BCN_TX_CMDID.

Another way would be to prolong WMI command timeout to ~11 seconds...
at least for the "tx credits being stuck" problem.


Micha?


From michal.kazior at tieto.com  Mon Apr  7 05:11:09 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 7 Apr 2014 11:11:09 +0200
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <5341F1A9.2030202@candelatech.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <5341F1A9.2030202@candelatech.com>
Message-ID: <CA+BoTQndgEB7X-RUPPkxdjnp96LJzbv6=Q9K4XTTrky-QwE4Ww@mail.gmail.com>

On 7 April 2014 02:30, Ben Greear <greearb at candelatech.com> wrote:
> On 04/04/2014 04:37 AM, Michal Kazior wrote:
>>
>> Hi,
>>
>> After digging around I've found what seems to be
>> the problem with WMI Tx credit starvation and
>> inability to properly flush Tx in ath10k_flush().
>
>
> I applied all four, rebooted AP and Station machine with the
> new kernel (3.14.0-wl-ath+).  I had removed my own tx-hang detection
> hack.
>
> It is not working well...though perhaps it is not directly related
> to your patches...I will do some reboots and try reversing some patches.
> But, 3.14.0-rc8-wl-ath+ was working mostly OK for me....
>
> It seems my user-space app got hung, probably because rtnl was being
> held too long while doing admin-down on a bunch of stations.
>
> Out of 32 stations, maybe 5 of them managed to come up and get
> an IP address through DHCP before user-space app hung and log
> started filling with the errors at the end of the dmesg below.
>
>
> sta218: associated
> IPv6: ADDRCONF(NETDEV_CHANGE): sta218: link becomes ready
> sta219: authenticate with 04:f0:21:03:38:99
> ath10k: mac vdev 19 beacon_interval 100
> ath10k: mac vdev 19 create peer 04:f0:21:03:38:99
> ath10k: mac vdev 19 start 04:f0:21:03:38:99
> ath10k: mac vdev 19 start center_freq 5180 phymode 11ac-vht80
>
> sta219: send auth to 04:f0:21:03:38:99 (try 1/3)
> sta219: authenticated
> sta218: deauthenticating from 04:f0:21:03:38:99 by local choice (Reason:
> 3=DEAUTH_LEAVING)
> ath10k: mac flushing peer 04:f0:21:03:38:99 on vdev 18 mgmt tid for unicast
> mgmt
> ath10k: mac vdev 18 peer delete 04:f0:21:03:38:99 (sta gone)
> ath10k: mac vdev 18 stop (disassociated
> ath10k: mac vdev 18 down
> ath10k: mac vdev 18 cts_prot 0
> ath10k: mac vdev 18 slot_time 1
> ath10k: mac vdev 18 preamble 1n
> sta219: associate with 04:f0:21:03:38:99 (try 1/3)
> sta219: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=22)
> ath10k: mac vdev 19 dtim_period 2
> ath10k: mac vdev 19 slot_time 2
> ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
> ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
> ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
> ath10k: mac vdev 19 up (associated) bssid 04:f0:21:03:38:99 aid 22
> sta219: associated
> IPv6: ADDRCONF(NETDEV_CHANGE): sta219: link becomes ready
> sta220: authenticate with 04:f0:21:03:38:99
> ath10k: mac vdev 20 beacon_interval 100
> ath10k: mac vdev 20 create peer 04:f0:21:03:38:99
> ath10k: mac vdev 20 start 04:f0:21:03:38:99
> ath10k: mac vdev 20 start center_freq 5180 phymode 11ac-vht80
> sta220: send auth to 04:f0:21:03:38:99 (try 1/3)
> sta220: authenticated
> sta220: associate with 04:f0:21:03:38:99 (try 1/3)
> sta220: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=23)
> ath10k: mac vdev 20 dtim_period 2
> ath10k: mac vdev 20 slot_time 2
> ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
> ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
> ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
> ath10k: mac vdev 20 up (associated) bssid 04:f0:21:03:38:99 aid 23
> sta220: associated
> IPv6: ADDRCONF(NETDEV_CHANGE): sta220: link becomes ready
> ath10k: Creating vdev id: 21  map: 4292870144
> ath10k: mac vdev create 21 (add interface) type 2 subtype 0
> ath10k: mac vdev 21 cts_prot 0
> ath10k: mac vdev 21 slot_time 1
> ath10k: mac vdev 21 preamble 1n
> IPv6: ADDRCONF(NETDEV_UP): sta221: link is not ready
> ath10k: mac vdev 21 delete (remove interface)
> ath10k: peer-unmap-event: unknown peer id 23
> ath10k: Creating vdev id: 21  map: 4292870144
> ath10k: mac vdev create 21 (add interface) type 2 subtype 0
> ath10k: mac vdev 21 cts_prot 0
> ath10k: mac vdev 21 slot_time 1
> ath10k: mac vdev 21 preamble 1n
> IPv6: ADDRCONF(NETDEV_UP): sta221: link is not ready
> sta217: authenticate with 04:f0:21:03:38:99
> ath10k: mac vdev 17 beacon_interval 100
> ath10k: mac vdev 17 create peer 04:f0:21:03:38:99
> ath10k: mac vdev 17 start 04:f0:21:03:38:99
> ath10k: mac vdev 17 start center_freq 5180 phymode 11ac-vht80
>
> sta217: send auth to 04:f0:21:03:38:99 (try 1/3)
> sta217: authenticated
> sta217: associate with 04:f0:21:03:38:99 (try 1/3)
> sta217: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=20)
> ath10k: mac vdev 17 dtim_period 2
> ath10k: mac vdev 17 slot_time 2
> ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
> ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
> ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
> ath10k: mac vdev 17 up (associated) bssid 04:f0:21:03:38:99 aid 20
> sta217: associated
> IPv6: ADDRCONF(NETDEV_CHANGE): sta217: link becomes ready
> sta218: authenticate with 04:f0:21:03:38:99
> ath10k: mac vdev 18 beacon_interval 100
> ath10k: mac vdev 18 create peer 04:f0:21:03:38:99
> ath10k: mac vdev 18 start 04:f0:21:03:38:99
> ath10k: mac vdev 18 start center_freq 5180 phymode 11ac-vht80
> sta218: send auth to 04:f0:21:03:38:99 (try 1/3)
> ath10k: Creating vdev id: 22  map: 4290772992
> ath10k: mac vdev create 22 (add interface) type 2 subtype 0
> sta218: authenticated
> ath10k: mac vdev 22 cts_prot 0
> ath10k: mac vdev 22 slot_time 1
> ath10k: mac vdev 22 preamble 1n
> IPv6: ADDRCONF(NETDEV_UP): sta222: link is not ready
> sta218: associate with 04:f0:21:03:38:99 (try 1/3)
> sta218: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=18)
> ath10k: mac vdev 18 dtim_period 2
> ath10k: mac vdev 18 slot_time 2
> ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
> ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
> ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
> ath10k: mac vdev 18 up (associated) bssid 04:f0:21:03:38:99 aid 18
> sta218: associated
> sta222: authenticate with 04:f0:21:03:38:99
> ath10k: mac vdev 22 beacon_interval 100
> ath10k: mac vdev 22 create peer 04:f0:21:03:38:99
> ath10k: mac vdev 22 start 04:f0:21:03:38:99
> ath10k: mac vdev 22 start center_freq 5180 phymode 11ac-vht80
>
> sta222: send auth to 04:f0:21:03:38:99 (try 1/3)
> ath10k: mac vdev 22 peer delete 04:f0:21:03:38:99 (sta gone)
> ath10k: mac vdev 22 stop (disassociated
> ath10k: mac vdev 22 down
> ath10k: mac vdev 22 delete (remove interface)
> ath10k: peer-unmap-event: unknown peer id 24
> ath10k: Creating vdev id: 22  map: 4290772992
> ath10k: mac vdev create 22 (add interface) type 2 subtype 0
> ath10k: mac vdev 22 cts_prot 0
> ath10k: mac vdev 22 slot_time 1
> ath10k: mac vdev 22 preamble 1n
> IPv6: ADDRCONF(NETDEV_UP): sta222: link is not ready
> sta221: authenticate with 04:f0:21:03:38:99
> ath10k: mac vdev 21 beacon_interval 100
> ath10k: mac vdev 21 create peer 04:f0:21:03:38:99
> ath10k: mac vdev 21 start 04:f0:21:03:38:99
> ath10k: mac vdev 21 start center_freq 5180 phymode 11ac-vht80
>
> sta221: send auth to 04:f0:21:03:38:99 (try 1/3)
> sta221: authenticated
> sta221: associate with 04:f0:21:03:38:99 (try 1/3)
> sta221: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=19)
> ath10k: mac vdev 21 dtim_period 2
> ath10k: mac vdev 21 slot_time 2
> ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
> ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
> ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
> ath10k: mac vdev 21 up (associated) bssid 04:f0:21:03:38:99 aid 19
> sta221: associated
> IPv6: ADDRCONF(NETDEV_CHANGE): sta221: link becomes ready
> sta222: authenticate with 04:f0:21:03:38:99
> ath10k: mac vdev 22 beacon_interval 100
> ath10k: mac vdev 22 create peer 04:f0:21:03:38:99
> ath10k: mac vdev 22 start 04:f0:21:03:38:99
> ath10k: mac vdev 22 start center_freq 5180 phymode 11ac-vht80
> sta222: send auth to 04:f0:21:03:38:99 (try 1/3)
> sta222: authenticated
> sta222: associate with 04:f0:21:03:38:99 (try 1/3)
> sta222: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=24)
> ath10k: mac vdev 22 dtim_period 2
> ath10k: mac vdev 22 slot_time 2
> ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
> ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
> ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
> ath10k: mac vdev 22 up (associated) bssid 04:f0:21:03:38:99 aid 24
> sta222: associated
> IPv6: ADDRCONF(NETDEV_CHANGE): sta222: link becomes ready
>
> sta213: deauthenticating from 04:f0:21:03:38:99 by local choice (Reason:
> 3=DEAUTH_LEAVING)
> ath10k: mac flushing peer 04:f0:21:03:38:99 on vdev 13 mgmt tid for unicast
> mgmt
> ath10k: mac vdev 13 peer delete 04:f0:21:03:38:99 (sta gone)
> ath10k: mac vdev 13 stop (disassociated
> ath10k: mac vdev 13 down
> ath10k: mac vdev 13 cts_prot 0
> ath10k: mac vdev 13 slot_time 1
>
> ath10k: failed to set erp slot for vdev 13: -11
> ath10k: mac vdev 13 preamble 1n
> ath10k: failed to set preamble for vdev 13: -11
> ath10k: failed to set wmm params: -11
> ath10k: failed to set wmm params: -11

These logs are not enough. I'd love to see traces for this to see what
frames are actually submitted and when tx credits are replenished.

I also wonder if this can be somehow related to your FW changes to
allow connecting multiple client virtual interfaces to a single AP?


Micha?


From kvalo at qca.qualcomm.com  Mon Apr  7 09:52:26 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Mon, 7 Apr 2014 16:52:26 +0300
Subject: [PATCH v2 1/2] ath10k: reorder functions
In-Reply-To: <1396610926-5787-2-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 4 Apr 2014 13:28:45 +0200")
References: <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-2-git-send-email-michal.kazior@tieto.com>
Message-ID: <87fvlpnt5x.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> This is done to avoid forward declarations with
> upcomming patches.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Like you said, I had a conflict with this patch. Can you double check my
resolution, please:

https://github.com/kvalo/ath/commit/0953accf20c325adde537a57c3e6a6a0f1ff04d7

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Mon Apr  7 10:04:39 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Mon, 7 Apr 2014 17:04:39 +0300
Subject: [PATCH v2 2/2] ath10k: refactor radar detection code
In-Reply-To: <1396610926-5787-3-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 4 Apr 2014 13:28:46 +0200")
References: <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-3-git-send-email-michal.kazior@tieto.com>
Message-ID: <87bnwdnslk.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> If 20MHz CAC completed successfully then
> subsequent CAC with wider bandwidth (40Mhz, 80Mhz)
> with identical control frequency did not start
> monitor vdev making it impossible to detect any
> radar pulses during intended CAC.
>
> It also was incorrect to assume ath10k_config() will
> be called after CAC is finished. Theoretically for
> non-HT channels nothing changes between CAC and
> start_ap() (albeit in practice this can be
> different). The incorrect assumption led to CAC
> not being stopped on non-HT chandefs leading to
> all Rx being drooped making it impossible for
> clients to associate.
>
> While at it clean up the code a bit.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

[...]

> @@ -858,6 +830,11 @@ static int ath10k_vdev_stop(struct ath10k_vif *arvif)
>  		return ret;
>  	}
>  
> +	if (!WARN_ON(ar->num_started_vdevs == 0)) {

Even though this is correct, I think it's still a bit evil. For example,
I missed '!' the first time I looked at this. Even this is a line
longer, I think it would be easier to read:

WARN_ON(ar->num_started_vdevs == 0);

if (ar->num_started_vdevs != 0) {
        ...
}

-- 
Kalle Valo


From Nick.Shu at spirent.com  Mon Apr  7 17:27:40 2014
From: Nick.Shu at spirent.com (Shu, Nick)
Date: Mon, 7 Apr 2014 21:27:40 +0000
Subject: wifi card disconnected right after assoicated with AP
Message-ID: <153F35912E69C446A72CF7D6417EBADE7CF38D@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>

Hi, All:
I'm trying to use a wifi card to associate to a access point, but got a strange thing here.
Right after associated with AP, it disconnected from AP, the pattern repeated for:
Scan
Authentication
Association
De-authenticated
Dis-associated
I captured the frames as below, saw a "wlan0 del station <AP's MAC>", why wlan0 do this local request?

0.096321: wlan0 (phy #0): scan started
2.802464: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 5180 5200 5220 5240 5260
 5280 5300 5320 5500 5520 5540 5560 5580 5660 5680 5700 5745 5765 5785 5805 5825, ""
0.008130: wlan0: new station c4:04:15:29:cd:2e
0.000462: wlan0 (phy #0): auth c4:04:15:29:cd:2e -> 00:03:07:12:34:56 status: 0: Successful [frame: b0 00 3c 00 00 03 07
 12 34 56 c4 04 15 29 cd 2e c4 04 15 29 cd 2e b0 11 00 00 02 00 00 00 dd 09 00 10 18 02 00 00 1c 00 00]
0.004211: wlan0 (phy #0): assoc c4:04:15:29:cd:2e -> 00:03:07:12:34:56 status: 0: Successful [frame: 30 00 3c 00 00 03 0
7 12 34 56 c4 04 15 29 cd 2e c4 04 15 29 cd 2e c0 11 11 10 00 00 01 c0 01 08 8c 12 98 24 b0 48 60 6c 35 01 00 41 01 00 4
6 05 72 00 01 00 00 2d 1a ef 09 17 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3d 16 99 0f 15 0
0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7f 08 04 00 08 00 00 00 00 40 dd 09 00 10 18 02 00 00 1c 00 00 d
d 18 00 50 f2 02 01 01 88 00 03 a4 00 00 27 a4 00 00 42 43 bc 00 62 32 66 00]
0.000099: wlan0 (phy #0): connected to c4:04:15:29:cd:2e
0.000858: wlan0: del station c4:04:15:29:cd:2e
0.000508: wlan0 (phy #0): disassoc 00:03:07:12:34:56 -> c4:04:15:29:cd:2e reason 3: Deauthenticated because sending stat
ion is leaving (or has left) the IBSS or ESS [frame: a0 00 00 00 c4 04 15 29 cd 2e 00 03 07 12 34 56 c4 04 15 29 cd 2e 0
0 00 03 00]
0.000044: wlan0 (phy #0): disconnected (local request)
0.003030: phy #0: regulatory domain change: set to world roaming by the wireless core upon initialization request

Thank you!

Nick Shu


E-mail confidentiality.
--------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.

Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.

Or if within the US,

Spirent Communications,
26750 Agoura Road, Calabasas, CA, 91302, USA.
Tel No. 1-818-676- 2300


From kvalo at qca.qualcomm.com  Tue Apr  8 09:44:22 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 8 Apr 2014 16:44:22 +0300
Subject: wifi card disconnected right after assoicated with AP
In-Reply-To: <153F35912E69C446A72CF7D6417EBADE7CF38D@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
 (Nick Shu's message of "Mon, 7 Apr 2014 21:27:40 +0000")
References: <153F35912E69C446A72CF7D6417EBADE7CF38D@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
Message-ID: <87ob0ckkax.fsf@kamboji.qca.qualcomm.com>

"Shu, Nick" <Nick.Shu at spirent.com> writes:

> I'm trying to use a wifi card to associate to a access point, but got
> a strange thing here.

What card exactly? And what version of ath10k and the firmware?

> Right after associated with AP, it disconnected from AP, the pattern repeated for:
> Scan
> Authentication
> Association
> De-authenticated
> Dis-associated
> I captured the frames as below, saw a "wlan0 del station <AP's MAC>",
> why wlan0 do this local request?

Very difficult to say based on the information you provided. How do you
exactly control the STA? Using iw, wpa_supplicant, network-manager or
something else?

> 0.096321: wlan0 (phy #0): scan started
> 2.802464: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 5180 5200 5220 5240 5260
>  5280 5300 5320 5500 5520 5540 5560 5580 5660 5680 5700 5745 5765 5785 5805 5825, ""
> 0.008130: wlan0: new station c4:04:15:29:cd:2e
> 0.000462: wlan0 (phy #0): auth c4:04:15:29:cd:2e -> 00:03:07:12:34:56
> status: 0: Successful [frame: b0 00 3c 00 00 03 07

00:03:07:12:34:56 (the default MAC address) implies that there's a
problem with the calibration data. Please try with firmware
10.1.467.2-1. Do you get a proper MAC address then?

Also It would be good to see both kernel logs as well as wpasupplicant
debug logs. And a sniffer capture would be preferably as well.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Tue Apr  8 08:42:19 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 8 Apr 2014 15:42:19 +0300
Subject: Running throughput tests
In-Reply-To: <53372210.7060903@intec.ugent.be> (Bart Jooris's message of "Sat, 
 29 Mar 2014 20:42:08 +0100")
References: <00ea01cee403$5331f1e0$f995d5a0$@sparklan.com>
 <012e01cef7e0$99017e70$cb047b50$@sparklan.com>
 <52AACFB9.8080901@intec.ugent.be>
 <006301cefa3c$44c07b50$ce4171f0$@sparklan.com>
 <52AEC26B.2060400@intec.ugent.be>
 <007f01cefa41$8a940de0$9fbc29a0$@sparklan.com>
 <52AEE61F.5030505@intec.ugent.be>
 <006b01cefacb$6c0b2d60$44218820$@sparklan.com>
 <52B00B10.3050300@intec.ugent.be>
 <004b01cefb9d$04a543e0$0defcba0$@sparklan.com>
 <52B2AE75.9050206@intec.ugent.be>
 <00df01cf0090$05944f10$10bced30$@sparklan.com>
 <52B9672E.9000701@intec.ugent.be>
 <008c01cf012e$e59563d0$b0c02b70$@sparklan.com>
 <530A64E5.2040401@intec.ugent.be> <530B0670.1010009@stackframe.org>
 <530E5EF2.8070800@intec.ugent.be>
 <87y50weecb.fsf_-_@kamboji.qca.qualcomm.com>
 <5335910B.3000702@intec.ugent.be>
 <87y4zutk4i.fsf@kamboji.qca.qualcomm.com>
 <53372210.7060903@intec.ugent.be>
Message-ID: <871tx8m1qs.fsf@kamboji.qca.qualcomm.com>

Hi Bart,

Bart Jooris <bart.jooris at gmail.com> writes:

> On 03/28/2014 04:31 PM, Kalle Valo wrote:
>
>> You are providing very little information which makes it difficult to
>> help. For starters:
>>
>> * What firmware version?
> I've cloned 'recently' https://github.com/kvalo/ath10k-firmware/
>
> tree -D /lib/firmware/ath10k/QCA988X
> ??? [Mar 29 10:46] hw2.0
> ??? [Feb 26 19:39] board.bin
> ??? [Feb 26 19:39] firmware-2.bin
> ??? [Feb 26 19:39] otp.bin

That doesn't tell anything about the firmware version. Please read this:

http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Firmware_version

You should use 10.1.467.2-1 and see this in dmesg:

[ 2651.506691] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.1.467.2-1 api 2 htt 2.1

(Please note that the info print was changed few weeks back, so it won't
look exactly same on 3.13.)

>> * What version of ath10k are you using?
>
> I compiled kernel 3.13.5.

Ok, that's a relatively old as the version of ath10k in that release is
from last October. We have had quite a few optimisations and fixes since
then but you should still easily get 400 Mbps, especially on your fast
x86 cpus.

>> * Are you sure that the host is not limiting the throughput in any way?
>>    Try to disable _all_ kernel debug options.

> /var/log/syslog and dmesg doesn't to be packed with messages related
> to the throughput test. I don't think to have seen the CPU being
> overloaded during the test.
> I'm planning to go back to the office tomorrow to verify this.
>
> Further I have these in my kernel config
> CONFIG_ATH10K=m
> CONFIG_ATH10K_PCI=m
> # CONFIG_ATH10K_DEBUG is not set
> CONFIG_ATH10K_DEBUGFS=y
> CONFIG_ATH10K_TRACING=y
>
> I will disable the last two too.

Ok, this looks good. But just to confirm, can you send the full kernel
config file as well?

>> * Also describe your test setup in detail.
>>
> Common for AP and STA:
>
> -DSS-1300 with i5-2540M CPU @ 2.60GHz - 8GB RAM - SSD 64GB.
> -1 sparkLAN WPEA-351AC card with QCA9880 chip set and 3 dual band antenna's.
> -Kernel 3.13.5 containing the ath10k modules
> -firmwares cloned end of February
> -iperf in udp mode used for the  throughput test
>
> AP only:
> -ubuntu 12.04 LTS as crda wouldn't build on ubuntu 13.10 (libgcrypt issue).
> -hostapd v2.2-devel
> -modified regulatory database and crda build
> -your Full_hostapd_configuration + channel=36 and vht_oper_centr_freq_seg0_idx=42
>
> STA only:
> -ubuntu 13.10
> -nmcli is used to connect to the AP
>
> Distance between AP and STA: 60 cm. Antenna's are now directed
> orthogonal per device, antennaX (X=1..3) on both devices are pointing
> in the same direction. Although I've played a lot with the antenna's
> directions already and I can't remember one run where it had a lot of
> impact...
>
> The spectrum analyser measured a band of almost 80MHz being used.

This looks good as well. Is it possible for you take debug logs? First
enable these ath10k options:

CONFIG_ATH10K_DEBUG=y
CONFIG_ATH10K_DEBUGFS=y
CONFIG_ATH10K_TRACING=y

And start ath10k with debug mask 0x432, which prints info related to
firmware configuration:

modprobe ath10k_core.ko debug_mask=0x432

Also start hostapd with -dddt and connect the ath10k STA to the AP. Then
send here both the full dmesg output, preferably starting from kernel
boot, and hostapd debug logs here from the AP. No need to run any
throughput tests in this case, I just want to see how we configure the
firmware when the STA associates.

And even better if you could use trace-cmd, we get more logs that way:

http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Tracing

-- 
Kalle Valo


From michal.kazior at tieto.com  Tue Apr  8 07:21:40 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue,  8 Apr 2014 13:21:40 +0200
Subject: [PATCH v2] ath10k: improve htc tx credit debugging prints
In-Reply-To: <1396955920-25863-1-git-send-email-michal.kazior@tieto.com>
References: <1396955920-25863-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1396956100-26668-1-git-send-email-michal.kazior@tieto.com>

This way it's easier to track and debug htc tx
credit issues.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
v2:
 * remove empty newline

(Sorry for the noise!)

 drivers/net/wireless/ath/ath10k/htc.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 7f1bccd..5b58dbb 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -157,6 +157,9 @@ int ath10k_htc_send(struct ath10k_htc *htc,
 			goto err_pull;
 		}
 		ep->tx_credits -= credits;
+		ath10k_dbg(ATH10K_DBG_HTC,
+			   "htc ep %d consumed %d credits (total %d)\n",
+			   eid, credits, ep->tx_credits);
 		spin_unlock_bh(&htc->tx_lock);
 	}
 
@@ -185,6 +188,9 @@ err_credits:
 	if (ep->tx_credit_flow_enabled) {
 		spin_lock_bh(&htc->tx_lock);
 		ep->tx_credits += credits;
+		ath10k_dbg(ATH10K_DBG_HTC,
+			   "htc ep %d reverted %d credits back (total %d)\n",
+			   eid, credits, ep->tx_credits);
 		spin_unlock_bh(&htc->tx_lock);
 
 		if (ep->ep_ops.ep_tx_credits)
@@ -234,12 +240,12 @@ ath10k_htc_process_credit_report(struct ath10k_htc *htc,
 		if (report->eid >= ATH10K_HTC_EP_COUNT)
 			break;
 
-		ath10k_dbg(ATH10K_DBG_HTC, "ep %d got %d credits\n",
-			   report->eid, report->credits);
-
 		ep = &htc->endpoint[report->eid];
 		ep->tx_credits += report->credits;
 
+		ath10k_dbg(ATH10K_DBG_HTC, "htc ep %d got %d credits (total %d)\n",
+			   report->eid, report->credits, ep->tx_credits);
+
 		if (ep->ep_ops.ep_tx_credits) {
 			spin_unlock_bh(&htc->tx_lock);
 			ep->ep_ops.ep_tx_credits(htc->ar);
-- 
1.8.5.3



From baantunes at gmail.com  Tue Apr  8 06:02:59 2014
From: baantunes at gmail.com (Bruno Antunes)
Date: Tue, 8 Apr 2014 11:02:59 +0100
Subject: WDS and adhoc support with ath10k
Message-ID: <603DB158-F608-47C8-AEE8-F0FCFD563699@gmail.com>

Hi,

I recently have been testing some 802.11ac hardware with the ath10k.

Could someone confirm if WDS and adhoc mode currently don't have support with this driver?

Thanks,
Bruno
  

From Nick.Shu at spirent.com  Tue Apr  8 10:20:38 2014
From: Nick.Shu at spirent.com (Shu, Nick)
Date: Tue, 8 Apr 2014 14:20:38 +0000
Subject: wifi card disconnected right after assoicated with AP
In-Reply-To: <87ob0ckkax.fsf@kamboji.qca.qualcomm.com>
References: <153F35912E69C446A72CF7D6417EBADE7CF38D@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
 <87ob0ckkax.fsf@kamboji.qca.qualcomm.com>
Message-ID: <153F35912E69C446A72CF7D6417EBADE7CF3CF@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>

Thanks, Kalle:
I installed Ubuntu 13.10 server that has the Linux kernel 3.11 (this is what I read from the info) on my test server, it should have all driver and firmware to support the card.
Card is a mini PCIe that has a QCA 9880 chip in it with 3x3 antenna configuration, made by Embedded Works.
Access Point side is a Netgear AC1900 NightHawk. I set it up and using Ch153, WPA-PSK, with DHCP enabled.

I'm new in Linux (worked on Windows for most time), so I'm still learning.
I used "iw" and "wpa_supplicant" to control the card.
I failed for scan command at the beginning (posted a message last week for help) and fixed by bring up the wlan0 interface (ip link set woan0 up).
Then set net key "wpa_passphrase SSID KEY"
Start wpa with command: "wpa_supplicant -B -D nl80211 -i wlan0 -c /etc/wpa_supplicant.conf".

I actually got the card associated with the AP but couldn't get a valid IP address last Friday, so I was working on getting IP address issue.
Then on Monday, I logged in to server and found the card wlan0 is up without command "ip link set ...", also the  net key was remembered and auto associate to AP.
So something is taking over and doing association automatically for me ( I installed metwork-manager, but never use it yet).

You mentioned the card MAC is not a valid one? I though the vender should programmed a valid MAC to chip, right?

I used "iw event -r -f" to monitor the debug message, do I have to enable something to get the kernel and supplicant log?

Thanks!
Nick


-----Original Message-----
From: Kalle Valo [mailto:kvalo at qca.qualcomm.com]
Sent: Tuesday, April 08, 2014 8:44 AM
To: Shu, Nick
Cc: ath10k at lists.infradead.org
Subject: Re: wifi card disconnected right after assoicated with AP

"Shu, Nick" <Nick.Shu at spirent.com> writes:

> I'm trying to use a wifi card to associate to a access point, but got
> a strange thing here.

What card exactly? And what version of ath10k and the firmware?

> Right after associated with AP, it disconnected from AP, the pattern repeated for:
> Scan
> Authentication
> Association
> De-authenticated
> Dis-associated
> I captured the frames as below, saw a "wlan0 del station <AP's MAC>",
> why wlan0 do this local request?

Very difficult to say based on the information you provided. How do you exactly control the STA? Using iw, wpa_supplicant, network-manager or something else?

> 0.096321: wlan0 (phy #0): scan started
> 2.802464: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437
> 2442 2447 2452 2457 2462 5180 5200 5220 5240 5260
>  5280 5300 5320 5500 5520 5540 5560 5580 5660 5680 5700 5745 5765 5785 5805 5825, ""
> 0.008130: wlan0: new station c4:04:15:29:cd:2e
> 0.000462: wlan0 (phy #0): auth c4:04:15:29:cd:2e -> 00:03:07:12:34:56
> status: 0: Successful [frame: b0 00 3c 00 00 03 07

00:03:07:12:34:56 (the default MAC address) implies that there's a problem with the calibration data. Please try with firmware 10.1.467.2-1. Do you get a proper MAC address then?

Also It would be good to see both kernel logs as well as wpasupplicant debug logs. And a sniffer capture would be preferably as well.

--
Kalle Valo
E-mail confidentiality.
--------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.

Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.

Or if within the US,

Spirent Communications,
26750 Agoura Road, Calabasas, CA, 91302, USA.
Tel No. 1-818-676- 2300


From kvalo at qca.qualcomm.com  Tue Apr  8 08:45:12 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 8 Apr 2014 15:45:12 +0300
Subject: Running throughput tests
In-Reply-To: <5337C859.3040405@intec.ugent.be> (Bart Jooris's message of "Sun, 
 30 Mar 2014 09:31:37 +0200")
References: <00ea01cee403$5331f1e0$f995d5a0$@sparklan.com>
 <006301cefa3c$44c07b50$ce4171f0$@sparklan.com>
 <52AEC26B.2060400@intec.ugent.be>
 <007f01cefa41$8a940de0$9fbc29a0$@sparklan.com>
 <52AEE61F.5030505@intec.ugent.be>
 <006b01cefacb$6c0b2d60$44218820$@sparklan.com>
 <52B00B10.3050300@intec.ugent.be>
 <004b01cefb9d$04a543e0$0defcba0$@sparklan.com>
 <52B2AE75.9050206@intec.ugent.be>
 <00df01cf0090$05944f10$10bced30$@sparklan.com>
 <52B9672E.9000701@intec.ugent.be>
 <008c01cf012e$e59563d0$b0c02b70$@sparklan.com>
 <530A64E5.2040401@intec.ugent.be> <530B0670.1010009@stackframe.org>
 <530E5EF2.8070800@intec.ugent.be>
 <87y50weecb.fsf_-_@kamboji.qca.qualcomm.com>
 <5335910B.3000702@intec.ugent.be>
 <87y4zutk4i.fsf@kamboji.qca.qualcomm.com>
 <53372210.7060903@intec.ugent.be> <53372A9A.1090402@candelatech.com>
 <5337C859.3040405@intec.ugent.be>
Message-ID: <87wqf0kn1j.fsf@kamboji.qca.qualcomm.com>

Bart Jooris <bart.jooris at gmail.com> writes:

> Dear Ben,
>
> On 03/29/2014 09:18 PM, Ben Greear wrote:
>> On 03/29/2014 12:42 PM, Bart Jooris wrote:
>>
>>> -DSS-1300 with i5-2540M CPU @ 2.60GHz - 8GB RAM - SSD 64GB.
>>> -1 sparkLAN WPEA-351AC card with QCA9880 chip set and 3 dual band
>>> antenna's.
>>> -Kernel 3.13.5 containing the ath10k modules
>>> -firmwares cloned end of February
>>> -iperf in udp mode used for the  throughput test
>>
>> I get 500+Mbps on some other NICs with same chipset... 
>
> :-) Which cards are you using?
>
>> I'll get some
>> WPEA-351AC as soon as I can find someone willing to sell them and will
>> do some tests on those as well...
>
> I have 8 of those, I can lend you 2.

Can you setup a third board as a sniffer and see what's happening on the
air? But it's still more important to get ath10k and hostapd debug logs,
try to take those first.

-- 
Kalle Valo


From michal.kazior at tieto.com  Tue Apr  8 07:18:40 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue,  8 Apr 2014 13:18:40 +0200
Subject: [PATCH] ath10k: improve htc tx credit debugging prints
Message-ID: <1396955920-25863-1-git-send-email-michal.kazior@tieto.com>

This way it's easier to track and debug htc tx
credit issues.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/htc.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 7f1bccd..d083198 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -157,7 +157,11 @@ int ath10k_htc_send(struct ath10k_htc *htc,
 			goto err_pull;
 		}
 		ep->tx_credits -= credits;
+		ath10k_dbg(ATH10K_DBG_HTC,
+			   "htc ep %d consumed %d credits (total %d)\n",
+			   eid, credits, ep->tx_credits);
 		spin_unlock_bh(&htc->tx_lock);
+
 	}
 
 	ath10k_htc_prepare_tx_skb(ep, skb);
@@ -185,6 +189,9 @@ err_credits:
 	if (ep->tx_credit_flow_enabled) {
 		spin_lock_bh(&htc->tx_lock);
 		ep->tx_credits += credits;
+		ath10k_dbg(ATH10K_DBG_HTC,
+			   "htc ep %d reverted %d credits back (total %d)\n",
+			   eid, credits, ep->tx_credits);
 		spin_unlock_bh(&htc->tx_lock);
 
 		if (ep->ep_ops.ep_tx_credits)
@@ -234,12 +241,12 @@ ath10k_htc_process_credit_report(struct ath10k_htc *htc,
 		if (report->eid >= ATH10K_HTC_EP_COUNT)
 			break;
 
-		ath10k_dbg(ATH10K_DBG_HTC, "ep %d got %d credits\n",
-			   report->eid, report->credits);
-
 		ep = &htc->endpoint[report->eid];
 		ep->tx_credits += report->credits;
 
+		ath10k_dbg(ATH10K_DBG_HTC, "htc ep %d got %d credits (total %d)\n",
+			   report->eid, report->credits, ep->tx_credits);
+
 		if (ep->ep_ops.ep_tx_credits) {
 			spin_unlock_bh(&htc->tx_lock);
 			ep->ep_ops.ep_tx_credits(htc->ar);
-- 
1.8.5.3



From wangdc at dhc.com.cn  Tue Apr  8 04:51:42 2014
From: wangdc at dhc.com.cn (wangdc)
Date: Tue, 8 Apr 2014 16:51:42 +0800
Subject: For Help: problems with tx bitrate in ath10k
Message-ID: <5343B89E.2090407@dhc.com.cn>

Hi,all

I used the backports-3.13.2-1 to drive a 11ac card(WLE900VX) on the 
ubuntu 12.04 LTS(64bit) (3.8.0-35-generic).
The card seemed to be working well when i connected it to a broadcom AC 
APs and the card could also send or receive data normally.
But when using command 'iw dev wlan0 station dump' to check the actual 
Rx and Tx rate, i couldn't get the tx bitrate correctly.

root at ubuntu:~$ iw dev wlan2 station dump
Station 10:48:b1:e8:17:a6 (on wlan2)
     inactive time:    28680 ms
     rx bytes:    903704
     rx packets:    6747
     tx bytes:    20731
     tx packets:    163
     tx retries:    1969
     tx failed:    0
     signal:      -36 dBm
     signal avg:    -36 dBm
     tx bitrate:     MCS 32 40Mhz short GI
     authorized:    yes
     authenticated:    yes
     preamble:    long
     WMM/WME:    yes
     MFP:        no
     TDLS peer:        no

And sometimes the tx bitrate was 3693.3 MBit/s, 65.0 MBit/s, 6.5Mbit/s etc.

The start log as following.

root at ubuntu:~$ dmesg | grep ath
[    0.800424] MODSIGN: Loaded cert 'Magrathea: Glacier signing key: 
c77318d5b035f7cbfa665f640863f8bc32a3fa33'
[   10.539694] ath10k_pci 0000:04:00.0: BAR 0: assigned [mem 
0xf0400000-0xf05fffff 64bit]
[   10.886386] ath10k: MSI-X didn't succeed (1), trying MSI
[   10.886454] ath10k_pci 0000:04:00.0: irq 44 for MSI/MSI-X
[   10.886492] ath10k: MSI interrupt handling
[   10.921722] ath10k: Hardware name qca988x hw2.0 version 0x4100016c
[   12.246510] ath10k: UART prints disabled
[   12.250960] ath10k: firmware 10.1.467.2-1 booted
[   12.260459] ath10k: htt target version 2.1
[   12.261559] ath: EEPROM regdomain: 0x0
[   12.261561] ath: EEPROM indicates default country code should be used
[   12.261562] ath: doing EEPROM country->regdmn map search
[   12.261563] ath: country maps to regdmn code: 0x3a
[   12.261565] ath: Country alpha2 being used: US
[   12.261566] ath: Regpair used: 0x3a
[   18.767377] ath10k: MSI-X didn't succeed (1), trying MSI
[   18.767451] ath10k_pci 0000:04:00.0: irq 44 for MSI/MSI-X
[   18.767496] ath10k: MSI interrupt handling
[   19.700523] ath10k: UART prints disabled
[   19.705037] ath10k: firmware 10.1.467.2-1 booted
[   19.714921] ath10k: htt target version 2.1
...

root at ubuntu:~$ dmesg
[  121.846056] ------------[ cut here ]------------
[  121.846090] WARNING: at /home/backports/net/wireless/util.c:1066 
cfg80211_calculate_bitrate+0x18e/0x210 [cfg80211]()
[  121.846093] Hardware name: 23066RC
[  121.846094] Modules linked in: ip_vs(F) nf_conntrack(F) libcrc32c(F) 
bnep(F) rfcomm(F) parport_pc(F) ppdev(F) arc4(F) coretemp(F) 
snd_hda_codec_hdmi(F) snd_hda_codec_realtek(F) ath10k_pci(OF) 
ath10k_core(OF) uvcvideo(F) nfsd(F) snd_hda_intel(F) kvm(F) 
snd_hda_codec(F) ath(OF) videobuf2_core(F) nfs_acl(F) videodev(F) 
auth_rpcgss(F) i915(F) nfs(F) videobuf2_vmalloc(F) snd_hwdep(F) btusb(F) 
snd_pcm(F) mac80211(OF) videobuf2_memops(F) joydev(F) fscache(F) 
bluetooth(F) ghash_clmulni_intel(F) thinkpad_acpi(F) lockd(F) 
snd_seq_midi(F) cryptd(F) drm_kms_helper(F) binfmt_misc(F) 
snd_rawmidi(F) drm(F) snd_seq_midi_event(F) cfg80211(OF) sunrpc(F) 
snd_seq(F) psmouse(F) snd_timer(F) snd_seq_device(F) mei(F) snd(F) 
microcode(F) serio_raw(F) mac_hid(F) i2c_algo_bit(F) snd_page_alloc(F) 
compat(OF) soundcore(F) lpc_ich(F) nvram(F) wmi(F) video(F) lp(F) 
parport(F) sdhci_pci(F) sdhci(F) e1000e(F)
[  121.846157] Pid: 1050, comm: NetworkManager Tainted: GF O 
3.8.0-35-generic #52~precise1-Ubuntu
[  121.846159] Call Trace:
[  121.846171]  [<ffffffff81059b6f>] warn_slowpath_common+0x7f/0xc0
[  121.846177]  [<ffffffff81059bca>] warn_slowpath_null+0x1a/0x20
[  121.846193]  [<ffffffffa019c8de>] 
cfg80211_calculate_bitrate+0x18e/0x210 [cfg80211]
[  121.846212]  [<ffffffffa01a99a7>] nl80211_put_sta_rate+0x57/0x2a0 
[cfg80211]
[  121.846229]  [<ffffffffa01ac0e1>] 
nl80211_send_station.isra.63+0x4a1/0x870 [cfg80211]
[  121.846246]  [<ffffffffa01ac98c>] nl80211_get_station+0x22c/0x290 
[cfg80211]
[  121.846254]  [<ffffffff8160f6dd>] genl_rcv_msg+0x22d/0x2b0
[  121.846260]  [<ffffffff815d830b>] ? __alloc_skb+0x8b/0x2a0
[  121.846264]  [<ffffffff8160f4b0>] ? genl_rcv+0x40/0x40
[  121.846270]  [<ffffffff8160ee89>] netlink_rcv_skb+0xa9/0xd0
[  121.846274]  [<ffffffff8160f495>] genl_rcv+0x25/0x40
[  121.846279]  [<ffffffff8160e7d1>] netlink_unicast+0x1b1/0x230
[  121.846285]  [<ffffffff8160eb4e>] netlink_sendmsg+0x2fe/0x3b0
[  121.846290]  [<ffffffff815cb282>] sock_sendmsg+0xd2/0xf0
[  121.846296]  [<ffffffff815cdb8a>] ? move_addr_to_kernel+0x5a/0xa0
[  121.846300]  [<ffffffff815da406>] ? verify_iovec+0x56/0xd0
[  121.846305]  [<ffffffff815cd09c>] ___sys_sendmsg+0x3ac/0x3c0
[  121.846311]  [<ffffffff811aea86>] ? pollwake+0x66/0x70
[  121.846316]  [<ffffffff81092050>] ? try_to_wake_up+0x200/0x200
[  121.846323]  [<ffffffff816f53e5>] ? _raw_spin_lock_irq+0x15/0x20
[  121.846327]  [<ffffffff81092050>] ? try_to_wake_up+0x200/0x200
[  121.846332]  [<ffffffff815ceba9>] __sys_sendmsg+0x49/0x90
[  121.846337]  [<ffffffff815cec09>] sys_sendmsg+0x19/0x20
[  121.846343]  [<ffffffff816fdf5d>] system_call_fastpath+0x1a/0x1f
[  121.846346] ---[ end trace fc50900f4228222f ]---

About the reason of the warning info above,
when debugging the code, rate->flags was 0x0 and the rate->mcs value was 
more than 32 in the function of cfg80211_calculate_bitrate,
but i didn't know why i got a wrong rate value.

/home/backports/net/wireless/util.c
u32 cfg80211_calculate_bitrate(struct rate_info *rate)
{
     int modulation, streams, bitrate;

     if (!(rate->flags & RATE_INFO_FLAGS_MCS) &&
         !(rate->flags & RATE_INFO_FLAGS_VHT_MCS))
         return rate->legacy;
     if (rate->flags & RATE_INFO_FLAGS_60G)
         return cfg80211_calculate_bitrate_60g(rate);
     if (rate->flags & RATE_INFO_FLAGS_VHT_MCS)
         return cfg80211_calculate_bitrate_vht(rate);

     /* the formula below does only work for MCS values smaller than 32 */
     if (WARN_ON_ONCE(rate->mcs >= 32))
         return 0;

I tried other version of the firmware and backports, the test results 
were as following:
a)The problem repeated when i tried firmware-2.bin_999.999.0.636.
b)The tx bitrate was fixed to 6MBit/s  and there was no warning info in 
the boot log  when i adopted the latest development 
releases(backports-20140221).

Is there anybody meets the same problem? If so, please give me some 
suggestion on getting Tx rate properly.

Thanks.
Rex



From kvalo at qca.qualcomm.com  Tue Apr  8 02:58:20 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 8 Apr 2014 09:58:20 +0300
Subject: [RFT 4/4] ath10k: improve tx flushing
In-Reply-To: <1396611464-5940-5-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 4 Apr 2014 13:37:44 +0200")
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1396611464-5940-5-git-send-email-michal.kazior@tieto.com>
Message-ID: <87k3b0mho3.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> Flushing was prone to timeouts when powersaving
> clients were involved that went missing while
> asleep. The common culprit was NullFunc frame
> being stuck in FW/HW queues.
>
> Introduce a two-pass flushing with WMI flush
> commands interleaved to force frame drops if
> necessary. This allows for a decreased flush
> timeout time and should get rid of some warnings.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

With this patch I see a new checkpatch warning:

drivers/net/wireless/ath/ath10k/mac.c:3785: WARNING: line over 80 characters

-- 
Kalle Valo


From michal.kazior at tieto.com  Tue Apr  8 01:51:45 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 8 Apr 2014 07:51:45 +0200
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <53435F89.60500@candelatech.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <5341F1A9.2030202@candelatech.com>
 <CA+BoTQndgEB7X-RUPPkxdjnp96LJzbv6=Q9K4XTTrky-QwE4Ww@mail.gmail.com>
 <53435F89.60500@candelatech.com>
Message-ID: <CA+BoTQk6G4-h8HQENbK9snrXo6j6FW4D+07XKZMEEuvWiu03ww@mail.gmail.com>

On 8 April 2014 04:31, Ben Greear <greearb at candelatech.com> wrote:
> On 04/07/2014 02:11 AM, Michal Kazior wrote:
>
>> These logs are not enough. I'd love to see traces for this to see what
>> frames are actually submitted and when tx credits are replenished.
>>
>> I also wonder if this can be somehow related to your FW changes to
>> allow connecting multiple client virtual interfaces to a single AP?
>
>
> I think it is unlikely due to my firmware changes...little of that touched
> the handling of management frames.  It might very well be a basic problem in
> either the firmware or driver when using multiple station VIFS.  I think
> that
> aside from my testing that code has not been used much.
>
> Note my followup email that problems started with patch 3/4...not sure you
> saw that one or not.  I saw similar failure to associate & get DHCP (and
> slow/hung user-space) without the kernel error logs.

I did get that mail. It's just that it makes little sense. Patch 3/4
simply extends ath10k_flush() to wait for management frames. It
shouldn't change behaviour of tx credit starvation which appears to be
the case in the logs you provided.


> I've added the first two patches to my tree and will continue to run
> with them since they do not appear to cause problems so far.

Patch 2/4 is probably meaningless in itself. It is just a preparation for 4/4.

Anyway, thanks for testing!


Micha?


From greearb at candelatech.com  Mon Apr  7 22:31:37 2014
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 07 Apr 2014 19:31:37 -0700
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <CA+BoTQndgEB7X-RUPPkxdjnp96LJzbv6=Q9K4XTTrky-QwE4Ww@mail.gmail.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>	<5341F1A9.2030202@candelatech.com>
 <CA+BoTQndgEB7X-RUPPkxdjnp96LJzbv6=Q9K4XTTrky-QwE4Ww@mail.gmail.com>
Message-ID: <53435F89.60500@candelatech.com>

On 04/07/2014 02:11 AM, Michal Kazior wrote:

> These logs are not enough. I'd love to see traces for this to see what
> frames are actually submitted and when tx credits are replenished.
>
> I also wonder if this can be somehow related to your FW changes to
> allow connecting multiple client virtual interfaces to a single AP?

I think it is unlikely due to my firmware changes...little of that touched
the handling of management frames.  It might very well be a basic problem in
either the firmware or driver when using multiple station VIFS.  I think that
aside from my testing that code has not been used much.

Note my followup email that problems started with patch 3/4...not sure you
saw that one or not.  I saw similar failure to associate & get DHCP (and
slow/hung user-space) without the kernel error logs.

I've added the first two patches to my tree and will continue to run
with them since they do not appear to cause problems so far.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From kvalo at qca.qualcomm.com  Tue Apr  8 02:39:46 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 8 Apr 2014 09:39:46 +0300
Subject: [PATCH] ath10k: cleanup debug messages in
 ath10k_wmi_event_host_swba()
In-Reply-To: <20140328093028.16927.81551.stgit@potku.adurom.net> (Kalle Valo's
 message of "Fri, 28 Mar 2014 11:30:28 +0200")
References: <20140328093028.16927.81551.stgit@potku.adurom.net>
Message-ID: <8738honx3h.fsf@kamboji.qca.qualcomm.com>

Kalle Valo <kvalo at qca.qualcomm.com> writes:

> They were just too superfluous and made it harder to read logs. Change them to
> follow the normal style used in ath10k.
>
> Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>

Applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Tue Apr  8 11:23:54 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 8 Apr 2014 18:23:54 +0300
Subject: wifi card disconnected right after assoicated with AP
In-Reply-To: <153F35912E69C446A72CF7D6417EBADE7CF3CF@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
 (Nick Shu's message of "Tue, 8 Apr 2014 14:20:38 +0000")
References: <153F35912E69C446A72CF7D6417EBADE7CF38D@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
 <87ob0ckkax.fsf@kamboji.qca.qualcomm.com>
 <153F35912E69C446A72CF7D6417EBADE7CF3CF@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
Message-ID: <87fvlnlu9h.fsf@kamboji.qca.qualcomm.com>

Hi Nick,

"Shu, Nick" <Nick.Shu at spirent.com> writes:

> I installed Ubuntu 13.10 server that has the Linux kernel 3.11 (this
> is what I read from the info) on my test server, it should have all
> driver and firmware to support the card.

In ath10k's lifetime that's ancient. I recommend using backports to get
a more recent version of ath10k:

https://backports.wiki.kernel.org/index.php/Main_Page

I would not even bother try debugging the issue until you have updated
ath10k and the firmware.

> Card is a mini PCIe that has a QCA 9880 chip in it with 3x3 antenna
> configuration, made by Embedded Works.
> Access Point side is a Netgear AC1900 NightHawk. I set it up and using
> Ch153, WPA-PSK, with DHCP enabled.
>
> I'm new in Linux (worked on Windows for most time), so I'm still
> learning.

Unfortunately I can only help with ath10k specific issues, I do not have
time to give general Linux support. But I can give you pointers and
there are other forums which can help you better with those.

> I used "iw" and "wpa_supplicant" to control the card.
> I failed for scan command at the beginning (posted a message last week
> for help) and fixed by bring up the wlan0 interface (ip link set woan0
> up).
> Then set net key "wpa_passphrase SSID KEY"
> Start wpa with command: "wpa_supplicant -B -D nl80211 -i wlan0 -c
> /etc/wpa_supplicant.conf".
>
> I actually got the card associated with the AP but couldn't get a
> valid IP address last Friday, so I was working on getting IP address
> issue.
> Then on Monday, I logged in to server and found the card wlan0 is up
> without command "ip link set ...", also the net key was remembered and
> auto associate to AP.
> So something is taking over and doing association automatically for me
> ( I installed metwork-manager, but never use it yet).

If you run wpasupplicant manually you should disable network-manager,
otherwise there will be problems. IIRC one issue might be that
network-manager automatically disconnects you, which might be the issue
you are having.

> You mentioned the card MAC is not a valid one? I though the vender
> should programmed a valid MAC to chip, right?

Yes, the MAC address is stored in EEPROM and the firmware reads it. But
older firmwares might not support newer boards and then there will be
problems in reading the EEPROM. That's why I recommend using firmware
10.1.467.2-1.

> I used "iw event -r -f" to monitor the debug message, do I have to
> enable something to get the kernel and supplicant log?

wpasupplicant has it's own debug log (-dddt) and kernel log can be read
with dmesg. I recommend starting from here:

http://wireless.kernel.org/en/users/Drivers/ath10k/debug
http://wireless.kernel.org/en/users/Documentation/wpa_supplicant

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Tue Apr  8 03:04:05 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 8 Apr 2014 10:04:05 +0300
Subject: [PATCH v2 2/2] ath10k: refactor radar detection code
In-Reply-To: <CA+BoTQ=-vrJ_tize+uwCp5jgM7pvPZ0s9bGUK42Ko1TCHzmfzg@mail.gmail.com>
 (Michal Kazior's message of "Tue, 8 Apr 2014 08:32:58 +0200")
References: <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-3-git-send-email-michal.kazior@tieto.com>
 <87bnwdnslk.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=-vrJ_tize+uwCp5jgM7pvPZ0s9bGUK42Ko1TCHzmfzg@mail.gmail.com>
Message-ID: <87fvlomhei.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

>> Even though this is correct, I think it's still a bit evil. For example,
>> I missed '!' the first time I looked at this. Even this is a line
>> longer, I think it would be easier to read:
>>
>> WARN_ON(ar->num_started_vdevs == 0);
>>
>> if (ar->num_started_vdevs != 0) {
>>         ...
>> }
>
> Sound reasonably.

I changed it like this now:

--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -878,7 +878,9 @@ static int ath10k_vdev_stop(struct ath10k_vif *arvif)
                return ret;
        }
 
-       if (!WARN_ON(ar->num_started_vdevs == 0)) {
+       WARN_ON(ar->num_started_vdevs == 0);
+
+       if (ar->num_started_vdevs != 0) {
                ar->num_started_vdevs--;
                ath10k_recalc_radar_detection(ar);

Full patch here:

https://github.com/kvalo/ath/commit/0d57ff8b99539895c5a3714d7ecd80a58b6a8928

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Tue Apr  8 03:41:37 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 8 Apr 2014 10:41:37 +0300
Subject: ath10k FAQ
Message-ID: <8761mkmfny.fsf@kamboji.qca.qualcomm.com>

Hi,

I created a small FAQ to the wiki and added the four questions which
seem to be popular:

http://wireless.kernel.org/en/users/Drivers/ath10k/faq

Comments welcome. And feel free to update it with new questions.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Tue Apr  8 02:42:01 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 8 Apr 2014 09:42:01 +0300
Subject: [PATCH] ath10k: refactor monitor code
In-Reply-To: <1396610305-5229-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 4 Apr 2014 13:18:25 +0200")
References: <1396610305-5229-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87y4zgmifa.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> It was possible to create/delete/start/stop
> monitor vdev from a few places that were not
> exclusively protected against each other. This
> resulted in monitor vdev being stopped/removed by
> one call origin while another one was expecting it
> to continue running.
>
> For example if CAC was started and interface's
> promiscuous mode was toggled monitor vdev was
> removed from the driver meaning no radar would be
> detected. In additional a warning would be printed
> upon CAC completion complaining it tried to stop
> non-running monitor vdev.
>
> The patch simplifies monitor code by removing
> IEEE80211_HW_WANT_MONITOR_VIF (which wasn't really
> ever needed) and improves state tracking. It also
> unifies prints.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From michal.kazior at tieto.com  Tue Apr  8 02:32:58 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 8 Apr 2014 08:32:58 +0200
Subject: [PATCH v2 2/2] ath10k: refactor radar detection code
In-Reply-To: <87bnwdnslk.fsf@kamboji.qca.qualcomm.com>
References: <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-3-git-send-email-michal.kazior@tieto.com>
 <87bnwdnslk.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CA+BoTQ=-vrJ_tize+uwCp5jgM7pvPZ0s9bGUK42Ko1TCHzmfzg@mail.gmail.com>

On 7 April 2014 16:04, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> If 20MHz CAC completed successfully then
>> subsequent CAC with wider bandwidth (40Mhz, 80Mhz)
>> with identical control frequency did not start
>> monitor vdev making it impossible to detect any
>> radar pulses during intended CAC.
>>
>> It also was incorrect to assume ath10k_config() will
>> be called after CAC is finished. Theoretically for
>> non-HT channels nothing changes between CAC and
>> start_ap() (albeit in practice this can be
>> different). The incorrect assumption led to CAC
>> not being stopped on non-HT chandefs leading to
>> all Rx being drooped making it impossible for
>> clients to associate.
>>
>> While at it clean up the code a bit.
>>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>
> [...]
>
>> @@ -858,6 +830,11 @@ static int ath10k_vdev_stop(struct ath10k_vif *arvif)
>>               return ret;
>>       }
>>
>> +     if (!WARN_ON(ar->num_started_vdevs == 0)) {
>
> Even though this is correct, I think it's still a bit evil. For example,
> I missed '!' the first time I looked at this. Even this is a line
> longer, I think it would be easier to read:
>
> WARN_ON(ar->num_started_vdevs == 0);
>
> if (ar->num_started_vdevs != 0) {
>         ...
> }

Sound reasonably.


Micha?


From michal.kazior at tieto.com  Tue Apr  8 02:07:32 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 8 Apr 2014 08:07:32 +0200
Subject: [PATCH v2 1/2] ath10k: reorder functions
In-Reply-To: <87fvlpnt5x.fsf@kamboji.qca.qualcomm.com>
References: <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-2-git-send-email-michal.kazior@tieto.com>
 <87fvlpnt5x.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CA+BoTQnJ2Dg9O64=uvn7U=6Tadv6WwcRGOViHScuS3sQ8=OeMg@mail.gmail.com>

On 7 April 2014 15:52, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> This is done to avoid forward declarations with
>> upcomming patches.
>>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>
> Like you said, I had a conflict with this patch. Can you double check my
> resolution, please:
>
> https://github.com/kvalo/ath/commit/0953accf20c325adde537a57c3e6a6a0f1ff04d7

Looks good.


Micha?


From michal.kazior at tieto.com  Tue Apr  8 03:03:15 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 8 Apr 2014 09:03:15 +0200
Subject: [PATCH] ath10k: refactor monitor code
In-Reply-To: <87ob0cmhwp.fsf@kamboji.qca.qualcomm.com>
References: <1396610305-5229-1-git-send-email-michal.kazior@tieto.com>
 <87y4zgmifa.fsf@kamboji.qca.qualcomm.com>
 <87ob0cmhwp.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CA+BoTQkWjr9pxTN0AgqDXLzXqTjJ1a=Zepss5UdDw7tpOQLOAw@mail.gmail.com>

On 8 April 2014 08:53, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Kalle Valo <kvalo at qca.qualcomm.com> writes:
>
>> Michal Kazior <michal.kazior at tieto.com> writes:
>>
>>> It was possible to create/delete/start/stop
>>> monitor vdev from a few places that were not
>>> exclusively protected against each other. This
>>> resulted in monitor vdev being stopped/removed by
>>> one call origin while another one was expecting it
>>> to continue running.
>>>
>>> For example if CAC was started and interface's
>>> promiscuous mode was toggled monitor vdev was
>>> removed from the driver meaning no radar would be
>>> detected. In additional a warning would be printed
>>> upon CAC completion complaining it tried to stop
>>> non-running monitor vdev.
>>>
>>> The patch simplifies monitor code by removing
>>> IEEE80211_HW_WANT_MONITOR_VIF (which wasn't really
>>> ever needed) and improves state tracking. It also
>>> unifies prints.
>>>
>>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>>
>> Thanks, applied.
>
> Actually there were two checkpatch warnings which I had missed:
>
> drivers/net/wireless/ath/ath10k/mac.c:2587: WARNING: line over 80 characters
> drivers/net/wireless/ath/ath10k/mac.c:2852: WARNING: line over 80 characters
>
> I amended it like this:
>

[...]

Sorry for the trouble and thanks!


Micha?


From kvalo at qca.qualcomm.com  Tue Apr  8 02:53:10 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 8 Apr 2014 09:53:10 +0300
Subject: [PATCH] ath10k: refactor monitor code
In-Reply-To: <87y4zgmifa.fsf@kamboji.qca.qualcomm.com> (Kalle Valo's message
 of "Tue, 08 Apr 2014 09:42:01 +0300")
References: <1396610305-5229-1-git-send-email-michal.kazior@tieto.com>
 <87y4zgmifa.fsf@kamboji.qca.qualcomm.com>
Message-ID: <87ob0cmhwp.fsf@kamboji.qca.qualcomm.com>

Kalle Valo <kvalo at qca.qualcomm.com> writes:

> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> It was possible to create/delete/start/stop
>> monitor vdev from a few places that were not
>> exclusively protected against each other. This
>> resulted in monitor vdev being stopped/removed by
>> one call origin while another one was expecting it
>> to continue running.
>>
>> For example if CAC was started and interface's
>> promiscuous mode was toggled monitor vdev was
>> removed from the driver meaning no radar would be
>> detected. In additional a warning would be printed
>> upon CAC completion complaining it tried to stop
>> non-running monitor vdev.
>>
>> The patch simplifies monitor code by removing
>> IEEE80211_HW_WANT_MONITOR_VIF (which wasn't really
>> ever needed) and improves state tracking. It also
>> unifies prints.
>>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>
> Thanks, applied.

Actually there were two checkpatch warnings which I had missed:

drivers/net/wireless/ath/ath10k/mac.c:2587: WARNING: line over 80 characters
drivers/net/wireless/ath/ath10k/mac.c:2852: WARNING: line over 80 characters

I amended it like this:

--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2584,7 +2584,8 @@ static int ath10k_config(struct ieee80211_hw *hw, u32 changed)
                        ar->monitor = true;
                        ret = ath10k_monitor_start(ar);
                        if (ret) {
-                               ath10k_warn("failed to start monitor (config): %d\n", ret);
+                               ath10k_warn("failed to start monitor (config): %d\n",
+                                           ret);
                                ar->monitor = false;
                        }
                } else if (!(conf->flags & IEEE80211_CONF_MONITOR) &&
@@ -2849,7 +2850,8 @@ static void ath10k_configure_filter(struct ieee80211_hw *hw,
                ar->promisc = true;
                ret = ath10k_monitor_start(ar);
                if (ret) {
-                       ath10k_warn("failed to start monitor (promisc): %d\n", ret);
+                       ath10k_warn("failed to start monitor (promisc): %d\n",
+                                   ret);
                        ar->promisc = false;
                }
        } else if (!(ar->filter_flags & FIF_PROMISC_IN_BSS) && ar->promisc) {

-- 
Kalle Valo


From greearb at candelatech.com  Tue Apr  8 12:02:29 2014
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 08 Apr 2014 09:02:29 -0700
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <CA+BoTQk6G4-h8HQENbK9snrXo6j6FW4D+07XKZMEEuvWiu03ww@mail.gmail.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <5341F1A9.2030202@candelatech.com>
 <CA+BoTQndgEB7X-RUPPkxdjnp96LJzbv6=Q9K4XTTrky-QwE4Ww@mail.gmail.com>
 <53435F89.60500@candelatech.com>
 <CA+BoTQk6G4-h8HQENbK9snrXo6j6FW4D+07XKZMEEuvWiu03ww@mail.gmail.com>
Message-ID: <53441D95.9000409@candelatech.com>

On 04/07/2014 10:51 PM, Michal Kazior wrote:
> On 8 April 2014 04:31, Ben Greear <greearb at candelatech.com> wrote:
>> On 04/07/2014 02:11 AM, Michal Kazior wrote:
>>
>>> These logs are not enough. I'd love to see traces for this to see what
>>> frames are actually submitted and when tx credits are replenished.
>>>
>>> I also wonder if this can be somehow related to your FW changes to
>>> allow connecting multiple client virtual interfaces to a single AP?
>>
>>
>> I think it is unlikely due to my firmware changes...little of that touched
>> the handling of management frames.  It might very well be a basic problem in
>> either the firmware or driver when using multiple station VIFS.  I think
>> that
>> aside from my testing that code has not been used much.
>>
>> Note my followup email that problems started with patch 3/4...not sure you
>> saw that one or not.  I saw similar failure to associate & get DHCP (and
>> slow/hung user-space) without the kernel error logs.
> 
> I did get that mail. It's just that it makes little sense. Patch 3/4
> simply extends ath10k_flush() to wait for management frames. It
> shouldn't change behaviour of tx credit starvation which appears to be
> the case in the logs you provided.

Maybe this causes unexpected waits (under lock) that in turn causes other
vifs trying to come up at the same time to time out?

It seems easily reproducible, so let me know what sort of logging/tracing
you would like to see (and how to enable it if it is not trivial)
and I'll reproduce it and send you the logs.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From Nick.Shu at spirent.com  Tue Apr  8 12:05:21 2014
From: Nick.Shu at spirent.com (Shu, Nick)
Date: Tue, 8 Apr 2014 16:05:21 +0000
Subject: wifi card disconnected right after assoicated with AP
In-Reply-To: <87fvlnlu9h.fsf@kamboji.qca.qualcomm.com>
References: <153F35912E69C446A72CF7D6417EBADE7CF38D@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
 <87ob0ckkax.fsf@kamboji.qca.qualcomm.com>
 <153F35912E69C446A72CF7D6417EBADE7CF3CF@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
 <87fvlnlu9h.fsf@kamboji.qca.qualcomm.com>
Message-ID: <153F35912E69C446A72CF7D6417EBADE7CF405@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>

Thanks, Kalle:
Yeah, I uninstalled "network-manager" and problem solved.
Now, card can associate to AP without dropping.

Now problem moved to firmware related issue, I had a valid MAC from chip vendor but it appeared as a default MAC from event message and AP's connected device field.
It couldn't get a valid IP address from AP's DHCP.

Now, I need to work on getting new driver and firmware from backports .
Thanks again
Nick

-----Original Message-----
From: Kalle Valo [mailto:kvalo at qca.qualcomm.com]
Sent: Tuesday, April 08, 2014 10:24 AM
To: Shu, Nick
Cc: ath10k at lists.infradead.org
Subject: Re: wifi card disconnected right after assoicated with AP

Hi Nick,

"Shu, Nick" <Nick.Shu at spirent.com> writes:

> I installed Ubuntu 13.10 server that has the Linux kernel 3.11 (this
> is what I read from the info) on my test server, it should have all
> driver and firmware to support the card.

In ath10k's lifetime that's ancient. I recommend using backports to get a more recent version of ath10k:

https://backports.wiki.kernel.org/index.php/Main_Page

I would not even bother try debugging the issue until you have updated ath10k and the firmware.

> Card is a mini PCIe that has a QCA 9880 chip in it with 3x3 antenna
> configuration, made by Embedded Works.
> Access Point side is a Netgear AC1900 NightHawk. I set it up and using
> Ch153, WPA-PSK, with DHCP enabled.
>
> I'm new in Linux (worked on Windows for most time), so I'm still
> learning.

Unfortunately I can only help with ath10k specific issues, I do not have time to give general Linux support. But I can give you pointers and there are other forums which can help you better with those.

> I used "iw" and "wpa_supplicant" to control the card.
> I failed for scan command at the beginning (posted a message last week
> for help) and fixed by bring up the wlan0 interface (ip link set woan0
> up).
> Then set net key "wpa_passphrase SSID KEY"
> Start wpa with command: "wpa_supplicant -B -D nl80211 -i wlan0 -c
> /etc/wpa_supplicant.conf".
>
> I actually got the card associated with the AP but couldn't get a
> valid IP address last Friday, so I was working on getting IP address
> issue.
> Then on Monday, I logged in to server and found the card wlan0 is up
> without command "ip link set ...", also the net key was remembered and
> auto associate to AP.
> So something is taking over and doing association automatically for me
> ( I installed metwork-manager, but never use it yet).

If you run wpasupplicant manually you should disable network-manager, otherwise there will be problems. IIRC one issue might be that network-manager automatically disconnects you, which might be the issue you are having.

> You mentioned the card MAC is not a valid one? I though the vender
> should programmed a valid MAC to chip, right?

Yes, the MAC address is stored in EEPROM and the firmware reads it. But older firmwares might not support newer boards and then there will be problems in reading the EEPROM. That's why I recommend using firmware 10.1.467.2-1.

> I used "iw event -r -f" to monitor the debug message, do I have to
> enable something to get the kernel and supplicant log?

wpasupplicant has it's own debug log (-dddt) and kernel log can be read with dmesg. I recommend starting from here:

http://wireless.kernel.org/en/users/Drivers/ath10k/debug
http://wireless.kernel.org/en/users/Documentation/wpa_supplicant

--
Kalle Valo
E-mail confidentiality.
--------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.

Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.

Or if within the US,

Spirent Communications,
26750 Agoura Road, Calabasas, CA, 91302, USA.
Tel No. 1-818-676- 2300


From greearb at candelatech.com  Tue Apr  8 17:11:35 2014
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 08 Apr 2014 14:11:35 -0700
Subject: ath10k: ieee80211_restart_work called with hardware scan in
 progress
In-Reply-To: <CA+BoTQmfBGJxwFnpq+7dE7MgL_db5gkCvRVfhk9YFAAPLZQwHQ@mail.gmail.com>
References: <53399E42.2090504@candelatech.com>
 <CA+BoTQmfBGJxwFnpq+7dE7MgL_db5gkCvRVfhk9YFAAPLZQwHQ@mail.gmail.com>
Message-ID: <53446607.1060609@candelatech.com>

On 03/31/2014 10:32 PM, Michal Kazior wrote:
> On 31 March 2014 18:56, Ben Greear <greearb at candelatech.com> wrote:
>> This came from a customer (demo) system.  Firmware is 10.1.389 based, modified
>> by us.  It has lots of known issues, but I haven't seen the warning
>> below before, and not sure it is specifically a bug with ath10k or not.
> 
> Hmm..

We are seeing crashes that are probably related to this fairly often.

Johannes:  Do you have any suggestion as to how to go about fixing this?

The crash we just saw looks like this:

BUG: unable to handle kernel paging request at 0000000000007ee0
IP: [<ffffffffa02bde7a>] cfg80211_scan_done+0x16/0x5e [cfg80211]
PGD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: nf_nat_ipv4 nf_nat 8021q garp stp mrp llc fuse macvlan pktgen ip6table_filter ip6_tables ebtable_nat ebtables f71882fg snd_hda_codec_realtek
snd_hda_codec_generic ath9k iTCO_wdt gpio_ich iTCO_vendor_support ppdev ath9k_common ath10k_pci snd_hda_intel ath9k_hw snd_hda_codec coretemp hwmon snd_hwdep
intel_powerclamp snd_seq snd_seq_device ath10k_core ath snd_pcm kvm mac80211 snd_timer snd soundcore cfg80211 i2c_i801 microcode serio_raw pcspkr lpc_ich e1000e
ptp pps_core shpchp parport_pc parport uinput ipv6 i915 i2c_algo_bit drm_kms_helper ata_generic pata_acpi drm i2c_core video [last unloaded: iptable_nat]
CPU: 1 PID: 12693 Comm: kworker/u8:0 Tainted: G        WC 3.14.0-wl-ath+ #7
Hardware name: To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M., BIOS 4.6.3 03/06/2012
Workqueue: phy0 ieee80211_scan_work [mac80211]
task: ffff8800bb1cc980 ti: ffff8800b95de000 task.ti: ffff8800b95de000
RIP: 0010:[<ffffffffa02bde7a>]  [<ffffffffa02bde7a>] cfg80211_scan_done+0x16/0x5e [cfg80211]
RSP: 0018:ffff8800b95dfd68  EFLAGS: 00010206
RAX: 0000000000007e00 RBX: ffff8800bb3f8f00 RCX: 0000000180100000
RDX: 0000000180100001 RSI: 0000000000000000 RDI: 0000000000008000
RBP: ffff8800b95dfd78 R08: ffff88022300cc18 R09: 0000000000000000
R10: ffffffffa03604a7 R11: ffff880205461200 R12: ffff880221775300
R13: ffff88020eefc801 R14: 0000000000000022 R15: ffff880221775328
FS:  0000000000000000(0000) GS:ffff88022bc80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000007ee0 CR3: 0000000001a0d000 CR4: 00000000000007e0
Stack:
 ffff8802217745e0 ffff880221775300 ffff8800b95dfdc8 ffffffffa036050b
 ffff8800b95dfda8 0000000000000292 ffff8800b95dfda8 ffff8802217745e0
 ffff8802217753d8 ffff88020eefc800 ffff880221775300 ffff880221775328
Call Trace:
 [<ffffffffa036050b>] __ieee80211_scan_completed+0xef/0x1a8 [mac80211]
 [<ffffffffa03611b8>] ieee80211_scan_work+0x3e4/0x3fb [mac80211]
 [<ffffffffa037e82a>] ? sdata_unlock+0xd/0xf [mac80211]
 [<ffffffff810d52af>] process_one_work+0x162/0x216
 [<ffffffff810d5724>] worker_thread+0x12f/0x1fd
 [<ffffffff810d55f5>] ? rescuer_thread+0x268/0x268
 [<ffffffff810d55f5>] ? rescuer_thread+0x268/0x268
 [<ffffffff810da37f>] kthread+0xa0/0xa8
 [<ffffffff810da2df>] ? __kthread_parkme+0x5c/0x5c
 [<ffffffff815b5f8c>] ret_from_fork+0x7c/0xb0
 [<ffffffff810da2df>] ? __kthread_parkme+0x5c/0x5c
Code: fe ff ff 48 83 c4 28 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 55 48 89 e5 41 54 41 88 f4 53 48 89 fb 48 8b 7f 40 e8 1a f3 ff ff <48> 3b 98 e0 00 00 00 74
11 be f1 00 00 00 48 c7 c7 4b 94 2d a0
RIP  [<ffffffffa02bde7a>] cfg80211_scan_done+0x16/0x5e [cfg80211]
 RSP <ffff8800b95dfd68>
CR2: 0000000000007ee0
ath10k: Creating vdev id: 30  map: 3221225472
ath10k: mac vdev create 30 (add interface) type 2 subtype 0
Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 1
Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
drm_kms_helper: panic occurred, switching back to text console
Rebooting in 10 seconds..


Thanks,
Ben

> 
> 
>> Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108)
>> Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108)
>> Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108)
>> Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108)
>> Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108)
>> Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108)
> 
> -108 = ESHUTDOWN. This can be a result of calling ath10k_halt() IOW
> driver is stopping by mac80211 request or ath10k_core_restart() was
> called. I suppose the latter is the case here.
> 
> ath10k_halt() calls ieee80211_scan_completed(hw, true) if necessary.
> But since it only sets 1 or 2 bits in local->scanning in mac80211 and
> schedules local->scan_work I suspect you can end up having
> local->restart_work scheduled sooner in some cases (both use different
> workqueues: scan_work uses per-hw queue, restart_work uses global
> system queue) and see the following:
> 
>> Mar 31 13:49:54 ct521-5332 kernel: ieee80211_restart_work called with hardware scan in progress
>> Mar 31 13:49:54 ct521-5332 kernel: Modules linked in: nf_nat_ipv4 nf_nat fuse 8021q mrp garp stp llc macvlan pktgen coretemp hwmon sunrpc ipv6 uinput
>> snd_hda_codec_realtek snd_hda_codec_generic ath10k_pci ath10k_core snd_hda_intel mac80211 snd_hda_codec snd_hwdep snd_seq snd_seq_device iTCO_wdt e1000e
>> microcode ath gpio_ich snd_pcm iTCO_vendor_support ppdev ptp snd_timer parport_pc snd cfg80211 parport serio_raw pps_core soundcore pcspkr i2c_i801 lpc_ich i915
>> drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: iptable_nat]
>> Mar 31 13:49:54 ct521-5332 kernel: CPU: 0 PID: 11818 Comm: kworker/0:0 Tainted: G        WC   3.14.0-rc7-wl-ath+ #4
>> Mar 31 13:49:54 ct521-5332 kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M., BIOS 4.6.3 09/05/2011
>> Mar 31 13:49:54 ct521-5332 kernel: Workqueue: events ieee80211_restart_work [mac80211]
>> Mar 31 13:49:54 ct521-5332 kernel: 0000000000000009 ffff8800bd865d68 ffffffff815ab0a5 ffff88022bc0ec38
>> Mar 31 13:49:54 ct521-5332 kernel: ffff8800bd865db8 ffff8800bd865da8 ffffffff810c1aa8 ffff8800bd865d88
>> Mar 31 13:49:54 ct521-5332 kernel: ffffffffa03858ce ffff8802214d5650 ffff8802214d45e0 ffff8802214d5650
>> Mar 31 13:49:54 ct521-5332 kernel: Call Trace:
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff815ab0a5>] dump_stack+0x4e/0x71
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810c1aa8>] warn_slowpath_common+0x77/0x91
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffffa03858ce>] ? ieee80211_restart_work+0x49/0x68 [mac80211]
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810c1b56>] warn_slowpath_fmt+0x41/0x43
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffffa03858ce>] ieee80211_restart_work+0x49/0x68 [mac80211]
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810d52af>] process_one_work+0x162/0x216
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810d5724>] worker_thread+0x12f/0x1fd
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810d55f5>] ? rescuer_thread+0x268/0x268
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810d55f5>] ? rescuer_thread+0x268/0x268
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810da37f>] kthread+0xa0/0xa8
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810da2df>] ? __kthread_parkme+0x5c/0x5c
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff815b5b4c>] ret_from_fork+0x7c/0xb0
>> Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810da2df>] ? __kthread_parkme+0x5c/0x5c
>> Mar 31 13:49:54 ct521-5332 kernel: ---[ end trace fd8ccdaa79168e68 ]---
> 
> It seems to me that any mac80211-driver can hit this as long as it
> requests a restart during a scan while something queued via
> ieee80211_queue_work() blocks (that something could be driver worker)
> long enough.


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From apenwarr at gmail.com  Tue Apr  8 19:56:36 2014
From: apenwarr at gmail.com (Avery Pennarun)
Date: Tue, 8 Apr 2014 19:56:36 -0400
Subject: ath10k FAQ
In-Reply-To: <8761mkmfny.fsf@kamboji.qca.qualcomm.com>
References: <8761mkmfny.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CAHqTa-1DMgZBW9aqHEXjEy=PWytk88S-kiy3kOqtiGDWLi==cA@mail.gmail.com>

On Tue, Apr 8, 2014 at 3:41 AM, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> I created a small FAQ to the wiki and added the four questions which
> seem to be popular:
>
> http://wireless.kernel.org/en/users/Drivers/ath10k/faq
>
> Comments welcome. And feel free to update it with new questions.

This seems helpful.  For the first question ("can't set channel") I
think the provided answer is not the only cause of the problem, and
was not the one that confused me at first.  For me, the main confusion
was that it's pretty non-intuitive how to set the 80 MHz center
frequency in hostapd.conf ("the center frequency of the channel 6
higher than the lowest channel number in the 4-channel group").  It
might help if you could include an example for that.  I guess it
varies by country so it might be a little tricky.

Have fun,

Avery


From yeohchunyeow at gmail.com  Tue Apr  8 22:47:33 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Wed, 9 Apr 2014 10:47:33 +0800
Subject: WDS and adhoc support with ath10k
In-Reply-To: <603DB158-F608-47C8-AEE8-F0FCFD563699@gmail.com>
References: <603DB158-F608-47C8-AEE8-F0FCFD563699@gmail.com>
Message-ID: <CAEFj984HyGGfWHNdpAkv4X0k=SBDu+ST9CyBdrfciXn8AZXgrw@mail.gmail.com>

> Could someone confirm if WDS and adhoc mode currently don't have support with this driver?

adhoc is working but not perfect, such as rate control not working, no
HT/VHT rate, and etc. You need to use the firmware version
999.999.0.636.

WDS should be working since 4 addresses has fixed by Michal:
http://lists.infradead.org/pipermail/ath10k/2014-February/001191.html

---
Chun-Yeow


From yeohchunyeow at gmail.com  Tue Apr  8 23:11:32 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Wed, 9 Apr 2014 11:11:32 +0800
Subject: For Help: problems with tx bitrate in ath10k
In-Reply-To: <5343B89E.2090407@dhc.com.cn>
References: <5343B89E.2090407@dhc.com.cn>
Message-ID: <CAEFj984QK4+-P39YUEvZekNk-TViYwDTR1QweZvWUkHF2wtoCw@mail.gmail.com>

Need firmware change to get proper Tx rate as pointed out by Kalle
Valo. So no support for the time being.

http://lists.infradead.org/pipermail/ath10k/2014-March/001587.html

----
Chun-Yeow

On Tue, Apr 8, 2014 at 4:51 PM, wangdc <wangdc at dhc.com.cn> wrote:
> Hi,all
>
> I used the backports-3.13.2-1 to drive a 11ac card(WLE900VX) on the ubuntu
> 12.04 LTS(64bit) (3.8.0-35-generic).
> The card seemed to be working well when i connected it to a broadcom AC APs
> and the card could also send or receive data normally.
> But when using command 'iw dev wlan0 station dump' to check the actual Rx
> and Tx rate, i couldn't get the tx bitrate correctly.
>
> root at ubuntu:~$ iw dev wlan2 station dump
> Station 10:48:b1:e8:17:a6 (on wlan2)
>     inactive time:    28680 ms
>     rx bytes:    903704
>     rx packets:    6747
>     tx bytes:    20731
>     tx packets:    163
>     tx retries:    1969
>     tx failed:    0
>     signal:      -36 dBm
>     signal avg:    -36 dBm
>     tx bitrate:     MCS 32 40Mhz short GI
>     authorized:    yes
>     authenticated:    yes
>     preamble:    long
>     WMM/WME:    yes
>     MFP:        no
>     TDLS peer:        no
>
> And sometimes the tx bitrate was 3693.3 MBit/s, 65.0 MBit/s, 6.5Mbit/s etc.
>
> The start log as following.
>
> root at ubuntu:~$ dmesg | grep ath
> [    0.800424] MODSIGN: Loaded cert 'Magrathea: Glacier signing key:
> c77318d5b035f7cbfa665f640863f8bc32a3fa33'
> [   10.539694] ath10k_pci 0000:04:00.0: BAR 0: assigned [mem
> 0xf0400000-0xf05fffff 64bit]
> [   10.886386] ath10k: MSI-X didn't succeed (1), trying MSI
> [   10.886454] ath10k_pci 0000:04:00.0: irq 44 for MSI/MSI-X
> [   10.886492] ath10k: MSI interrupt handling
> [   10.921722] ath10k: Hardware name qca988x hw2.0 version 0x4100016c
> [   12.246510] ath10k: UART prints disabled
> [   12.250960] ath10k: firmware 10.1.467.2-1 booted
> [   12.260459] ath10k: htt target version 2.1
> [   12.261559] ath: EEPROM regdomain: 0x0
> [   12.261561] ath: EEPROM indicates default country code should be used
> [   12.261562] ath: doing EEPROM country->regdmn map search
> [   12.261563] ath: country maps to regdmn code: 0x3a
> [   12.261565] ath: Country alpha2 being used: US
> [   12.261566] ath: Regpair used: 0x3a
> [   18.767377] ath10k: MSI-X didn't succeed (1), trying MSI
> [   18.767451] ath10k_pci 0000:04:00.0: irq 44 for MSI/MSI-X
> [   18.767496] ath10k: MSI interrupt handling
> [   19.700523] ath10k: UART prints disabled
> [   19.705037] ath10k: firmware 10.1.467.2-1 booted
> [   19.714921] ath10k: htt target version 2.1
> ...
>
> root at ubuntu:~$ dmesg
> [  121.846056] ------------[ cut here ]------------
> [  121.846090] WARNING: at /home/backports/net/wireless/util.c:1066
> cfg80211_calculate_bitrate+0x18e/0x210 [cfg80211]()
> [  121.846093] Hardware name: 23066RC
> [  121.846094] Modules linked in: ip_vs(F) nf_conntrack(F) libcrc32c(F)
> bnep(F) rfcomm(F) parport_pc(F) ppdev(F) arc4(F) coretemp(F)
> snd_hda_codec_hdmi(F) snd_hda_codec_realtek(F) ath10k_pci(OF)
> ath10k_core(OF) uvcvideo(F) nfsd(F) snd_hda_intel(F) kvm(F) snd_hda_codec(F)
> ath(OF) videobuf2_core(F) nfs_acl(F) videodev(F) auth_rpcgss(F) i915(F)
> nfs(F) videobuf2_vmalloc(F) snd_hwdep(F) btusb(F) snd_pcm(F) mac80211(OF)
> videobuf2_memops(F) joydev(F) fscache(F) bluetooth(F) ghash_clmulni_intel(F)
> thinkpad_acpi(F) lockd(F) snd_seq_midi(F) cryptd(F) drm_kms_helper(F)
> binfmt_misc(F) snd_rawmidi(F) drm(F) snd_seq_midi_event(F) cfg80211(OF)
> sunrpc(F) snd_seq(F) psmouse(F) snd_timer(F) snd_seq_device(F) mei(F) snd(F)
> microcode(F) serio_raw(F) mac_hid(F) i2c_algo_bit(F) snd_page_alloc(F)
> compat(OF) soundcore(F) lpc_ich(F) nvram(F) wmi(F) video(F) lp(F) parport(F)
> sdhci_pci(F) sdhci(F) e1000e(F)
> [  121.846157] Pid: 1050, comm: NetworkManager Tainted: GF O
> 3.8.0-35-generic #52~precise1-Ubuntu
> [  121.846159] Call Trace:
> [  121.846171]  [<ffffffff81059b6f>] warn_slowpath_common+0x7f/0xc0
> [  121.846177]  [<ffffffff81059bca>] warn_slowpath_null+0x1a/0x20
> [  121.846193]  [<ffffffffa019c8de>] cfg80211_calculate_bitrate+0x18e/0x210
> [cfg80211]
> [  121.846212]  [<ffffffffa01a99a7>] nl80211_put_sta_rate+0x57/0x2a0
> [cfg80211]
> [  121.846229]  [<ffffffffa01ac0e1>]
> nl80211_send_station.isra.63+0x4a1/0x870 [cfg80211]
> [  121.846246]  [<ffffffffa01ac98c>] nl80211_get_station+0x22c/0x290
> [cfg80211]
> [  121.846254]  [<ffffffff8160f6dd>] genl_rcv_msg+0x22d/0x2b0
> [  121.846260]  [<ffffffff815d830b>] ? __alloc_skb+0x8b/0x2a0
> [  121.846264]  [<ffffffff8160f4b0>] ? genl_rcv+0x40/0x40
> [  121.846270]  [<ffffffff8160ee89>] netlink_rcv_skb+0xa9/0xd0
> [  121.846274]  [<ffffffff8160f495>] genl_rcv+0x25/0x40
> [  121.846279]  [<ffffffff8160e7d1>] netlink_unicast+0x1b1/0x230
> [  121.846285]  [<ffffffff8160eb4e>] netlink_sendmsg+0x2fe/0x3b0
> [  121.846290]  [<ffffffff815cb282>] sock_sendmsg+0xd2/0xf0
> [  121.846296]  [<ffffffff815cdb8a>] ? move_addr_to_kernel+0x5a/0xa0
> [  121.846300]  [<ffffffff815da406>] ? verify_iovec+0x56/0xd0
> [  121.846305]  [<ffffffff815cd09c>] ___sys_sendmsg+0x3ac/0x3c0
> [  121.846311]  [<ffffffff811aea86>] ? pollwake+0x66/0x70
> [  121.846316]  [<ffffffff81092050>] ? try_to_wake_up+0x200/0x200
> [  121.846323]  [<ffffffff816f53e5>] ? _raw_spin_lock_irq+0x15/0x20
> [  121.846327]  [<ffffffff81092050>] ? try_to_wake_up+0x200/0x200
> [  121.846332]  [<ffffffff815ceba9>] __sys_sendmsg+0x49/0x90
> [  121.846337]  [<ffffffff815cec09>] sys_sendmsg+0x19/0x20
> [  121.846343]  [<ffffffff816fdf5d>] system_call_fastpath+0x1a/0x1f
> [  121.846346] ---[ end trace fc50900f4228222f ]---
>
> About the reason of the warning info above,
> when debugging the code, rate->flags was 0x0 and the rate->mcs value was
> more than 32 in the function of cfg80211_calculate_bitrate,
> but i didn't know why i got a wrong rate value.
>
> /home/backports/net/wireless/util.c
> u32 cfg80211_calculate_bitrate(struct rate_info *rate)
> {
>     int modulation, streams, bitrate;
>
>     if (!(rate->flags & RATE_INFO_FLAGS_MCS) &&
>         !(rate->flags & RATE_INFO_FLAGS_VHT_MCS))
>         return rate->legacy;
>     if (rate->flags & RATE_INFO_FLAGS_60G)
>         return cfg80211_calculate_bitrate_60g(rate);
>     if (rate->flags & RATE_INFO_FLAGS_VHT_MCS)
>         return cfg80211_calculate_bitrate_vht(rate);
>
>     /* the formula below does only work for MCS values smaller than 32 */
>     if (WARN_ON_ONCE(rate->mcs >= 32))
>         return 0;
>
> I tried other version of the firmware and backports, the test results were
> as following:
> a)The problem repeated when i tried firmware-2.bin_999.999.0.636.
> b)The tx bitrate was fixed to 6MBit/s  and there was no warning info in the
> boot log  when i adopted the latest development
> releases(backports-20140221).
>
> Is there anybody meets the same problem? If so, please give me some
> suggestion on getting Tx rate properly.
>
> Thanks.
> Rex
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From michal.kazior at tieto.com  Wed Apr  9 02:25:11 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 9 Apr 2014 08:25:11 +0200
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <53441D95.9000409@candelatech.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <5341F1A9.2030202@candelatech.com>
 <CA+BoTQndgEB7X-RUPPkxdjnp96LJzbv6=Q9K4XTTrky-QwE4Ww@mail.gmail.com>
 <53435F89.60500@candelatech.com>
 <CA+BoTQk6G4-h8HQENbK9snrXo6j6FW4D+07XKZMEEuvWiu03ww@mail.gmail.com>
 <53441D95.9000409@candelatech.com>
Message-ID: <CA+BoTQkCDiUiV7dsg-myOZXQEB=B7JHH8NWm5BHsp1xExjLkSA@mail.gmail.com>

On 8 April 2014 18:02, Ben Greear <greearb at candelatech.com> wrote:
> On 04/07/2014 10:51 PM, Michal Kazior wrote:
>> On 8 April 2014 04:31, Ben Greear <greearb at candelatech.com> wrote:
>>> On 04/07/2014 02:11 AM, Michal Kazior wrote:
>>>
>>>> These logs are not enough. I'd love to see traces for this to see what
>>>> frames are actually submitted and when tx credits are replenished.
>>>>
>>>> I also wonder if this can be somehow related to your FW changes to
>>>> allow connecting multiple client virtual interfaces to a single AP?
>>>
>>>
>>> I think it is unlikely due to my firmware changes...little of that touched
>>> the handling of management frames.  It might very well be a basic problem in
>>> either the firmware or driver when using multiple station VIFS.  I think
>>> that
>>> aside from my testing that code has not been used much.
>>>
>>> Note my followup email that problems started with patch 3/4...not sure you
>>> saw that one or not.  I saw similar failure to associate & get DHCP (and
>>> slow/hung user-space) without the kernel error logs.
>>
>> I did get that mail. It's just that it makes little sense. Patch 3/4
>> simply extends ath10k_flush() to wait for management frames. It
>> shouldn't change behaviour of tx credit starvation which appears to be
>> the case in the logs you provided.
>
> Maybe this causes unexpected waits (under lock) that in turn causes other
> vifs trying to come up at the same time to time out?

Hm... Most stuff is configured while holding conf_mutex and is
completed while it is held. The exception are beacons and mgmt tx.
Perhaps waiting for mgmt tx in ath10k_flush() doesn't interleave mgmt
tx with other commands and ends up starving tx credit sooner.

I'm planning to submit RFTv2 later today with a few fixes.


> It seems easily reproducible, so let me know what sort of logging/tracing
> you would like to see (and how to enable it if it is not trivial)
> and I'll reproduce it and send you the logs.

Additional kernel config:

CONFIG_ATH10K_DEBUG=y
CONFIG_ATH10K_DEBUGFS=y
CONFIG_ATH10K_TRACING=y
CONFIG_MAC80211_MESSAGE_TRACING=y

This probably requires this to be set first:

CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y

(it's in Kernel Hacking)

Once you have this you can use trace-cmd command to gathers logs:

  trace-cmd record -e mac80211 -e cfg80211 -e ath10k

And then perform whatever tortures on ath10k you wish.

This creates trace.dat in your current directory. The file can get
pretty heavy and it might not fit into an email so we might need to
transfer it "out of band" somehow.

If you use wpa_supplicant/hostapd you can pass -T argument to those to
get all their messages into tracing as markers. This way you're able
to get unified logs in one file with correct chronological order.


Micha?


From johannes at sipsolutions.net  Wed Apr  9 03:44:56 2014
From: johannes at sipsolutions.net (Johannes Berg)
Date: Wed, 09 Apr 2014 09:44:56 +0200
Subject: ath10k: ieee80211_restart_work called with hardware scan in
 progress
In-Reply-To: <53446607.1060609@candelatech.com>
 (sfid-20140408_231213_154583_EA8ACCB7)
References: <53399E42.2090504@candelatech.com>
 <CA+BoTQmfBGJxwFnpq+7dE7MgL_db5gkCvRVfhk9YFAAPLZQwHQ@mail.gmail.com>
 <53446607.1060609@candelatech.com> (sfid-20140408_231213_154583_EA8ACCB7)
Message-ID: <1397029496.4964.0.camel@jlt4.sipsolutions.net>

On Tue, 2014-04-08 at 14:11 -0700, Ben Greear wrote:
> On 03/31/2014 10:32 PM, Michal Kazior wrote:
> > On 31 March 2014 18:56, Ben Greear <greearb at candelatech.com> wrote:
> >> This came from a customer (demo) system.  Firmware is 10.1.389 based, modified
> >> by us.  It has lots of known issues, but I haven't seen the warning
> >> below before, and not sure it is specifically a bug with ath10k or not.
> > 
> > Hmm..
> 
> We are seeing crashes that are probably related to this fairly often.
> 
> Johannes:  Do you have any suggestion as to how to go about fixing this?

Abort the hw scan properly before calling hw restart.

johannes



From marek.kwaczynski at tieto.com  Wed Apr  9 04:14:02 2014
From: marek.kwaczynski at tieto.com (Marek Kwaczynski)
Date: Wed,  9 Apr 2014 10:14:02 +0200
Subject: [PATCH 1/2] mac80211: add option to generate CCMP IVs only for mgmt
 frames
Message-ID: <1397031243-24388-1-git-send-email-marek.kwaczynski@tieto.com>

Some chips can encrypt managment frames in HW, but
require generated IV in the frame. Add a key flag
that allows us to achieve this.

Signed-off-by: Marek Kwaczynski <marek.kwaczynski at tieto.com>
---
 include/net/mac80211.h |   16 ++++++++++------
 net/mac80211/tx.c      |    5 +++--
 net/mac80211/wpa.c     |    6 ++++--
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 2de7ff4..c81415f 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1202,14 +1202,18 @@ struct ieee80211_vif *wdev_to_ieee80211_vif(struct wireless_dev *wdev);
  *	fall back to software crypto. Note that this flag deals only with
  *	RX, if your crypto engine can't deal with TX you can also set the
  *	%IEEE80211_KEY_FLAG_SW_MGMT_TX flag to encrypt such frames in SW.
+ * @IEEE80211_KEY_FLAG_GENERATE_MGMT_IV: This flag should be set by the
+ *	driver for a CCMP key to indicate that is requires IV generation
+ *	only for managment frames (MFP).
  */
 enum ieee80211_key_flags {
-	IEEE80211_KEY_FLAG_GENERATE_IV	= 1<<1,
-	IEEE80211_KEY_FLAG_GENERATE_MMIC= 1<<2,
-	IEEE80211_KEY_FLAG_PAIRWISE	= 1<<3,
-	IEEE80211_KEY_FLAG_SW_MGMT_TX	= 1<<4,
-	IEEE80211_KEY_FLAG_PUT_IV_SPACE = 1<<5,
-	IEEE80211_KEY_FLAG_RX_MGMT	= 1<<6,
+	IEEE80211_KEY_FLAG_GENERATE_IV		= 1<<1,
+	IEEE80211_KEY_FLAG_GENERATE_MMIC	= 1<<2,
+	IEEE80211_KEY_FLAG_PAIRWISE		= 1<<3,
+	IEEE80211_KEY_FLAG_SW_MGMT_TX		= 1<<4,
+	IEEE80211_KEY_FLAG_PUT_IV_SPACE		= 1<<5,
+	IEEE80211_KEY_FLAG_RX_MGMT		= 1<<6,
+	IEEE80211_KEY_FLAG_SW_MGMT_IV_TX	= 1<<7,
 };
 
 /**
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 19d36d4..49b19ab 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -625,8 +625,9 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
 				tx->key = NULL;
 			else
 				skip_hw = (tx->key->conf.flags &
-					   IEEE80211_KEY_FLAG_SW_MGMT_TX) &&
-					ieee80211_is_mgmt(hdr->frame_control);
+				      (IEEE80211_KEY_FLAG_SW_MGMT_TX |
+				       IEEE80211_KEY_FLAG_GENERATE_MGMT_IV)) &&
+				       ieee80211_is_mgmt(hdr->frame_control);
 			break;
 		case WLAN_CIPHER_SUITE_AES_CMAC:
 			if (!ieee80211_is_mgmt(hdr->frame_control))
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index b8600e3..a5fe1d9 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -450,8 +450,10 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
 
 	ccmp_pn2hdr(pos, pn, key->conf.keyidx);
 
-	/* hwaccel - with software CCMP header */
-	if (info->control.hw_key)
+	/* hwaccel - with software CCMP header or the HW needs
+	 * generated the IV */
+	if (info->control.hw_key ||
+	    (key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_MGMT_IV))
 		return 0;
 
 	pos += IEEE80211_CCMP_HDR_LEN;
-- 
1.7.9.5


From marek.kwaczynski at tieto.com  Wed Apr  9 04:14:03 2014
From: marek.kwaczynski at tieto.com (Marek Kwaczynski)
Date: Wed,  9 Apr 2014 10:14:03 +0200
Subject: [PATCH 2/2] ath10k: Fix pmf for action frames
In-Reply-To: <1397031243-24388-1-git-send-email-marek.kwaczynski@tieto.com>
References: <1397031243-24388-1-git-send-email-marek.kwaczynski@tieto.com>
Message-ID: <1397031243-24388-2-git-send-email-marek.kwaczynski@tieto.com>

Fix sending and receiveing protected managment frames.
Lack of protected flag for received protected action frames
causes report these frames as unprotected robust action frames.
If the driver in AP mode sent frames with protected flag and
CCMP header using IEEE80211_KEY_FLAG_SW_MGMT_TX flag,
the FW encrypted frames once again. From user side all
received SA Query Requests and Responses were skipped and
all protected action frames were sent as malformed packets.

Signed-off-by: Marek Kwaczynski <marek.kwaczynski at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c |    5 ++++-
 drivers/net/wireless/ath/ath10k/wmi.c |   23 +++++++++++++++++++----
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 58ec5a7..5fa6ace 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -54,7 +54,10 @@ static int ath10k_send_key(struct ath10k_vif *arvif,
 	switch (key->cipher) {
 	case WLAN_CIPHER_SUITE_CCMP:
 		arg.key_cipher = WMI_CIPHER_AES_CCM;
-		key->flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
+		if (arvif->vdev_type == WMI_VDEV_TYPE_AP)
+			key->flags |= IEEE80211_KEY_FLAG_GENERATE_MGMT_IV;
+		else
+			key->flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
 		break;
 	case WLAN_CIPHER_SUITE_TKIP:
 		arg.key_cipher = WMI_CIPHER_TKIP;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index d4b48ef..c09f2fe 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -639,6 +639,7 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 	struct sk_buff *wmi_skb;
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	int len;
+	u32 buf_len = skb->len;
 	u16 fc;
 
 	hdr = (struct ieee80211_hdr *)skb->data;
@@ -648,6 +649,15 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 		return -EINVAL;
 
 	len = sizeof(cmd->hdr) + skb->len;
+
+	if ((ieee80211_is_action(hdr->frame_control) ||
+	     ieee80211_is_deauth(hdr->frame_control) ||
+	     ieee80211_is_disassoc(hdr->frame_control)) &&
+	     ieee80211_has_protected(hdr->frame_control)) {
+		len += IEEE80211_CCMP_MIC_LEN;
+		buf_len += IEEE80211_CCMP_MIC_LEN;
+	}
+
 	len = round_up(len, 4);
 
 	wmi_skb = ath10k_wmi_alloc_skb(len);
@@ -659,7 +669,7 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 	cmd->hdr.vdev_id = __cpu_to_le32(ATH10K_SKB_CB(skb)->vdev_id);
 	cmd->hdr.tx_rate = 0;
 	cmd->hdr.tx_power = 0;
-	cmd->hdr.buf_len = __cpu_to_le32((u32)(skb->len));
+	cmd->hdr.buf_len = __cpu_to_le32(buf_len);
 
 	memcpy(cmd->hdr.peer_macaddr.addr, ieee80211_get_DA(hdr), ETH_ALEN);
 	memcpy(cmd->buf, skb->data, skb->len);
@@ -957,10 +967,15 @@ static int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
 	 * frames with Protected Bit set. */
 	if (ieee80211_has_protected(hdr->frame_control) &&
 	    !ieee80211_is_auth(hdr->frame_control)) {
-		status->flag |= RX_FLAG_DECRYPTED | RX_FLAG_IV_STRIPPED |
-				RX_FLAG_MMIC_STRIPPED;
-		hdr->frame_control = __cpu_to_le16(fc &
+		status->flag |= RX_FLAG_DECRYPTED;
+
+		if (!ieee80211_is_action(hdr->frame_control) &&
+		    !ieee80211_is_deauth(hdr->frame_control) &&
+		    !ieee80211_is_disassoc(hdr->frame_control)) {
+			status->flag |= RX_FLAG_IV_STRIPPED | RX_FLAG_MMIC_STRIPPED;
+			hdr->frame_control = __cpu_to_le16(fc &
 					~IEEE80211_FCTL_PROTECTED);
+		}
 	}
 
 	ath10k_dbg(ATH10K_DBG_MGMT,
-- 
1.7.9.5



From marek.kwaczynski at tieto.com  Wed Apr  9 04:57:36 2014
From: marek.kwaczynski at tieto.com (Marek Kwaczynski)
Date: Wed,  9 Apr 2014 10:57:36 +0200
Subject: [PATCH v2 1/2] mac80211: add option to generate CCMP IVs only for
 mgmt frames
Message-ID: <1397033857-2523-1-git-send-email-marek.kwaczynski@tieto.com>

Some chips can encrypt managment frames in HW, but
require generated IV in the frame. Add a key flag
that allows us to achieve this.

Signed-off-by: Marek Kwaczynski <marek.kwaczynski at tieto.com>
---

v2: fix missed prefix

 include/net/mac80211.h |   16 ++++++++++------
 net/mac80211/tx.c      |    5 +++--
 net/mac80211/wpa.c     |    7 +++++--
 3 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 2de7ff4..77689ca 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1202,14 +1202,18 @@ struct ieee80211_vif *wdev_to_ieee80211_vif(struct wireless_dev *wdev);
  *	fall back to software crypto. Note that this flag deals only with
  *	RX, if your crypto engine can't deal with TX you can also set the
  *	%IEEE80211_KEY_FLAG_SW_MGMT_TX flag to encrypt such frames in SW.
+ * @IEEE80211_KEY_FLAG_GENERATE_MGMT_IV_TX: This flag should be set by the
+ *	driver for a CCMP key to indicate that is requires IV generation
+ *	only for managment frames (MFP).
  */
 enum ieee80211_key_flags {
-	IEEE80211_KEY_FLAG_GENERATE_IV	= 1<<1,
-	IEEE80211_KEY_FLAG_GENERATE_MMIC= 1<<2,
-	IEEE80211_KEY_FLAG_PAIRWISE	= 1<<3,
-	IEEE80211_KEY_FLAG_SW_MGMT_TX	= 1<<4,
-	IEEE80211_KEY_FLAG_PUT_IV_SPACE = 1<<5,
-	IEEE80211_KEY_FLAG_RX_MGMT	= 1<<6,
+	IEEE80211_KEY_FLAG_GENERATE_IV		= 1<<1,
+	IEEE80211_KEY_FLAG_GENERATE_MMIC	= 1<<2,
+	IEEE80211_KEY_FLAG_PAIRWISE		= 1<<3,
+	IEEE80211_KEY_FLAG_SW_MGMT_TX		= 1<<4,
+	IEEE80211_KEY_FLAG_PUT_IV_SPACE		= 1<<5,
+	IEEE80211_KEY_FLAG_RX_MGMT		= 1<<6,
+	IEEE80211_KEY_FLAG_GENERATE_MGMT_IV_TX	= 1<<7,
 };
 
 /**
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 19d36d4..8a49272 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -625,8 +625,9 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
 				tx->key = NULL;
 			else
 				skip_hw = (tx->key->conf.flags &
-					   IEEE80211_KEY_FLAG_SW_MGMT_TX) &&
-					ieee80211_is_mgmt(hdr->frame_control);
+				   (IEEE80211_KEY_FLAG_SW_MGMT_TX |
+				    IEEE80211_KEY_FLAG_GENERATE_MGMT_IV_TX)) &&
+				    ieee80211_is_mgmt(hdr->frame_control);
 			break;
 		case WLAN_CIPHER_SUITE_AES_CMAC:
 			if (!ieee80211_is_mgmt(hdr->frame_control))
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index b8600e3..2ef2e40 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -450,8 +450,11 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
 
 	ccmp_pn2hdr(pos, pn, key->conf.keyidx);
 
-	/* hwaccel - with software CCMP header */
-	if (info->control.hw_key)
+	/* hwaccel - with software CCMP header or the HW needs
+	 * generated the IV
+	 */
+	if (info->control.hw_key ||
+	    (key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_MGMT_IV_TX))
 		return 0;
 
 	pos += IEEE80211_CCMP_HDR_LEN;
-- 
1.7.9.5



From marek.kwaczynski at tieto.com  Wed Apr  9 04:57:37 2014
From: marek.kwaczynski at tieto.com (Marek Kwaczynski)
Date: Wed,  9 Apr 2014 10:57:37 +0200
Subject: [PATCH v2 2/2] ath10k: Fix pmf for action frames
In-Reply-To: <1397033857-2523-1-git-send-email-marek.kwaczynski@tieto.com>
References: <1397033857-2523-1-git-send-email-marek.kwaczynski@tieto.com>
Message-ID: <1397033857-2523-2-git-send-email-marek.kwaczynski@tieto.com>

Fix sending and receiveing protected managment frames.
Lack of protected flag for received protected action frames
causes report these frames as unprotected robust action frames.
If the driver in AP mode sent frame with protected flag and
CCMP header using IEEE80211_KEY_FLAG_SW_MGMT_TX flag,
the FW encrypted frames once again. From user side all
received SA Query Requests and Responses were skipped and
all protected action frames were sent as malformed packets.

Signed-off-by: Marek Kwaczynski <marek.kwaczynski at tieto.com>
---

v2: fix missed prefix

 drivers/net/wireless/ath/ath10k/mac.c |    5 ++++-
 drivers/net/wireless/ath/ath10k/wmi.c |   24 ++++++++++++++++++++----
 2 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 58ec5a7..0c66c18 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -54,7 +54,10 @@ static int ath10k_send_key(struct ath10k_vif *arvif,
 	switch (key->cipher) {
 	case WLAN_CIPHER_SUITE_CCMP:
 		arg.key_cipher = WMI_CIPHER_AES_CCM;
-		key->flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
+		if (arvif->vdev_type == WMI_VDEV_TYPE_AP)
+			key->flags |= IEEE80211_KEY_FLAG_GENERATE_MGMT_IV_TX;
+		else
+			key->flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
 		break;
 	case WLAN_CIPHER_SUITE_TKIP:
 		arg.key_cipher = WMI_CIPHER_TKIP;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index d4b48ef..6d8a097 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -639,6 +639,7 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 	struct sk_buff *wmi_skb;
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	int len;
+	u32 buf_len = skb->len;
 	u16 fc;
 
 	hdr = (struct ieee80211_hdr *)skb->data;
@@ -648,6 +649,15 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 		return -EINVAL;
 
 	len = sizeof(cmd->hdr) + skb->len;
+
+	if ((ieee80211_is_action(hdr->frame_control) ||
+	     ieee80211_is_deauth(hdr->frame_control) ||
+	     ieee80211_is_disassoc(hdr->frame_control)) &&
+	     ieee80211_has_protected(hdr->frame_control)) {
+		len += IEEE80211_CCMP_MIC_LEN;
+		buf_len += IEEE80211_CCMP_MIC_LEN;
+	}
+
 	len = round_up(len, 4);
 
 	wmi_skb = ath10k_wmi_alloc_skb(len);
@@ -659,7 +669,7 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 	cmd->hdr.vdev_id = __cpu_to_le32(ATH10K_SKB_CB(skb)->vdev_id);
 	cmd->hdr.tx_rate = 0;
 	cmd->hdr.tx_power = 0;
-	cmd->hdr.buf_len = __cpu_to_le32((u32)(skb->len));
+	cmd->hdr.buf_len = __cpu_to_le32(buf_len);
 
 	memcpy(cmd->hdr.peer_macaddr.addr, ieee80211_get_DA(hdr), ETH_ALEN);
 	memcpy(cmd->buf, skb->data, skb->len);
@@ -957,10 +967,16 @@ static int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
 	 * frames with Protected Bit set. */
 	if (ieee80211_has_protected(hdr->frame_control) &&
 	    !ieee80211_is_auth(hdr->frame_control)) {
-		status->flag |= RX_FLAG_DECRYPTED | RX_FLAG_IV_STRIPPED |
-				RX_FLAG_MMIC_STRIPPED;
-		hdr->frame_control = __cpu_to_le16(fc &
+		status->flag |= RX_FLAG_DECRYPTED;
+
+		if (!ieee80211_is_action(hdr->frame_control) &&
+		    !ieee80211_is_deauth(hdr->frame_control) &&
+		    !ieee80211_is_disassoc(hdr->frame_control)) {
+			status->flag |= RX_FLAG_IV_STRIPPED |
+					RX_FLAG_MMIC_STRIPPED;
+			hdr->frame_control = __cpu_to_le16(fc &
 					~IEEE80211_FCTL_PROTECTED);
+		}
 	}
 
 	ath10k_dbg(ATH10K_DBG_MGMT,
-- 
1.7.9.5



From michal.kazior at tieto.com  Wed Apr  9 06:01:24 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:01:24 +0200
Subject: [PATCH 3/4] ath10k: prevent beacon memory leak
In-Reply-To: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
References: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397037685-7485-4-git-send-email-michal.kazior@tieto.com>

If DMA mapping of next beacon failed ath10k leaked
the beacon.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 35c7d52..ca51f17 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1450,6 +1450,7 @@ static void ath10k_wmi_event_host_swba(struct ath10k *ar, struct sk_buff *skb)
 					ATH10K_SKB_CB(bcn)->paddr);
 		if (ret) {
 			ath10k_warn("failed to map beacon: %d\n", ret);
+			dev_kfree_skb_any(bcn);
 			goto skip;
 		}
 
-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:01:22 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:01:22 +0200
Subject: [PATCH 1/4] ath10k: make sure to not leak beacon dma mapping
In-Reply-To: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
References: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397037685-7485-2-git-send-email-michal.kazior@tieto.com>

If for some reason mac80211 wouldn't stop
beaconing gracefully and just removed interface of
a running AP/IBSS interface it was possible to
leak pending beacon DMA mapping. It's very
unlikely but better safe than sorry.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 58ec5a7..5a9da3a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2738,6 +2738,9 @@ static void ath10k_remove_interface(struct ieee80211_hw *hw,
 
 	spin_lock_bh(&ar->data_lock);
 	if (arvif->beacon) {
+		dma_unmap_single(arvif->ar->dev,
+				 ATH10K_SKB_CB(arvif->beacon)->paddr,
+				 arvif->beacon->len, DMA_TO_DEVICE);
 		dev_kfree_skb_any(arvif->beacon);
 		arvif->beacon = NULL;
 	}
-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:01:23 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:01:23 +0200
Subject: [PATCH 2/4] ath10k: make sure to not use invalid beacon pointer
In-Reply-To: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
References: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397037685-7485-3-git-send-email-michal.kazior@tieto.com>

If DMA mapping of next beacon failed it was
possible for next SWBA to access a pointer that
was already unmapped and freed. This could cause
memory corruption.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index d4b48ef..35c7d52 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1441,6 +1441,8 @@ static void ath10k_wmi_event_host_swba(struct ath10k *ar, struct sk_buff *skb)
 			dev_kfree_skb_any(arvif->beacon);
 		}
 
+		arvif->beacon = NULL;
+
 		ATH10K_SKB_CB(bcn)->paddr = dma_map_single(arvif->ar->dev,
 							   bcn->data, bcn->len,
 							   DMA_TO_DEVICE);
-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:01:21 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:01:21 +0200
Subject: [PATCH 0/4] ath10k: AP-related fixes
Message-ID: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>

Hi,

This is a bunch of fixes I've found while
investigating tx credit issues.

I've only experienced problem fixed by 4/4
firsthand. Other patches are preemptive fixes :-)


Michal Kazior (4):
  ath10k: make sure to not leak beacon dma mapping
  ath10k: make sure to not use invalid beacon pointer
  ath10k: prevent beacon memory leak
  ath10k: fix firmware recovery with ap interface

 drivers/net/wireless/ath/ath10k/mac.c | 16 ++++++++++++++++
 drivers/net/wireless/ath/ath10k/wmi.c |  3 +++
 2 files changed, 19 insertions(+)

-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:01:25 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:01:25 +0200
Subject: [PATCH 4/4] ath10k: fix firmware recovery with ap interface
In-Reply-To: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
References: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397037685-7485-5-git-send-email-michal.kazior@tieto.com>

Beacon data wasn't properly cleared during early
phase of recovery. This in turn caused firmware to
crash because the beacon data was submitted before
vdevs were fully re-configured. Ultimately the
device was considered wedged and nothing worked
until driver was reloaded.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 5a9da3a..143ea1c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2264,6 +2264,8 @@ static void ath10k_tx(struct ieee80211_hw *hw,
  */
 void ath10k_halt(struct ath10k *ar)
 {
+	struct ath10k_vif *arvif;
+
 	lockdep_assert_held(&ar->conf_mutex);
 
 	ath10k_stop_cac(ar);
@@ -2280,6 +2282,17 @@ void ath10k_halt(struct ath10k *ar)
 		ar->scan.in_progress = false;
 		ieee80211_scan_completed(ar->hw, true);
 	}
+
+	list_for_each_entry(arvif, &ar->arvifs, list) {
+		if (!arvif->beacon)
+			continue;
+
+		dma_unmap_single(arvif->ar->dev,
+				 ATH10K_SKB_CB(arvif->beacon)->paddr,
+				 arvif->beacon->len, DMA_TO_DEVICE);
+		dev_kfree_skb_any(arvif->beacon);
+		arvif->beacon = NULL;
+	}
 	spin_unlock_bh(&ar->data_lock);
 }
 
-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:07:06 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:07:06 +0200
Subject: [PATCH 1/3] ath10k: differentiate between target init failures
In-Reply-To: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
References: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397038028-7665-2-git-send-email-michal.kazior@tieto.com>

This just makes it easier to tell apart different
kinds of bringup failure.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/pci.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index bf1083d..cd3b00c 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2464,7 +2464,13 @@ static int ath10k_pci_wait_for_target_init(struct ath10k *ar)
 		mdelay(10);
 	} while (time_before(jiffies, timeout));
 
-	if (val == 0xffffffff || !(val & FW_IND_INITIALIZED)) {
+	if (val == 0xffffffff) {
+		ath10k_err("failed to read device register, device is gone\n");
+		ret = -EIO;
+		goto out;
+	}
+
+	if (!(val & FW_IND_INITIALIZED)) {
 		ath10k_err("failed to receive initialized event from target: %08x\n",
 			   val);
 		ret = -ETIMEDOUT;
-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:07:08 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:07:08 +0200
Subject: [PATCH 3/3] ath10k: skip suspending when recovering
In-Reply-To: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
References: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397038028-7665-4-git-send-email-michal.kazior@tieto.com>

It doesn't make much sense to even try suspending
the device when recovering. Recovering means the
device is unresponsive and waiting for suspend
procedure means taking a 3 second timeout waiting
for tx credits.

This speeds up firmware recovery significantly.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 6abde37..75b3dfb 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -680,8 +680,8 @@ static void ath10k_core_restart(struct work_struct *work)
 
 	switch (ar->state) {
 	case ATH10K_STATE_ON:
-		ath10k_halt(ar);
 		ar->state = ATH10K_STATE_RESTARTING;
+		ath10k_halt(ar);
 		ieee80211_restart_hw(ar->hw);
 		break;
 	case ATH10K_STATE_OFF:
@@ -908,7 +908,9 @@ void ath10k_core_stop(struct ath10k *ar)
 	lockdep_assert_held(&ar->conf_mutex);
 
 	/* try to suspend target */
-	ath10k_wait_for_suspend(ar, WMI_PDEV_SUSPEND_AND_DISABLE_INTR);
+	if (ar->state != ATH10K_STATE_RESTARTING)
+		ath10k_wait_for_suspend(ar, WMI_PDEV_SUSPEND_AND_DISABLE_INTR);
+
 	ath10k_debug_stop(ar);
 	ath10k_htc_stop(&ar->htc);
 	ath10k_htt_detach(&ar->htt);
-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:07:05 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:07:05 +0200
Subject: [PATCH 0/3] ath10k: improve recovery speed
Message-ID: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>

Hi,

Patch 1/3 is just a cleanup I wanted to keep
separate from 2/3 which actually improves recovery
speed.

With this I'm able to recover from a `hard`
simualtion crash in ~3 seconds instead of ~10.

This should decrease the chance of CQM kicking in
on connected clients (due to beacon loss) when
ath10k is acting as AP.


Michal Kazior (3):
  ath10k: differentiate between target init failures
  ath10k: don't wait for device init if it crashed
  ath10k: skip suspending when recovering

 drivers/net/wireless/ath/ath10k/core.c |  6 ++++--
 drivers/net/wireless/ath/ath10k/pci.c  | 17 ++++++++++++++++-
 2 files changed, 20 insertions(+), 3 deletions(-)

-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:07:07 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:07:07 +0200
Subject: [PATCH 2/3] ath10k: don't wait for device init if it crashed
In-Reply-To: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
References: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397038028-7665-3-git-send-email-michal.kazior@tieto.com>

When warm resetting it's possible for device to
crash during initialization. Instead of waiting 3
seconds just return failure as soon as
FW_IND_EVENT_PENDING is set.

This speeds up device bootup and recovery in some
cases.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/pci.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index cd3b00c..8337608 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2452,6 +2452,9 @@ static int ath10k_pci_wait_for_target_init(struct ath10k *ar)
 		if (val == 0xffffffff)
 			continue;
 
+		if (val & FW_IND_EVENT_PENDING)
+			break;
+
 		if (val & FW_IND_INITIALIZED)
 			break;
 
@@ -2470,6 +2473,12 @@ static int ath10k_pci_wait_for_target_init(struct ath10k *ar)
 		goto out;
 	}
 
+	if (val & FW_IND_EVENT_PENDING) {
+		ath10k_warn("device has crashed during init\n");
+		ret = -ECOMM;
+		goto out;
+	}
+
 	if (!(val & FW_IND_INITIALIZED)) {
 		ath10k_err("failed to receive initialized event from target: %08x\n",
 			   val);
-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:48:47 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:48:47 +0200
Subject: [RFTv2 1/5] ath10k: always request htc tx replenishment
In-Reply-To: <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397040531-6224-2-git-send-email-michal.kazior@tieto.com>

This simplifies tx credit management and tries to
address a problem where driver runs out of credits
and is unable to recover when firmware stalls.

This also makes it a little more easy to track and
debug htc tx credit flow since there should be no
laziness involved.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/htc.c | 15 +--------------
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 7f1bccd..c2a290a 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -86,19 +86,6 @@ static void ath10k_htc_notify_tx_completion(struct ath10k_htc_ep *ep,
 	ep->ep_ops.ep_tx_complete(ep->htc->ar, skb);
 }
 
-/* assumes tx_lock is held */
-static bool ath10k_htc_ep_need_credit_update(struct ath10k_htc_ep *ep)
-{
-	if (!ep->tx_credit_flow_enabled)
-		return false;
-	if (ep->tx_credits >= ep->tx_credits_per_max_message)
-		return false;
-
-	ath10k_dbg(ATH10K_DBG_HTC, "HTC: endpoint %d needs credit update\n",
-		   ep->eid);
-	return true;
-}
-
 static void ath10k_htc_prepare_tx_skb(struct ath10k_htc_ep *ep,
 				      struct sk_buff *skb)
 {
@@ -113,7 +100,7 @@ static void ath10k_htc_prepare_tx_skb(struct ath10k_htc_ep *ep,
 	spin_lock_bh(&ep->htc->tx_lock);
 	hdr->seq_no = ep->seq_no++;
 
-	if (ath10k_htc_ep_need_credit_update(ep))
+	if (ep->tx_credit_flow_enabled)
 		hdr->flags |= ATH10K_HTC_FLAG_NEED_CREDIT_UPDATE;
 
 	spin_unlock_bh(&ep->htc->tx_lock);
-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:48:46 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:48:46 +0200
Subject: [RFTv2 0/5] ath10k: ath10k: fix flushing and tx stalls
In-Reply-To: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>

Hi,

After digging around I've found what seems to be
the problem with WMI Tx credit starvation and
inability to properly flush Tx in ath10k_flush().

Long story short: if a client that was asleep (as
per what firmware thinks) goes out of range (or
just stops responding) then Tx rots in FW/HW
queues for a few seconds before it's discarded.
For WMI Tx credits this means management frames
eat up Tx credits for a few seconds (causing other
WMI commands to timeout and return -EAGAIN/-11).
For HTT Tx this means NullFunc frames would get
stuck for a few seconds before completion was
received.

v2:
 * added tx replenishment patch
 * added conf_mutex locking
 * change condition for flushing mgmt tx


Michal Kazior (5):
  ath10k: always request htc tx replenishment
  ath10k: fix wmi-htc tx credit starvation
  ath10k: rework peer accounting
  ath10k: wait for mgmt tx when flushing too
  ath10k: improve tx flushing

 drivers/net/wireless/ath/ath10k/core.h |   7 +-
 drivers/net/wireless/ath/ath10k/htc.c  |  15 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 275 ++++++++++++++++++++++++++++++---
 drivers/net/wireless/ath/ath10k/txrx.c |  29 ++--
 drivers/net/wireless/ath/ath10k/wmi.c  |   5 -
 drivers/net/wireless/ath/ath10k/wmi.h  |   4 +
 6 files changed, 275 insertions(+), 60 deletions(-)

-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:48:50 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:48:50 +0200
Subject: [RFTv2 4/5] ath10k: wait for mgmt tx when flushing too
In-Reply-To: <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397040531-6224-5-git-send-email-michal.kazior@tieto.com>

The 10.1 firmware uses WMI to Tx management frames
but ath10k_flush() didn't care. This could lead to
some frames not being sent.

Although there are no Tx completions for WMI
mangement frames it's still better to at least
wait for ath10k queue to be drained.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index adb5da1..1d95500 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3782,19 +3782,27 @@ static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
 
 	mutex_lock(&ar->conf_mutex);
 
-	if (ar->state == ATH10K_STATE_WEDGED)
+	if (ar->state == ATH10K_STATE_WEDGED) {
+		ret = -EBUSY;
 		goto skip;
+	}
 
 	ret = wait_event_timeout(ar->htt.empty_tx_wq, ({
-			bool empty;
+			bool htt_empty, wmi_empty;
+			unsigned long flags;
 
 			spin_lock_bh(&ar->htt.tx_lock);
-			empty = (ar->htt.num_pending_tx == 0);
+			htt_empty = (ar->htt.num_pending_tx == 0);
 			spin_unlock_bh(&ar->htt.tx_lock);
 
+			spin_lock_irqsave(&ar->wmi_mgmt_tx_queue.lock, flags);
+			wmi_empty = skb_queue_len(&ar->wmi_mgmt_tx_queue) == 0;
+			spin_unlock_irqrestore(&ar->wmi_mgmt_tx_queue.lock,
+					       flags);
+
 			skip = (ar->state == ATH10K_STATE_WEDGED);
 
-			(empty || skip);
+			((htt_empty && wmi_empty) || skip);
 		}), ATH10K_FLUSH_TIMEOUT_HZ);
 
 	if (ret <= 0 || skip)
@@ -3803,6 +3811,11 @@ static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
 
 skip:
 	mutex_unlock(&ar->conf_mutex);
+
+	/* empty mgmt tx queue doesn't mean mgmt tx is flushed because the last
+	 * frame still may be processed by a worker */
+	if (ret > 0 && !skip)
+		cancel_work_sync(&ar->wmi_mgmt_tx_work);
 }
 
 /* TODO: Implement this function properly
-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:48:51 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:48:51 +0200
Subject: [RFTv2 5/5] ath10k: improve tx flushing
In-Reply-To: <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397040531-6224-6-git-send-email-michal.kazior@tieto.com>

Flushing was prone to timeouts when powersaving
clients were involved that went missing while
asleep. The common culprit was NullFunc frame
being stuck in FW/HW queues.

Introduce a two-pass flushing with WMI flush
commands interleaved to force frame drops if
necessary. This allows for a decreased flush
timeout time and should get rid of some warnings.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.h |  2 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 97 +++++++++++++++++++++++++++-------
 drivers/net/wireless/ath/ath10k/wmi.h  |  1 +
 3 files changed, 81 insertions(+), 19 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 61e325a..0d60e70 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -38,7 +38,7 @@
 
 #define ATH10K_SCAN_ID 0
 #define WMI_READY_TIMEOUT (5 * HZ)
-#define ATH10K_FLUSH_TIMEOUT_HZ (5*HZ)
+#define ATH10K_FLUSH_TIMEOUT_HZ (1*HZ)
 #define ATH10K_NUM_CHANS 38
 
 /* Antenna noise floor */
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 1d95500..dc176b5 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3769,25 +3769,31 @@ static int ath10k_set_frag_threshold(struct ieee80211_hw *hw, u32 value)
 	return ret;
 }
 
-static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
+static int ath10k_flush_all_peer_tids(struct ath10k *ar)
 {
-	struct ath10k *ar = hw->priv;
-	bool skip;
+	struct ath10k_peer *peer;
 	int ret;
 
-	/* mac80211 doesn't care if we really xmit queued frames or not
-	 * we'll collect those frames either way if we stop/delete vdevs */
-	if (drop)
-		return;
-
-	mutex_lock(&ar->conf_mutex);
+	lockdep_assert_held(&ar->conf_mutex);
 
-	if (ar->state == ATH10K_STATE_WEDGED) {
-		ret = -EBUSY;
-		goto skip;
+	list_for_each_entry(peer, &ar->peers, list) {
+		ret = ath10k_wmi_peer_flush(ar, peer->vdev_id, peer->addr,
+					    WMI_PEER_TID_ALL_MASK);
+		if (ret) {
+			ath10k_warn("failed to request peer %pM on vdev %i to flush %08x: %d\n",
+				    peer->addr, peer->vdev_id,
+				    WMI_PEER_TID_ALL_MASK, ret);
+			return ret;
+		}
 	}
 
-	ret = wait_event_timeout(ar->htt.empty_tx_wq, ({
+	return 0;
+}
+
+static int ath10k_flush_wait(struct ath10k *ar)
+{
+	bool skip;
+	int ret = wait_event_timeout(ar->htt.empty_tx_wq, ({
 			bool htt_empty, wmi_empty;
 			unsigned long flags;
 
@@ -3805,16 +3811,71 @@ static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
 			((htt_empty && wmi_empty) || skip);
 		}), ATH10K_FLUSH_TIMEOUT_HZ);
 
-	if (ret <= 0 || skip)
-		ath10k_warn("failed to flush transmit queue (skip %i ar-state %i): %i\n",
-			    skip, ar->state, ret);
+	if (ret == 0)
+		ret = -ETIMEDOUT;
+	else if (ret > 0)
+		ret = 0;
+
+	if (skip) {
+		ath10k_warn("ignoring flushing result because hardware is wedged\n");
+		ret = -EBUSY;
+	}
+
+	return ret;
+}
+
+static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
+{
+	struct ath10k *ar = hw->priv;
+	int ret;
+
+	mutex_lock(&ar->conf_mutex);
+
+	if (drop) {
+		ath10k_mgmt_over_wmi_tx_purge(ar);
+
+		ret = ath10k_flush_all_peer_tids(ar);
+		if (ret) {
+			ath10k_warn("failed to flush all peer tids: %d\n", ret);
+			goto out;
+		}
 
-skip:
+		goto out;
+	}
+
+	if (ar->state == ATH10K_STATE_WEDGED) {
+		ath10k_warn("skipping flushing because hardware is wedged\n");
+		ret = -EBUSY;
+		goto out;
+	}
+
+	ret = ath10k_flush_wait(ar);
+	if (ret) {
+		ath10k_dbg(ATH10K_DBG_MAC,
+			   "failed to wait for tx to flush: %d, forcing\n",
+			   ret);
+
+		ath10k_mgmt_over_wmi_tx_purge(ar);
+
+		ret = ath10k_flush_all_peer_tids(ar);
+		if (ret) {
+			ath10k_warn("failed to flush all peer tids: %d\n", ret);
+			goto out;
+		}
+
+		ret = ath10k_flush_wait(ar);
+		if (ret) {
+			ath10k_warn("failed to flush tx: %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
 	mutex_unlock(&ar->conf_mutex);
 
 	/* empty mgmt tx queue doesn't mean mgmt tx is flushed because the last
 	 * frame still may be processed by a worker */
-	if (ret > 0 && !skip)
+	if (ret == 0)
 		cancel_work_sync(&ar->wmi_mgmt_tx_work);
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 90fe2e9..2b37c4a 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -3846,6 +3846,7 @@ struct wmi_peer_delete_cmd {
 
 #define WMI_PEER_TID_MGMT 17
 #define WMI_PEER_TID_MGMT_MASK BIT(WMI_PEER_TID_MGMT)
+#define WMI_PEER_TID_ALL_MASK 0xFFFFFFFF
 
 struct wmi_peer_flush_tids_cmd {
 	__le32 vdev_id;
-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:48:48 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:48:48 +0200
Subject: [RFTv2 2/5] ath10k: fix wmi-htc tx credit starvation
In-Reply-To: <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397040531-6224-3-git-send-email-michal.kazior@tieto.com>

Each WMI management Tx consumes 1 HTC Tx credit
and doesn't replenish it until the frame is
actually transmitted out of firmware's Tx queues.

If associated client was asleep and has gone out
of range then unicast frames won't be released for
FW/HW queues for a while (10 seconds per
observation). This means that if more management
frames are queued then HTC Tx credits are drained
to 0 and no other commands can be submitted
including beacons and peer removal.

This could in turn result in clients disconnecting
due to their beacon loss and may trigger spurious
sta kickouts because wmi peer removal command may
never reach firmware during disassociation.

This could happen, e.g. when disconnecting
client (hostapd inactivity) that has gone away
while asleep when acting as AP.

As a workaround flush frames that can potentialy
get stuck in FW Tx queues.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 96 +++++++++++++++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/wmi.c |  5 --
 drivers/net/wireless/ath/ath10k/wmi.h |  3 ++
 3 files changed, 99 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 58ec5a7..5cfbf88 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2076,9 +2076,67 @@ void ath10k_mgmt_over_wmi_tx_purge(struct ath10k *ar)
 	}
 }
 
+static void ath10k_mgmt_tx_flush(struct ath10k *ar, struct sk_buff *skb)
+{
+	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
+	struct ieee80211_sta *sta;
+	struct ath10k_vif *arvif;
+	u8 *da = ieee80211_get_DA(hdr);
+	u8 vdev_id = ATH10K_SKB_CB(skb)->vdev_id;
+	u32 bcn_intval = 0;
+	unsigned int msecs;
+	int ret;
+
+	lockdep_assert_held(&ar->conf_mutex);
+
+	if (!is_unicast_ether_addr(da))
+		return;
+
+	rcu_read_lock();
+	sta = ieee80211_find_sta_by_ifaddr(ar->hw, da, NULL);
+	rcu_read_unlock();
+
+	/*
+	 * FW Tx queues can be paused only for associated peers. Since this is
+	 * a workaround just assume worst case if station simply entry exists.
+	 */
+	if (!sta)
+		return;
+
+	list_for_each_entry(arvif, &ar->arvifs, list) {
+		if (arvif->vdev_id == vdev_id) {
+			bcn_intval = arvif->beacon_interval;
+			break;
+		}
+	}
+
+	if (!bcn_intval)
+		return;
+
+	/*
+	 * Wait 2 beacon intervals before flushing so stations that are
+	 * asleep but are actually still in range have a chance to see
+	 * updated PVB, wake up and fetch the frame. There's no other way of
+	 * synchronizing other than sleeping because there's no tx completion
+	 * indication event for WMI management tx.
+	 */
+	msecs = 2 * arvif->beacon_interval * 1024 / 1000;
+	ath10k_dbg(ATH10K_DBG_MAC,
+		   "mac flushing peer %pM on vdev %i mgmt tid for unicast mgmt (%d msecs)\n",
+		   da, vdev_id, msecs);
+	msleep(msecs);
+
+	ret = ath10k_wmi_peer_flush(ar, vdev_id, da,
+				    WMI_PEER_TID_MGMT_MASK);
+	if (ret)
+		ath10k_warn("failed to flush peer %pM mgmt tid: %d\n",
+			    da, ret);
+}
+
 void ath10k_mgmt_over_wmi_tx_work(struct work_struct *work)
 {
 	struct ath10k *ar = container_of(work, struct ath10k, wmi_mgmt_tx_work);
+	struct ieee80211_tx_info *info;
 	struct sk_buff *skb;
 	int ret;
 
@@ -2087,12 +2145,50 @@ void ath10k_mgmt_over_wmi_tx_work(struct work_struct *work)
 		if (!skb)
 			break;
 
+		mutex_lock(&ar->conf_mutex);
+
 		ret = ath10k_wmi_mgmt_tx(ar, skb);
 		if (ret) {
 			ath10k_warn("failed to transmit management frame via WMI: %d\n",
 				    ret);
+			mutex_unlock(&ar->conf_mutex);
 			ieee80211_free_txskb(ar->hw, skb);
+			continue;
 		}
+
+		/*
+		 * Each WMI management Tx consumes 1 HTC Tx credit and doesn't
+		 * replenish it until the frame is actually transmitted out of
+		 * firmware's Tx queues.
+		 *
+		 * If associated client was asleep and has gone out of range
+		 * then unicast frames won't be released for FW/HW queues for a
+		 * while (10 seconds per observation). This means that if more
+		 * management frames are queued then HTC Tx credits are drained
+		 * to 0 and no other commands can be submitted including
+		 * beacons and peer removal.
+		 *
+		 * This could in turn result in clients disconnecting due to
+		 * their beacon loss and may trigger spurious sta kickouts
+		 * because wmi peer removal command may never reach firmware
+		 * during disassociation.
+		 *
+		 * This could happen, e.g. when disconnecting client that has
+		 * gone away while asleep.
+		 *
+		 * As a workaround flush unicast management frames that can
+		 * possibly be buffered.
+		 *
+		 * Note: This is a deficiency in design of WMI_MGMT_TX command.
+		 */
+		ath10k_mgmt_tx_flush(ar, skb);
+
+		mutex_unlock(&ar->conf_mutex);
+
+		/* there's no way to get ACK so just assume it's acked */
+		info = IEEE80211_SKB_CB(skb);
+		info->flags |= IEEE80211_TX_STAT_ACK;
+		ieee80211_tx_status(ar->hw, skb);
 	}
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index d4b48ef..3b270a4 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -637,7 +637,6 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 	struct wmi_mgmt_tx_cmd *cmd;
 	struct ieee80211_hdr *hdr;
 	struct sk_buff *wmi_skb;
-	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	int len;
 	u16 fc;
 
@@ -673,10 +672,6 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 	if (ret)
 		return ret;
 
-	/* TODO: report tx status to mac80211 - temporary just ACK */
-	info->flags |= IEEE80211_TX_STAT_ACK;
-	ieee80211_tx_status_irqsafe(ar->hw, skb);
-
 	return ret;
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index ae83822..90fe2e9 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -3844,6 +3844,9 @@ struct wmi_peer_delete_cmd {
 	struct wmi_mac_addr peer_macaddr;
 } __packed;
 
+#define WMI_PEER_TID_MGMT 17
+#define WMI_PEER_TID_MGMT_MASK BIT(WMI_PEER_TID_MGMT)
+
 struct wmi_peer_flush_tids_cmd {
 	__le32 vdev_id;
 	struct wmi_mac_addr peer_macaddr;
-- 
1.8.5.3



From michal.kazior at tieto.com  Wed Apr  9 06:48:49 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed,  9 Apr 2014 12:48:49 +0200
Subject: [RFTv2 3/5] ath10k: rework peer accounting
In-Reply-To: <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>

It was troublesome to iterate over peers and
perform sleepable calls. This will be necessary
for some upcomming changes to tx flushing.

Make peer allocation and initial setup
protected by both ar->conf_mutex and
ar->data_lock. This way it's possible to iterate
over peers with conf_mutex and call sleepable
functions.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.h |  5 +++
 drivers/net/wireless/ath/ath10k/mac.c  | 69 +++++++++++++++++++++++++++++++---
 drivers/net/wireless/ath/ath10k/txrx.c | 29 +++++++-------
 3 files changed, 81 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 8edd6da..61e325a 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -199,9 +199,14 @@ struct ath10k_dfs_stats {
 #define ATH10K_MAX_NUM_PEER_IDS (1 << 11) /* htt rx_desc limit */
 
 struct ath10k_peer {
+	/* protected by conf_mutex + data_lock */
 	struct list_head list;
+
+	/* protected by conf_mutex */
 	int vdev_id;
 	u8 addr[ETH_ALEN];
+
+	/* protected by data_lock */
 	DECLARE_BITMAP(peer_ids, ATH10K_MAX_NUM_PEER_IDS);
 	struct ieee80211_key_conf *keys[WMI_MAX_KEY_INDEX + 1];
 };
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 5cfbf88..adb5da1 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -318,28 +318,61 @@ static u8 ath10k_parse_mpdudensity(u8 mpdudensity)
 
 static int ath10k_peer_create(struct ath10k *ar, u32 vdev_id, const u8 *addr)
 {
+	struct ath10k_peer *peer;
 	int ret;
 
 	lockdep_assert_held(&ar->conf_mutex);
 
+	peer = ath10k_peer_find(ar, vdev_id, addr);
+	if (peer) {
+		ath10k_warn("peer %pM on vdev %i already exists\n",
+			    addr, vdev_id);
+		return -EINVAL;
+	}
+
+	peer = kzalloc(sizeof(*peer), GFP_KERNEL);
+	if (!peer) {
+		ath10k_warn("failed to allocate peer %pM on vdev %i: not enough memory\n",
+			    addr, vdev_id);
+		return -ENOMEM;
+	}
+
+	peer->vdev_id = vdev_id;
+	memcpy(peer->addr, addr, ETH_ALEN);
+
+	spin_lock_bh(&ar->data_lock);
+	list_add(&peer->list, &ar->peers);
+	spin_unlock_bh(&ar->data_lock);
+
 	ret = ath10k_wmi_peer_create(ar, vdev_id, addr);
 	if (ret) {
 		ath10k_warn("failed to create wmi peer %pM on vdev %i: %i\n",
 			    addr, vdev_id, ret);
-		return ret;
+		goto err_free;
 	}
 
 	ret = ath10k_wait_for_peer_created(ar, vdev_id, addr);
 	if (ret) {
 		ath10k_warn("failed to wait for created wmi peer %pM on vdev %i: %i\n",
 			    addr, vdev_id, ret);
-		return ret;
+		goto err_free;
 	}
 	spin_lock_bh(&ar->data_lock);
 	ar->num_peers++;
 	spin_unlock_bh(&ar->data_lock);
 
 	return 0;
+
+err_free:
+	spin_lock_bh(&ar->data_lock);
+	list_del(&peer->list);
+	/* very unlikely, but check anyway */
+	if (!bitmap_empty(peer->peer_ids, ATH10K_MAX_NUM_PEER_IDS))
+		ath10k_warn("removing peer %pM on vdev %i still being mapped in firmware\n",
+			    addr, vdev_id);
+	spin_unlock_bh(&ar->data_lock);
+	kfree(peer);
+	return ret;
 }
 
 static int ath10k_mac_set_kickout(struct ath10k_vif *arvif)
@@ -416,22 +449,46 @@ static int ath10k_mac_set_frag(struct ath10k_vif *arvif, u32 value)
 
 static int ath10k_peer_delete(struct ath10k *ar, u32 vdev_id, const u8 *addr)
 {
+	struct ath10k_peer *peer;
 	int ret;
 
 	lockdep_assert_held(&ar->conf_mutex);
 
+	peer = ath10k_peer_find(ar, vdev_id, addr);
+	if (!peer) {
+		ath10k_warn("failed to lookup peer %pM on vdev %i\n",
+			    addr, vdev_id);
+		return -ENOENT;
+	}
+
 	ret = ath10k_wmi_peer_delete(ar, vdev_id, addr);
-	if (ret)
-		return ret;
+	if (ret) {
+		ath10k_warn("failed to request wmi peer %pM on vdev %i removal: %d\n",
+			    addr, vdev_id, ret);
+		goto out;
+	}
 
 	ret = ath10k_wait_for_peer_deleted(ar, vdev_id, addr);
-	if (ret)
-		return ret;
+	if (ret) {
+		ath10k_warn("failed to wait for wmi peer %pM on vdev %i removal: %d\n",
+			    addr, vdev_id, ret);
+		goto out;
+	}
 
 	spin_lock_bh(&ar->data_lock);
 	ar->num_peers--;
 	spin_unlock_bh(&ar->data_lock);
 
+out:
+	spin_lock_bh(&ar->data_lock);
+	list_del(&peer->list);
+	if (!bitmap_empty(peer->peer_ids, ATH10K_MAX_NUM_PEER_IDS))
+		ath10k_warn("removing peer %pM on vdev %i still being mapped in firmware\n",
+			    addr, vdev_id);
+	spin_unlock_bh(&ar->data_lock);
+
+	kfree(peer);
+
 	return 0;
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/txrx.c b/drivers/net/wireless/ath/ath10k/txrx.c
index 82669a7..d802569 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -100,13 +100,13 @@ exit:
 		wake_up(&htt->empty_tx_wq);
 }
 
+/* hold conf_mutex for simple iteration, or conf_mutex+data_lock for
+ * modifications */
 struct ath10k_peer *ath10k_peer_find(struct ath10k *ar, int vdev_id,
 				     const u8 *addr)
 {
 	struct ath10k_peer *peer;
 
-	lockdep_assert_held(&ar->data_lock);
-
 	list_for_each_entry(peer, &ar->peers, list) {
 		if (peer->vdev_id != vdev_id)
 			continue;
@@ -139,10 +139,14 @@ static int ath10k_wait_for_peer_common(struct ath10k *ar, int vdev_id,
 	int ret;
 
 	ret = wait_event_timeout(ar->peer_mapping_wq, ({
-			bool mapped;
+			struct ath10k_peer *peer;
+			bool mapped = false;
 
 			spin_lock_bh(&ar->data_lock);
-			mapped = !!ath10k_peer_find(ar, vdev_id, addr);
+			peer = ath10k_peer_find(ar, vdev_id, addr);
+			if (peer)
+				mapped = !bitmap_empty(peer->peer_ids,
+						       ATH10K_MAX_NUM_PEER_IDS);
 			spin_unlock_bh(&ar->data_lock);
 
 			mapped == expect_mapped;
@@ -173,20 +177,16 @@ void ath10k_peer_map_event(struct ath10k_htt *htt,
 	spin_lock_bh(&ar->data_lock);
 	peer = ath10k_peer_find(ar, ev->vdev_id, ev->addr);
 	if (!peer) {
-		peer = kzalloc(sizeof(*peer), GFP_ATOMIC);
-		if (!peer)
-			goto exit;
-
-		peer->vdev_id = ev->vdev_id;
-		memcpy(peer->addr, ev->addr, ETH_ALEN);
-		list_add(&peer->list, &ar->peers);
-		wake_up(&ar->peer_mapping_wq);
+		ath10k_warn("failed to map peer %pM on vdev %i: no such entry\n",
+			    ev->addr, ev->vdev_id);
+		goto exit;
 	}
 
 	ath10k_dbg(ATH10K_DBG_HTT, "htt peer map vdev %d peer %pM id %d\n",
 		   ev->vdev_id, ev->addr, ev->peer_id);
 
 	set_bit(ev->peer_id, peer->peer_ids);
+	wake_up(&ar->peer_mapping_wq);
 exit:
 	spin_unlock_bh(&ar->data_lock);
 }
@@ -210,11 +210,8 @@ void ath10k_peer_unmap_event(struct ath10k_htt *htt,
 
 	clear_bit(ev->peer_id, peer->peer_ids);
 
-	if (bitmap_empty(peer->peer_ids, ATH10K_MAX_NUM_PEER_IDS)) {
-		list_del(&peer->list);
-		kfree(peer);
+	if (bitmap_empty(peer->peer_ids, ATH10K_MAX_NUM_PEER_IDS))
 		wake_up(&ar->peer_mapping_wq);
-	}
 
 exit:
 	spin_unlock_bh(&ar->data_lock);
-- 
1.8.5.3



From kvalo at qca.qualcomm.com  Wed Apr  9 07:11:30 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 9 Apr 2014 14:11:30 +0300
Subject: For Help: problems with tx bitrate in ath10k
In-Reply-To: <CAEFj984QK4+-P39YUEvZekNk-TViYwDTR1QweZvWUkHF2wtoCw@mail.gmail.com>
 (Yeoh Chun-Yeow's message of "Wed, 9 Apr 2014 11:11:32 +0800")
References: <5343B89E.2090407@dhc.com.cn>
 <CAEFj984QK4+-P39YUEvZekNk-TViYwDTR1QweZvWUkHF2wtoCw@mail.gmail.com>
Message-ID: <878urekba5.fsf@kamboji.qca.qualcomm.com>

Yeoh Chun-Yeow <yeohchunyeow at gmail.com> writes:

> Need firmware change to get proper Tx rate as pointed out by Kalle
> Valo. So no support for the time being.
>
> http://lists.infradead.org/pipermail/ath10k/2014-March/001587.html

That's right. I added this question also to the FAQ:

http://wireless.kernel.org/en/users/Drivers/ath10k/faq#Why_the_TX_rate_reported_to_user_space_is_wrong.3F

Is there any way to report to user space that TX rate reports are not
supported? If not, it would be great if someone would have time to add
that to cfg80211/mac80211. This issue is confusing a lot of people.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  9 07:14:08 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 9 Apr 2014 14:14:08 +0300
Subject: WDS and adhoc support with ath10k
In-Reply-To: <CAEFj984HyGGfWHNdpAkv4X0k=SBDu+ST9CyBdrfciXn8AZXgrw@mail.gmail.com>
 (Yeoh Chun-Yeow's message of "Wed, 9 Apr 2014 10:47:33 +0800")
References: <603DB158-F608-47C8-AEE8-F0FCFD563699@gmail.com>
 <CAEFj984HyGGfWHNdpAkv4X0k=SBDu+ST9CyBdrfciXn8AZXgrw@mail.gmail.com>
Message-ID: <874n22kb5r.fsf@kamboji.qca.qualcomm.com>

Yeoh Chun-Yeow <yeohchunyeow at gmail.com> writes:

>> Could someone confirm if WDS and adhoc mode currently don't have support with this driver?
>
> adhoc is working but not perfect, such as rate control not working, no
> HT/VHT rate, and etc. You need to use the firmware version
> 999.999.0.636.
>
> WDS should be working since 4 addresses has fixed by Michal:
> http://lists.infradead.org/pipermail/ath10k/2014-February/001191.html

But the version of ath10k in openwrt is starting to become old, I doubt
it has Michal's fix.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  9 07:24:02 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 9 Apr 2014 14:24:02 +0300
Subject: ath10k FAQ
In-Reply-To: <CAHqTa-1DMgZBW9aqHEXjEy=PWytk88S-kiy3kOqtiGDWLi==cA@mail.gmail.com>
 (Avery Pennarun's message of "Tue, 8 Apr 2014 19:56:36 -0400")
References: <8761mkmfny.fsf@kamboji.qca.qualcomm.com>
 <CAHqTa-1DMgZBW9aqHEXjEy=PWytk88S-kiy3kOqtiGDWLi==cA@mail.gmail.com>
Message-ID: <87zjjuiw4t.fsf@kamboji.qca.qualcomm.com>

Avery Pennarun <apenwarr at gmail.com> writes:

> On Tue, Apr 8, 2014 at 3:41 AM, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>> I created a small FAQ to the wiki and added the four questions which
>> seem to be popular:
>>
>> http://wireless.kernel.org/en/users/Drivers/ath10k/faq
>>
>> Comments welcome. And feel free to update it with new questions.
>
> This seems helpful.

Especially for me as now I can just answer with an URL ;)

> For the first question ("can't set channel") I think the provided
> answer is not the only cause of the problem, and was not the one that
> confused me at first. For me, the main confusion was that it's pretty
> non-intuitive how to set the 80 MHz center frequency in hostapd.conf
> ("the center frequency of the channel 6 higher than the lowest channel
> number in the 4-channel group"). It might help if you could include an
> example for that. I guess it varies by country so it might be a little
> tricky.

Good point. I tried to improve the answer a bit now:

----------------------------------------------------------------------
Why I cannot start an AP in an 80 MHz channel / in 11ac mode?

If you get "nl80211: Failed to set channel" error from hostapd, most
likely that means that regulatory database doesn't support 80 MHz
channels (which were introduced in 11ac). You can check that with iw:

$ iw reg get
country FI: DFS-ETSI
        (2402 - 2482 @ 40), (N/A, 20)
        (5170 - 5250 @ 80), (N/A, 20)
        (5250 - 5330 @ 80), (N/A, 20), DFS
        (5490 - 5710 @ 80), (N/A, 27), DFS
        (57240 - 65880 @ 2160), (N/A, 40), NO-OUTDOOR

If you do not see "@ 80" within the frequency range you are using, it
means that the regulatory database doesn't support 80 MHz channels.

Other problem is that configuring VHT (= 802.11ac) in hostapd is not
very intuitive, pay extra attention how you configure it. Especially
vht_oper_centr_freq_seg0_idx is challenging. See example configuration
and hostapd configuration file documentation.
----------------------------------------------------------------------

I'm trying to maintain all configuration related documentation in
respective pages and that's why I just have pointers in the FAQ.

-- 
Kalle Valo


From nbd at openwrt.org  Wed Apr  9 07:47:17 2014
From: nbd at openwrt.org (Felix Fietkau)
Date: Wed, 09 Apr 2014 13:47:17 +0200
Subject: [OpenWrt-Devel] WDS and adhoc support with ath10k
In-Reply-To: <874n22kb5r.fsf@kamboji.qca.qualcomm.com>
References: <603DB158-F608-47C8-AEE8-F0FCFD563699@gmail.com>
 <CAEFj984HyGGfWHNdpAkv4X0k=SBDu+ST9CyBdrfciXn8AZXgrw@mail.gmail.com>
 <874n22kb5r.fsf@kamboji.qca.qualcomm.com>
Message-ID: <53453345.1000407@openwrt.org>

On 2014-04-09 13:14, Kalle Valo wrote:
> Yeoh Chun-Yeow <yeohchunyeow at gmail.com> writes:
> 
>>> Could someone confirm if WDS and adhoc mode currently don't have support with this driver?
>>
>> adhoc is working but not perfect, such as rate control not working, no
>> HT/VHT rate, and etc. You need to use the firmware version
>> 999.999.0.636.
>>
>> WDS should be working since 4 addresses has fixed by Michal:
>> http://lists.infradead.org/pipermail/ath10k/2014-February/001191.html
> 
> But the version of ath10k in openwrt is starting to become old, I doubt
> it has Michal's fix.
It was updated recently, to wireless-testing 2014-03-31

- Felix


From aaronmray at ohioitguy.com  Wed Apr  9 12:07:56 2014
From: aaronmray at ohioitguy.com (Aaron Ray)
Date: Wed, 9 Apr 2014 12:07:56 -0400
Subject: WDS and adhoc support with ath10k
Message-ID: <CAGsNzDJ4hDBa82bUFTQkUqjuRuKOaOVMJDsFZUUvdPGf+iKBdQ@mail.gmail.com>

I've been exploring WDS support in OpenWRT and ath10k. I'm running the
latest openwrt trunk as of this weekend and I'm NOT able to get WDS
working on my ath10k card.

No sta adapter is created also iw doesn't list any support for WDS.
I'd like to get this working if anyone has any ideas.


From greearb at candelatech.com  Wed Apr  9 13:34:18 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 09 Apr 2014 10:34:18 -0700
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <CA+BoTQkCDiUiV7dsg-myOZXQEB=B7JHH8NWm5BHsp1xExjLkSA@mail.gmail.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <5341F1A9.2030202@candelatech.com>
 <CA+BoTQndgEB7X-RUPPkxdjnp96LJzbv6=Q9K4XTTrky-QwE4Ww@mail.gmail.com>
 <53435F89.60500@candelatech.com>
 <CA+BoTQk6G4-h8HQENbK9snrXo6j6FW4D+07XKZMEEuvWiu03ww@mail.gmail.com>
 <53441D95.9000409@candelatech.com>
 <CA+BoTQkCDiUiV7dsg-myOZXQEB=B7JHH8NWm5BHsp1xExjLkSA@mail.gmail.com>
Message-ID: <5345849A.5090603@candelatech.com>

On 04/08/2014 11:25 PM, Michal Kazior wrote:

> Additional kernel config:
> 
> CONFIG_ATH10K_DEBUG=y
> CONFIG_ATH10K_DEBUGFS=y
> CONFIG_ATH10K_TRACING=y
> CONFIG_MAC80211_MESSAGE_TRACING=y
> 
> This probably requires this to be set first:
> 
> CONFIG_TRACING=y
> CONFIG_GENERIC_TRACER=y
> CONFIG_TRACING_SUPPORT=y
> 
> (it's in Kernel Hacking)
> 
> Once you have this you can use trace-cmd command to gathers logs:
> 
>   trace-cmd record -e mac80211 -e cfg80211 -e ath10k
> 
> And then perform whatever tortures on ath10k you wish.
> 
> This creates trace.dat in your current directory. The file can get
> pretty heavy and it might not fit into an email so we might need to
> transfer it "out of band" somehow.
> 
> If you use wpa_supplicant/hostapd you can pass -T argument to those to
> get all their messages into tracing as markers. This way you're able
> to get unified logs in one file with correct chronological order.

My version of supplicant does not support -T.  I have just sync'd down the
latest upstream hostapd code and will see if that adds the support.

Here are the trace output logs and /var/log/messages.

http://www.candelatech.com/tmp/ath10k-debug.tar.bz2

Test case is to create 32 stations, bring them up and get DHCP, start
10Mbps TCP traffic on each, and re-set them.  When resetting them system generally craps
out and user-space app trying to reset the ports hangs..  Logs are full
of ath10k driver error messages.

In previous tests, I think I was running traffic while bringing up
additional interfaces, so that is probably why I could not even bring
them up properly with your patches.

This is with your RFTv2 patches on top of some of my patches and
recent wl-ath tree.  This is using my modified firmware since this
test case cannot work at all on standard firmware.

Let me know if I can offer any additional logs or info.

Thanks,
Ben



-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Wed Apr  9 15:29:36 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 09 Apr 2014 12:29:36 -0700
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <5345849A.5090603@candelatech.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <5341F1A9.2030202@candelatech.com>
 <CA+BoTQndgEB7X-RUPPkxdjnp96LJzbv6=Q9K4XTTrky-QwE4Ww@mail.gmail.com>
 <53435F89.60500@candelatech.com>
 <CA+BoTQk6G4-h8HQENbK9snrXo6j6FW4D+07XKZMEEuvWiu03ww@mail.gmail.com>
 <53441D95.9000409@candelatech.com>
 <CA+BoTQkCDiUiV7dsg-myOZXQEB=B7JHH8NWm5BHsp1xExjLkSA@mail.gmail.com>
 <5345849A.5090603@candelatech.com>
Message-ID: <53459FA0.9020700@candelatech.com>

On 04/09/2014 10:34 AM, Ben Greear wrote:

> This is with your RFTv2 patches on top of some of my patches and
> recent wl-ath tree.  This is using my modified firmware since this
> test case cannot work at all on standard firmware.
> 
> Let me know if I can offer any additional logs or info.

By the way, I reproduced the general problem with only your first two
patches (from previous RFT series) applied.  It is at least a bit
harder to reproduce, but it can happen.

Possibly the causes of the failure to flush are different in that
case, so it may not really be quite the same issue.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From Nick.Shu at spirent.com  Wed Apr  9 17:18:35 2014
From: Nick.Shu at spirent.com (Shu, Nick)
Date: Wed, 9 Apr 2014 21:18:35 +0000
Subject: ath10k driver and firmware upgrade
Message-ID: <153F35912E69C446A72CF7D6417EBADE7CF57F@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>

Hi, Kalle and all:
I have a question about upgrade the diver and firmware for my wifi ac pcie card.
I read through the docs in your /ath10k website and did the driver and firmware update.
After that, here is what I read back from system:

root at coast198:/home/spirent# ethtool -i wlan0
driver: ath10k_pci
version: 3.11.0-12-generic
firmware-version: 999.999.0.636
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

So, I can see the firmware has been updated (I used firmware-2.bin_999.999.0.636 for STA, right?).
But how can I find out have drivers been changed?

I did following to change the driver:
1. Download the tarball from "backports-3.13.2-1" to my PC.
2. FTP it to my Linux box (test server running on Ubuntu 13.10 server).
3. Unpack it to my working directory.
4. Run "make defconfig-ath10k"
        "make"
        "make install".
5. But auto install failed because of some initramfs issue (no key? from error message), so I manually "rmmod" all drivers ( ath10k_pci.ko, ath10k_core.ko, mac80211.ko, ath.ko, cfg80211.ko, compat.ko) and then "Insmod" all drivers back.
6. Run "update-initramfs -u" and reboot.

Did I do everything correct?
I used "dhcpcd wlan0" to get a valid IP address from a Netgear wifiac ac access point, but from access point manager, the MAC for my card is still "00:03:07:12:34:56".
>From your last email, you said this default MAC was caused by wrong driver and firmware, so why it's still there after I changed driver and firmware? Do I miss something?

Thank you!

Nick Shu


E-mail confidentiality.
--------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.

Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.

Or if within the US,

Spirent Communications,
26750 Agoura Road, Calabasas, CA, 91302, USA.
Tel No. 1-818-676- 2300


From greearb at candelatech.com  Wed Apr  9 17:46:16 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 09 Apr 2014 14:46:16 -0700
Subject: [RFTv2 0/5] ath10k: ath10k: fix flushing and tx stalls
In-Reply-To: <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <5345BFA8.7040500@candelatech.com>

Here's another log snippet with these 5 patches (and lots more
mostly non ath10k patches of my own) applied:

No (significant) user traffic was running.

sta215: authenticated at: 1397076587.913186
sta215: associate with 04:f0:21:03:38:99 (try 1/3), at: 1397076587.915143
ath10k: mac flushing peer 04:f0:21:03:38:99 on vdev 16 mgmt tid for unicast mgmt (204 msecs)
sta215: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=17) at: 1397076588.120218
ath10k: mac vdev 16 dtim_period 2
ath10k: mac vdev 16 slot_time 2
ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
ath10k: mac vdev 16 up (associated) bssid 04:f0:21:03:38:99 aid 17
sta215: associated at: 1397076588.122484
IPv6: ADDRCONF(NETDEV_CHANGE): sta215: link becomes ready
sta216: authenticate with 04:f0:21:03:38:99 at: 1397076588.124830
ath10k: mac vdev 17 beacon_interval 100
ath10k: mac vdev 17 create peer 04:f0:21:03:38:99
ath10k: mac vdev 17 start 04:f0:21:03:38:99
ath10k: mac vdev 17 start center_freq 5180 phymode 11ac-vht80
sta216: send auth to 04:f0:21:03:38:99 (try 1/3) at: 1397076588.125811
ath10k: mac flushing peer 04:f0:21:03:38:99 on vdev 17 mgmt tid for unicast mgmt (204 msecs)
sta216: send auth to 04:f0:21:03:38:99 (try 2/3) at: 1397076588.431144
ath10k: failed to transmit management frame via WMI: -11
sta216: send auth to 04:f0:21:03:38:99 (try 3/3) at: 1397076591.431376
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 17 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
sta216: deauthenticating from 04:f0:21:03:38:99 by local choice (reason=3)
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 17 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: mac vdev 17 peer delete 04:f0:21:03:38:99 (sta gone)
ath10k: failed to request wmi peer 04:f0:21:03:38:99 on vdev 17 removal: -11
ath10k: removing peer 04:f0:21:03:38:99 on vdev 17 still being mapped in firmware
ath10k: mac vdev 17 stop (disassociated
ath10k: failed to stop WMI vdev 17: -11
ath10k: mac vdev 17 down
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 16 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 16 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
sta218: authenticate with 04:f0:21:03:38:99 at: 1397076616.431328
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 16 to flush ffffffff: -11
ath10k: failed to flush all peer tids: -11
ath10k: mac vdev 19 beacon_interval 100
ath10k: failed to set beacon interval for vdev 19: -11
ath10k: mac vdev 19 create peer 04:f0:21:03:38:99
ath10k: failed to create wmi peer 04:f0:21:03:38:99 on vdev 19: -11
ath10k: failed to add peer 04:f0:21:03:38:99 for vdev 19 when changing bssid: -11
ath10k: mac vdev 19 start 04:f0:21:03:38:99
ath10k: mac vdev 19 start center_freq 5180 phymode 11ac-vht80


Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Wed Apr  9 19:58:07 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 09 Apr 2014 16:58:07 -0700
Subject: [RFTv2 0/5] ath10k: ath10k: fix flushing and tx stalls
In-Reply-To: <5345BFA8.7040500@candelatech.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
 <5345BFA8.7040500@candelatech.com>
Message-ID: <5345DE8F.2060808@candelatech.com>

On 04/09/2014 02:46 PM, Ben Greear wrote:
> Here's another log snippet with these 5 patches (and lots more
> mostly non ath10k patches of my own) applied:

And another one, this time with more debugging enabled.
The 0x7110XXXX numbers indicate the command-id (the XXXX part
is the cmd id).

After this below, I see a debug-log message come from
the firmware, and then nothing else.  I had added a sort
of keep-alive message in the firmware, and I do not see that
in my logs, so probably firmware is wedged in such a way that
it cannot or will not send packets to the host at this point.

I had chased this sort of problem previously, and ended up
with a hack to reset firmware when the flush failed twice.
I backed that out when applying your patches, but I guess
it is still needed.


ath10k: ep 2 got 1 credits tot 2
ath10k: mac vdev 20 start 04:f0:21:03:38:99
ath10k: mac vdev 20 start center_freq 5180 phymode 11ac-vht80
ath10k: ep 2 used 1 credits, remaining 1 dbg 1896910867 (0x71109013)
ath10k: ep 2 got 1 credits tot 2
sta219: send auth to 04:f0:21:03:38:99 (try 1/3) at: 1397086238.721985
ath10k: ep 2 used 1 credits, remaining 1 dbg 1896910888 (0x71109028)
ath10k: mac flushing peer 04:f0:21:03:38:99 on vdev 20 mgmt tid for unicast mgmt (204 msecs)
ath10k: ep 2 used 1 credits, remaining 0 dbg 1896910878 (0x7110901e)
ath10k: Creating vdev id: 22  map: 12582912
ath10k: mac vdev create 22 (add interface) type 2 subtype 0
sta219: send auth to 04:f0:21:03:38:99 (try 2/3) at: 1397086239.28088
[firmware logging msg]
ath10k: failed to create WMI vdev 22: -11
ath10k: failed to transmit management frame via WMI: -11
ath10k: Creating vdev id: 22  map: 12582912
ath10k: mac vdev create 22 (add interface) type 2 subtype 0
ath10k: failed to create WMI vdev 22: -11
sta219: deauthenticating from 04:f0:21:03:38:99 by local choice (reason=3)
ath10k: failed to wait for tx to flush: -110, forcing
ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 20 to flush ffffffff: -11
....




> 
> No (significant) user traffic was running.
> 
> sta215: authenticated at: 1397076587.913186
> sta215: associate with 04:f0:21:03:38:99 (try 1/3), at: 1397076587.915143
> ath10k: mac flushing peer 04:f0:21:03:38:99 on vdev 16 mgmt tid for unicast mgmt (204 msecs)
> sta215: RX AssocResp from 04:f0:21:03:38:99 (capab=0x1 status=0 aid=17) at: 1397076588.120218
> ath10k: mac vdev 16 dtim_period 2
> ath10k: mac vdev 16 slot_time 2
> ath10k: mac ht peer 04:f0:21:03:38:99 mcs cnt 24 nss 3
> ath10k: mac vht peer 04:f0:21:03:38:99 max_mpdu 65535 flags 0x6003001
> ath10k: mac peer 04:f0:21:03:38:99 phymode 11ac-vht80
> ath10k: mac vdev 16 up (associated) bssid 04:f0:21:03:38:99 aid 17
> sta215: associated at: 1397076588.122484
> IPv6: ADDRCONF(NETDEV_CHANGE): sta215: link becomes ready
> sta216: authenticate with 04:f0:21:03:38:99 at: 1397076588.124830
> ath10k: mac vdev 17 beacon_interval 100
> ath10k: mac vdev 17 create peer 04:f0:21:03:38:99
> ath10k: mac vdev 17 start 04:f0:21:03:38:99
> ath10k: mac vdev 17 start center_freq 5180 phymode 11ac-vht80
> sta216: send auth to 04:f0:21:03:38:99 (try 1/3) at: 1397076588.125811
> ath10k: mac flushing peer 04:f0:21:03:38:99 on vdev 17 mgmt tid for unicast mgmt (204 msecs)
> sta216: send auth to 04:f0:21:03:38:99 (try 2/3) at: 1397076588.431144
> ath10k: failed to transmit management frame via WMI: -11
> sta216: send auth to 04:f0:21:03:38:99 (try 3/3) at: 1397076591.431376
> ath10k: failed to wait for tx to flush: -110, forcing
> ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 17 to flush ffffffff: -11
> ath10k: failed to flush all peer tids: -11
> sta216: deauthenticating from 04:f0:21:03:38:99 by local choice (reason=3)
> ath10k: failed to wait for tx to flush: -110, forcing
> ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 17 to flush ffffffff: -11
> ath10k: failed to flush all peer tids: -11
> ath10k: mac vdev 17 peer delete 04:f0:21:03:38:99 (sta gone)
> ath10k: failed to request wmi peer 04:f0:21:03:38:99 on vdev 17 removal: -11
> ath10k: removing peer 04:f0:21:03:38:99 on vdev 17 still being mapped in firmware
> ath10k: mac vdev 17 stop (disassociated
> ath10k: failed to stop WMI vdev 17: -11
> ath10k: mac vdev 17 down
> ath10k: failed to wait for tx to flush: -110, forcing
> ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 16 to flush ffffffff: -11
> ath10k: failed to flush all peer tids: -11
> ath10k: failed to wait for tx to flush: -110, forcing
> ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 16 to flush ffffffff: -11
> ath10k: failed to flush all peer tids: -11
> sta218: authenticate with 04:f0:21:03:38:99 at: 1397076616.431328
> ath10k: failed to wait for tx to flush: -110, forcing
> ath10k: failed to request peer 04:f0:21:03:38:99 on vdev 16 to flush ffffffff: -11
> ath10k: failed to flush all peer tids: -11
> ath10k: mac vdev 19 beacon_interval 100
> ath10k: failed to set beacon interval for vdev 19: -11
> ath10k: mac vdev 19 create peer 04:f0:21:03:38:99
> ath10k: failed to create wmi peer 04:f0:21:03:38:99 on vdev 19: -11
> ath10k: failed to add peer 04:f0:21:03:38:99 for vdev 19 when changing bssid: -11
> ath10k: mac vdev 19 start 04:f0:21:03:38:99
> ath10k: mac vdev 19 start center_freq 5180 phymode 11ac-vht80
> 
> 
> Thanks,
> Ben
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From wangdc at dhc.com.cn  Wed Apr  9 21:10:44 2014
From: wangdc at dhc.com.cn (wangdc)
Date: Thu, 10 Apr 2014 09:10:44 +0800
Subject: ath10k driver and firmware upgrade
In-Reply-To: <mailman.297.1397087917.1064.ath10k@lists.infradead.org>
References: <mailman.297.1397087917.1064.ath10k@lists.infradead.org>
Message-ID: <5345EF94.1010104@dhc.com.cn>


On 2014?04?10? 07:58, ath10k-request at lists.infradead.org wrote:
> Message: 4
> Date: Wed, 9 Apr 2014 21:18:35 +0000
> From: "Shu, Nick"<Nick.Shu at spirent.com>
> To:"kvalo at qca.qualcomm.com"  <kvalo at qca.qualcomm.com>
> Cc:"ath10k at lists.infradead.org"  <ath10k at lists.infradead.org>
> Subject: ath10k driver and firmware upgrade
> Message-ID:
>          <153F35912E69C446A72CF7D6417EBADE7CF57F at SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
>
>
> So, I can see the firmware has been updated (I used firmware-2.bin_999.999.0.636 for STA, right?).
> But how can I find out have drivers been changed?
>
> I did following to change the driver:
> 1. Download the tarball from "backports-3.13.2-1" to my PC.
> 2. FTP it to my Linux box (test server running on Ubuntu 13.10 server).
> 3. Unpack it to my working directory.
> 4. Run "make defconfig-ath10k"
>          "make"
>          "make install".
> 5. But auto install failed because of some initramfs issue (no key? from error message), so I manually "rmmod" all drivers ( ath10k_pci.ko, ath10k_core.ko, mac80211.ko, ath.ko, cfg80211.ko, compat.ko) and then "Insmod" all drivers back.
> 6. Run "update-initramfs -u" and reboot.
>
> Did I do everything correct?
> I used "dhcpcd wlan0" to get a valid IP address from a Netgear wifiac ac access point, but from access point manager, the MAC for my card is still "00:03:07:12:34:56".
> >From your last email, you said this default MAC was caused by wrong driver and firmware, so why it's still there after I changed driver and firmware? Do I miss something?
>

May be you can get the mac address correctly using the following method.
http://lists.infradead.org/pipermail/ath10k/2014-March/001452.html

----

Rex




From greearb at candelatech.com  Wed Apr  9 21:41:02 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 09 Apr 2014 18:41:02 -0700
Subject: ath10k driver and firmware upgrade
In-Reply-To: <153F35912E69C446A72CF7D6417EBADE7CF57F@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
References: <153F35912E69C446A72CF7D6417EBADE7CF57F@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
Message-ID: <5345F6AE.4010607@candelatech.com>

On 04/09/2014 02:18 PM, Shu, Nick wrote:
> Hi, Kalle and all:
> I have a question about upgrade the diver and firmware for my wifi ac pcie card.
> I read through the docs in your /ath10k website and did the driver and firmware update.
> After that, here is what I read back from system:
> 
> root at coast198:/home/spirent# ethtool -i wlan0
> driver: ath10k_pci
> version: 3.11.0-12-generic
> firmware-version: 999.999.0.636
> bus-info: 0000:03:00.0
> supports-statistics: yes
> supports-test: no
> supports-eeprom-access: no
> supports-register-dump: no
> supports-priv-flags: no
> 
> So, I can see the firmware has been updated (I used firmware-2.bin_999.999.0.636 for STA, right?).
> But how can I find out have drivers been changed?
> 
> I did following to change the driver:
> 1. Download the tarball from "backports-3.13.2-1" to my PC.
> 2. FTP it to my Linux box (test server running on Ubuntu 13.10 server).
> 3. Unpack it to my working directory.
> 4. Run "make defconfig-ath10k"
>         "make"
>         "make install".
> 5. But auto install failed because of some initramfs issue (no key? from error message), so I manually "rmmod" all drivers ( ath10k_pci.ko, ath10k_core.ko, mac80211.ko, ath.ko, cfg80211.ko, compat.ko) and then "Insmod" all drivers back.
> 6. Run "update-initramfs -u" and reboot.
> 
> Did I do everything correct?
> I used "dhcpcd wlan0" to get a valid IP address from a Netgear wifiac ac access point, but from access point manager, the MAC for my card is still "00:03:07:12:34:56".
>>From your last email, you said this default MAC was caused by wrong driver and firmware, so why it's still there after I changed driver and firmware? Do I miss something?

You are going to have to use the 10.1.467 firmware for that NIC it seems.  That MAC means
the OTP logic in the firmware cannot understand the eeprom config on your NIC.

I haven't tried the 999.x firmware, but I did have a similar problem when using WLE900VX on
a 10.1.389 firmware (.467 had support I needed).

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From kvalo at qca.qualcomm.com  Wed Apr  9 23:45:39 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 10 Apr 2014 06:45:39 +0300
Subject: [RFT 0/4] ath10k: fix flushing and tx stalls
In-Reply-To: <5345849A.5090603@candelatech.com> (Ben Greear's message of "Wed, 
 09 Apr 2014 10:34:18 -0700")
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <5341F1A9.2030202@candelatech.com>
 <CA+BoTQndgEB7X-RUPPkxdjnp96LJzbv6=Q9K4XTTrky-QwE4Ww@mail.gmail.com>
 <53435F89.60500@candelatech.com>
 <CA+BoTQk6G4-h8HQENbK9snrXo6j6FW4D+07XKZMEEuvWiu03ww@mail.gmail.com>
 <53441D95.9000409@candelatech.com>
 <CA+BoTQkCDiUiV7dsg-myOZXQEB=B7JHH8NWm5BHsp1xExjLkSA@mail.gmail.com>
 <5345849A.5090603@candelatech.com>
Message-ID: <87eh15j198.fsf@kamboji.qca.qualcomm.com>

Ben Greear <greearb at candelatech.com> writes:

> My version of supplicant does not support -T.  I have just sync'd down the
> latest upstream hostapd code and will see if that adds the support.

You need to enable CONFIG_DEBUG_LINUX_TRACING in wpasupplicant.

http://wireless.kernel.org/en/developers/Documentation/mac80211/tracing

-- 
Kalle Valo


From greearb at candelatech.com  Thu Apr 10 00:14:02 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 09 Apr 2014 21:14:02 -0700
Subject: Crash during driver startup.
Message-ID: <53461A8A.4030209@candelatech.com>

This is in a fairly hacked code tree, so problem could be mine, but
just in case someone sees something obvious, here's the stack:

I had copied over a new firmware image and was in process of reloading
the ath10k driver and related modules when this happened.



ieee80211 phy0: Atheros AR9300 Rev:3 mem=0xffffc90016f00000, irq=18
e1000e 0000:02:00.0 eth1: registered PHC clock
e1000e 0000:02:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:90:0b:26:81:91
e1000e 0000:02:00.0 eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:02:00.0 eth1: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF
ath10k: boot warm reset complete
ath10k: boot init ce src ring id 0 entries 16 base_addr ffff8800d5418000
ath10k: boot ce dest ring id 1 entries 512 base_addr ffff880034e12000
ath10k: boot ce dest ring id 2 entries 32 base_addr ffff8800d5419000
ath10k: boot init ce src ring id 3 entries 32 base_addr ffff8800d541a000
ath10k: boot init ce src ring id 4 entries 4096 base_addr ffff880034e70000
ath10k: boot init ce src ring id 7 entries 2 base_addr ffff8800d541b000
ath10k: boot ce dest ring id 7 entries 2 base_addr ffff8800d541c000
ath10k_pci 0000:04:00.0: irq 52 for MSI/MSI-X
ath10k: boot waiting target to initialise
ath10k: boot target indicator 0
ath10k: boot target indicator 0
ath10k: boot target indicator 0
ath10k: boot target indicator 2
ath10k: boot target initialised
ath10k: pci irq MSI
ath10k: Hardware name qca988x hw2.0 version 0x4100016c
ath10k: trying fw api 2
iTCO_vendor_support: vendor-support=0
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10
iTCO_wdt: Found a Cougar Point TCO device (Version=2, TCOBASE=0x0460)
ath10k: found fw version 10.1.467-ct
ath10k: found fw timestamp 1397084546
ath10k: found firmware features ie (4 B)
ath10k: Enabling feature bit: 1
ath10k: Enabling feature bit: 2
ath10k: Enabling feature bit: 4
ath10k: features
ath10k: found FW bss info, RAM: addr 0x40d650 len 0x1db0  ROM: addr 0x400c00 len 0x5ce8
ath10k: found otp image ie (7561 B)
ath10k: found fw image ie (195877 B)
iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
ath10k: using fw api 2
ath10k: boot push board extended data addr 0x0
BUG: unable to handle kernel paging request at ffffffff815d6133
IP: [<ffffffff810fc68d>] __lock_acquire+0xf6/0xe48
cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain
cfg80211: World regulatory domain updated:
cfg80211:  DFS Master region: unset
cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm)
cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm)
cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm)
cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm)
PGD 1a10067 PUD 1a11063 PMD 14001e1
Oops: 0003 [#1] PREEMPT SMP
Modules linked in: iTCO_wdt iTCO_vendor_support joydev cdc_acm microcode snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic pcspkr ath10k_pci(+) 
snd_hda_intel ath9k snd_hda_codec ath9k_common serio_raw ath9k_hw snd_hwdep ath10k_core ath snd_seq mac80211 snd_seq_device i2c_i801 snd_pcm cfg80211 e1000e 
lpc_ich ptp pps_core snd_timer snd soundcore uinput sunrpc ipv6 i915 video i2c_algo_bit drm_kms_helper drm i2c_core
CPU: 2 PID: 529 Comm: udevd Not tainted 3.14.0+ #15
Hardware name: To be filled by O.E.M. To be filled by O.E.M./HURONRIVER, BIOS 4.6.5 05/02/2012
task: ffff88020fe342a0 ti: ffff8802102a4000 task.ti: ffff8802102a4000
RIP: 0010:[<ffffffff810fc68d>]  [<ffffffff810fc68d>] __lock_acquire+0xf6/0xe48
RSP: 0018:ffff8802102a5628  EFLAGS: 00010082
RAX: ffffffff815d5f9b RBX: ffff88020fe342a0 RCX: 0000000000000002
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8802102a5758
RBP: ffff8802102a56e8 R08: 0000000000000002 R09: 0000000000000001
R10: ffffffff810f5999 R11: ffff8802105da510 R12: 0000000000000046
R13: ffff8800d5e2aaa0 R14: ffff8802102a5758 R15: 00000000fffb9169
FS:  00007f4bfaa71840(0000) GS:ffff88021fb00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffff815d6133 CR3: 0000000214120000 CR4: 00000000000407e0
Stack:
  ffff880200000000 0000550200000000 0000000000000001 ffffffff00000002
  0000000000000000 ffff88020fe342a0 00000000815d5d7c 0000000000000002
  ffff88020fe342a0 ffff88020fe34ae0 0000000000000006 0000000000000007
Call Trace:
  [<ffffffff810fdaf4>] ? mark_held_locks+0x71/0x99
  [<ffffffff810c6b6d>] ? __local_bh_enable_ip+0xaa/0xd9
  [<ffffffff810fd7eb>] lock_acquire+0x82/0x9d
  [<ffffffff810f5999>] ? complete+0x19/0x45
  [<ffffffff810c6b72>] ? __local_bh_enable_ip+0xaf/0xd9
  [<ffffffff815d5f9b>] _raw_spin_lock_irqsave+0x47/0x5a
  [<ffffffff810f5999>] ? complete+0x19/0x45
  [<ffffffff810f5999>] complete+0x19/0x45
  [<ffffffffa056d977>] ath10k_pci_hif_exchange_bmi_msg+0x267/0x3f4 [ath10k_pci]
  [<ffffffffa0471b42>] ath10k_hif_exchange_bmi_msg+0xe/0x10 [ath10k_core]
  [<ffffffffa0471f01>] ath10k_bmi_write_memory+0xc4/0x12d [ath10k_core]
  [<ffffffffa046877f>] ath10k_core_start+0x207/0x828 [ath10k_core]
  [<ffffffffa0469723>] ath10k_core_register+0x5ca/0x77f [ath10k_core]
  [<ffffffffa056e935>] ath10k_pci_probe+0x362/0x37d [ath10k_pci]
  [<ffffffff81313783>] local_pci_probe+0x38/0x7e
  [<ffffffff813d209c>] ? driver_probe_device+0x2f9/0x2f9
  [<ffffffff813139d6>] pci_device_probe+0xc6/0xec
  [<ffffffff813d1ec8>] driver_probe_device+0x125/0x2f9
  [<ffffffff813d209c>] ? driver_probe_device+0x2f9/0x2f9
  [<ffffffff813d20ea>] __driver_attach+0x4e/0x6f
  [<ffffffff813d0330>] bus_for_each_dev+0x5a/0x8c
  [<ffffffff813d1878>] driver_attach+0x19/0x1b
  [<ffffffff813d1555>] bus_add_driver+0x110/0x1f5
  [<ffffffff813d26dd>] driver_register+0x87/0xbe
  [<ffffffff81312df6>] __pci_register_driver+0x5c/0x60
  [<ffffffffa0576000>] ? 0xffffffffa0575fff
  [<ffffffffa0576020>] ath10k_pci_init+0x20/0x3c [ath10k_pci]
  [<ffffffffa0576000>] ? 0xffffffffa0575fff
  [<ffffffff81002124>] do_one_initcall+0xae/0x156
  [<ffffffff810f9f3a>] ? up_read+0x24/0x29
  [<ffffffff81150aa1>] ? jump_label_lock+0x12/0x14
  [<ffffffff810e0965>] ? __blocking_notifier_call_chain+0x4c/0x5a
  [<ffffffff81125188>] load_module+0x1b2e/0x1e42
  [<ffffffff811224b5>] ? mod_kobject_put+0x9b/0x9b
  [<ffffffff812e9c8e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
  [<ffffffff81125568>] SyS_init_module+0xcc/0xdb
  [<ffffffff815dac7d>] system_call_fastpath+0x1a/0x1f
Code: 4c 89 f7 89 8d 58 ff ff ff 44 89 8d 50 ff ff ff e8 d9 ea ff ff 48 85 c0 8b 8d 58 ff ff ff 44 8b 8d 50 ff ff ff 0f 84 9f 04 00 00 <f0> ff 80 98 01 00 00 83 
3d 0d 82 35 01 00 44 8b ab e8 07 00 00
RIP  [<ffffffff810fc68d>] __lock_acquire+0xf6/0xe48
  RSP <ffff8802102a5628>
CR2: ffffffff815d6133
---[ end trace d566585fb1bbffa2 ]---

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From kvalo at qca.qualcomm.com  Thu Apr 10 00:34:36 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 10 Apr 2014 07:34:36 +0300
Subject: ath10k driver and firmware upgrade
In-Reply-To: <153F35912E69C446A72CF7D6417EBADE7CF57F@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
 (Nick Shu's message of "Wed, 9 Apr 2014 21:18:35 +0000")
References: <153F35912E69C446A72CF7D6417EBADE7CF57F@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
Message-ID: <87a9btiyzn.fsf@kamboji.qca.qualcomm.com>

Hi Nick,

"Shu, Nick" <Nick.Shu at spirent.com> writes:

> I have a question about upgrade the diver and firmware for my wifi ac
> pcie card. I read through the docs in your /ath10k website and did the
> driver and firmware update. After that, here is what I read back from
> system:
>
> root at coast198:/home/spirent# ethtool -i wlan0
> driver: ath10k_pci
> version: 3.11.0-12-generic
> firmware-version: 999.999.0.636
> bus-info: 0000:03:00.0
> supports-statistics: yes
> supports-test: no
> supports-eeprom-access: no
> supports-register-dump: no
> supports-priv-flags: no
>
> So, I can see the firmware has been updated (I used
> firmware-2.bin_999.999.0.636 for STA, right?).

Like Ben said, if you still see 00:03:07:12:34:56 you should use
firmware version 10.1.467.2-1.

> But how can I find out have drivers been changed?

I added some tips to the wiki:

----------------------------------------------------------------------
To check that you are really using ath10k from backports make sure that
compat module is loaded and ath10k_pci module uses it:

$ lsmod | grep compat
compat                 36104  6 iwldvm,iwlwifi,ath10k_pci,ath10k_core,mac80211,cfg80211

To check version of backports project:

$ dmesg | grep backport
[   23.210662] Loading modules backported from Linux version next-20140221-0-gfaa2e6f
[   23.210665] Backport generated by backports.git
backports-20140221-0-g8e94650
----------------------------------------------------------------------

http://wireless.kernel.org/en/users/Drivers/ath10k/backports

> I did following to change the driver:
> 1. Download the tarball from "backports-3.13.2-1" to my PC.
> 2. FTP it to my Linux box (test server running on Ubuntu 13.10 server).
> 3. Unpack it to my working directory.
> 4. Run "make defconfig-ath10k"
>         "make"
>         "make install".
> 5. But auto install failed because of some initramfs issue (no key? from error message), so I manually "rmmod" all drivers ( ath10k_pci.ko, ath10k_core.ko, mac80211.ko, ath.ko, cfg80211.ko, compat.ko) and then "Insmod" all drivers back.
> 6. Run "update-initramfs -u" and reboot.
>
> Did I do everything correct?

The initramfs issues look odd, I haven't seen those before. But
otherwise this looks good.

> I used "dhcpcd wlan0" to get a valid IP address from a Netgear wifiac
> ac access point, but from access point manager, the MAC for my card is
> still "00:03:07:12:34:56". From your last email, you said this default
> MAC was caused by wrong driver and firmware, so why it's still there
> after I changed driver and firmware? Do I miss something?

The problem is that firmware 999.999.0.636 doesn't support all hw
versions, that's why you need to use firmware from 10.1 branch.

-- 
Kalle Valo


From michal.kazior at tieto.com  Thu Apr 10 01:10:34 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 10 Apr 2014 07:10:34 +0200
Subject: [RFTv2 0/5] ath10k: ath10k: fix flushing and tx stalls
In-Reply-To: <5345DE8F.2060808@candelatech.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
 <5345BFA8.7040500@candelatech.com>
 <5345DE8F.2060808@candelatech.com>
Message-ID: <CA+BoTQnorw7Z8ve9pvGY-RgZP2N+RWNd14Xa_yxM3q1+7ryNfw@mail.gmail.com>

On 10 April 2014 01:58, Ben Greear <greearb at candelatech.com> wrote:
> On 04/09/2014 02:46 PM, Ben Greear wrote:
>> Here's another log snippet with these 5 patches (and lots more
>> mostly non ath10k patches of my own) applied:
>
> And another one, this time with more debugging enabled.
> The 0x7110XXXX numbers indicate the command-id (the XXXX part
> is the cmd id).
>
> After this below, I see a debug-log message come from
> the firmware, and then nothing else.  I had added a sort
> of keep-alive message in the firmware, and I do not see that
> in my logs, so probably firmware is wedged in such a way that
> it cannot or will not send packets to the host at this point.
>
> I had chased this sort of problem previously, and ended up
> with a hack to reset firmware when the flush failed twice.
> I backed that out when applying your patches, but I guess
> it is still needed.

Then this looks like a different issue from what I've been trying to
fix actually.

In my case when acting as AP it's possible to get WMI mgmt tx frames
stuck in FW queues when sleeping client stops responding for about 10
seconds. If you use up all tx credits (the multitude of 2 that there
are :-) beaconing stops and everything just fails.


> ath10k: ep 2 got 1 credits tot 2
> ath10k: mac vdev 20 start 04:f0:21:03:38:99
> ath10k: mac vdev 20 start center_freq 5180 phymode 11ac-vht80

> ath10k: ep 2 used 1 credits, remaining 1 dbg 1896910867 (0x71109013)

I suppose this print is located in ath10k_htc_send()?


> ath10k: ep 2 got 1 credits tot 2
> sta219: send auth to 04:f0:21:03:38:99 (try 1/3) at: 1397086238.721985
> ath10k: ep 2 used 1 credits, remaining 1 dbg 1896910888 (0x71109028)
> ath10k: mac flushing peer 04:f0:21:03:38:99 on vdev 20 mgmt tid for unicast mgmt (204 msecs)
> ath10k: ep 2 used 1 credits, remaining 0 dbg 1896910878 (0x7110901e)
> ath10k: Creating vdev id: 22  map: 12582912
> ath10k: mac vdev create 22 (add interface) type 2 subtype 0
> sta219: send auth to 04:f0:21:03:38:99 (try 2/3) at: 1397086239.28088
> [firmware logging msg]
> ath10k: failed to create WMI vdev 22: -11

Hmm.. If I read this correctly it means that MGMT_TX and
PEER_FLUSH_TIDS commands are both stuck in firmware. This most likely
means firmware stops processing everything altogether. Having HTC
debug prints from ath10k_htc_notify_tx_completion() could provide more
insight perhaps. I suspect MGMT_TX is the trigger in all cases.

I'm still suspicious of your firmware changes. You connect multiple
stations to the exact same AP. Is peer mapping working correctly? Are
tid queues mapped correctly in all cases? Perhaps there's some kind of
inconsistency that leads to this mess? I think firmware wasn't
originally designed to support your usecase. Or maybe firmware just
breaks when you try to run a hundred or so of vdevs :-D


Micha?


From greearb at candelatech.com  Thu Apr 10 01:26:42 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 09 Apr 2014 22:26:42 -0700
Subject: [RFTv2 0/5] ath10k: ath10k: fix flushing and tx stalls
In-Reply-To: <CA+BoTQnorw7Z8ve9pvGY-RgZP2N+RWNd14Xa_yxM3q1+7ryNfw@mail.gmail.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>	<1397040531-6224-1-git-send-email-michal.kazior@tieto.com>	<5345BFA8.7040500@candelatech.com>	<5345DE8F.2060808@candelatech.com>
 <CA+BoTQnorw7Z8ve9pvGY-RgZP2N+RWNd14Xa_yxM3q1+7ryNfw@mail.gmail.com>
Message-ID: <53462B92.7010408@candelatech.com>

On 04/09/2014 10:10 PM, Michal Kazior wrote:
> On 10 April 2014 01:58, Ben Greear <greearb at candelatech.com> wrote:
>> On 04/09/2014 02:46 PM, Ben Greear wrote:
>>> Here's another log snippet with these 5 patches (and lots more
>>> mostly non ath10k patches of my own) applied:
>>
>> And another one, this time with more debugging enabled.
>> The 0x7110XXXX numbers indicate the command-id (the XXXX part
>> is the cmd id).
>>
>> After this below, I see a debug-log message come from
>> the firmware, and then nothing else.  I had added a sort
>> of keep-alive message in the firmware, and I do not see that
>> in my logs, so probably firmware is wedged in such a way that
>> it cannot or will not send packets to the host at this point.
>>
>> I had chased this sort of problem previously, and ended up
>> with a hack to reset firmware when the flush failed twice.
>> I backed that out when applying your patches, but I guess
>> it is still needed.
>
> Then this looks like a different issue from what I've been trying to
> fix actually.
>
> In my case when acting as AP it's possible to get WMI mgmt tx frames
> stuck in FW queues when sleeping client stops responding for about 10
> seconds. If you use up all tx credits (the multitude of 2 that there
> are :-) beaconing stops and everything just fails.

I see them stuck for a long while in STA mode too, but usually
it recovers.  I tried finding where in firmware I could increase
the tx-credits to 4 or something, but had no luck...tis a twisty
maze.


>> ath10k: ep 2 got 1 credits tot 2
>> ath10k: mac vdev 20 start 04:f0:21:03:38:99
>> ath10k: mac vdev 20 start center_freq 5180 phymode 11ac-vht80
>
>> ath10k: ep 2 used 1 credits, remaining 1 dbg 1896910867 (0x71109013)
>
> I suppose this print is located in ath10k_htc_send()?

Yes, right after decrementing credits.

>> ath10k: ep 2 got 1 credits tot 2
>> sta219: send auth to 04:f0:21:03:38:99 (try 1/3) at: 1397086238.721985
>> ath10k: ep 2 used 1 credits, remaining 1 dbg 1896910888 (0x71109028)
>> ath10k: mac flushing peer 04:f0:21:03:38:99 on vdev 20 mgmt tid for unicast mgmt (204 msecs)
>> ath10k: ep 2 used 1 credits, remaining 0 dbg 1896910878 (0x7110901e)
>> ath10k: Creating vdev id: 22  map: 12582912
>> ath10k: mac vdev create 22 (add interface) type 2 subtype 0
>> sta219: send auth to 04:f0:21:03:38:99 (try 2/3) at: 1397086239.28088
>> [firmware logging msg]
>> ath10k: failed to create WMI vdev 22: -11
>
> Hmm.. If I read this correctly it means that MGMT_TX and
> PEER_FLUSH_TIDS commands are both stuck in firmware. This most likely
> means firmware stops processing everything altogether. Having HTC
> debug prints from ath10k_htc_notify_tx_completion() could provide more
> insight perhaps. I suspect MGMT_TX is the trigger in all cases.
>
> I'm still suspicious of your firmware changes. You connect multiple
> stations to the exact same AP. Is peer mapping working correctly? Are
> tid queues mapped correctly in all cases? Perhaps there's some kind of
> inconsistency that leads to this mess? I think firmware wasn't
> originally designed to support your usecase. Or maybe firmware just
> breaks when you try to run a hundred or so of vdevs :-D

I have at least attempted to rectify all of that, but indeed this
particular lockup seems like a firmware issue.  I personally suspect
that I just find many bugs 32 times faster than simpler systems will :P

The firmware has it's own sort of tx-to-host-credits logic, so if it runs
out of space it might not be able to send any messages back to
the host.  I've crawled through a lot of that code and didn't
see any obvious ways to leak buffers, but it's far from simple
code, so I could still be wrong.

Maybe I could add a small scratch area in firmware memory and place debug
info there and read it from host over the PCI bus like when we
dump the crash info...  This time of night I really hate firmware :P

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From kvalo at qca.qualcomm.com  Thu Apr 10 01:57:13 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 10 Apr 2014 08:57:13 +0300
Subject: [PATCH 2/4] ath10k: make sure to not use invalid beacon pointer
In-Reply-To: <1397037685-7485-3-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Wed, 9 Apr 2014 12:01:23 +0200")
References: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
 <1397037685-7485-3-git-send-email-michal.kazior@tieto.com>
Message-ID: <87wqexhgli.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> If DMA mapping of next beacon failed it was
> possible for next SWBA to access a pointer that
> was already unmapped and freed. This could cause
> memory corruption.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
> ---
>  drivers/net/wireless/ath/ath10k/wmi.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index d4b48ef..35c7d52 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -1441,6 +1441,8 @@ static void ath10k_wmi_event_host_swba(struct ath10k *ar, struct sk_buff *skb)
>  			dev_kfree_skb_any(arvif->beacon);
>  		}
>  
> +		arvif->beacon = NULL;

Why have this outside the "if (arvif->beacon)" check? If it's already
NULL, there's no need to set it to NULL again. And besides, at least for
me, it's more intuitive to reset the variable immeadiately after
dev_kfree_skb_any().

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Thu Apr 10 02:11:04 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 10 Apr 2014 09:11:04 +0300
Subject: [PATCH 2/3] ath10k: don't wait for device init if it crashed
In-Reply-To: <1397038028-7665-3-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Wed, 9 Apr 2014 12:07:07 +0200")
References: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
 <1397038028-7665-3-git-send-email-michal.kazior@tieto.com>
Message-ID: <87siplhfyf.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> When warm resetting it's possible for device to
> crash during initialization. Instead of waiting 3
> seconds just return failure as soon as
> FW_IND_EVENT_PENDING is set.
>
> This speeds up device bootup and recovery in some
> cases.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

[...]

> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -2452,6 +2452,9 @@ static int ath10k_pci_wait_for_target_init(struct ath10k *ar)
>  		if (val == 0xffffffff)
>  			continue;
>  
> +		if (val & FW_IND_EVENT_PENDING)
> +			break;

Can you add a small comment here explaining why we do this? "device has
most probably crashed" or something like that.

-- 
Kalle Valo


From yeohchunyeow at gmail.com  Thu Apr 10 02:17:38 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 10 Apr 2014 14:17:38 +0800
Subject: WDS and adhoc support with ath10k
In-Reply-To: <CAGsNzDJ4hDBa82bUFTQkUqjuRuKOaOVMJDsFZUUvdPGf+iKBdQ@mail.gmail.com>
References: <CAGsNzDJ4hDBa82bUFTQkUqjuRuKOaOVMJDsFZUUvdPGf+iKBdQ@mail.gmail.com>
Message-ID: <CAEFj985jaYoB0fgoY7G0vstcPJTTtGGLy_unAaTWUKvKGDwChw@mail.gmail.com>

Just make sure that the adhoc mode is working first before proceed to WDS.

Be sure the firmware version is as follow:
[   13.810000] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw
999.999.0.636 api 2 htt 2.1

I haven't tried the adhoc mode with WDS, but did try for managed and
AP interface.

I think that you need to turn on the 4addr flag in iw:
iw dev wlan0 set 4addr on

----
Chun-Yeow

On Thu, Apr 10, 2014 at 12:07 AM, Aaron Ray <aaronmray at ohioitguy.com> wrote:
> I've been exploring WDS support in OpenWRT and ath10k. I'm running the
> latest openwrt trunk as of this weekend and I'm NOT able to get WDS
> working on my ath10k card.
>
> No sta adapter is created also iw doesn't list any support for WDS.
> I'd like to get this working if anyone has any ideas.
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From kvalo at qca.qualcomm.com  Thu Apr 10 02:50:02 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 10 Apr 2014 09:50:02 +0300
Subject: [RFTv2 3/5] ath10k: rework peer accounting
In-Reply-To: <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Wed, 9 Apr 2014 12:48:49 +0200")
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>
Message-ID: <87ob09he5h.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> It was troublesome to iterate over peers and
> perform sleepable calls. This will be necessary
> for some upcomming changes to tx flushing.
>
> Make peer allocation and initial setup
> protected by both ar->conf_mutex and
> ar->data_lock. This way it's possible to iterate
> over peers with conf_mutex and call sleepable
> functions.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Sorry, but I'm not really getting your idea here of using both
conf_mutex and data_lock to protect ar->peers. Can you elaborate more,
please? Why can't we just use conf_mutex then? What am I missing?

-- 
Kalle Valo


From michal.kazior at tieto.com  Thu Apr 10 02:56:38 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 10 Apr 2014 08:56:38 +0200
Subject: [RFTv2 3/5] ath10k: rework peer accounting
In-Reply-To: <87ob09he5h.fsf@kamboji.qca.qualcomm.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>
 <87ob09he5h.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CA+BoTQkTvOvjW51R2YmtW_5_5jtKan1u6jRY3_82FRZnZG2jEw@mail.gmail.com>

On 10 April 2014 08:50, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> It was troublesome to iterate over peers and
>> perform sleepable calls. This will be necessary
>> for some upcomming changes to tx flushing.
>>
>> Make peer allocation and initial setup
>> protected by both ar->conf_mutex and
>> ar->data_lock. This way it's possible to iterate
>> over peers with conf_mutex and call sleepable
>> functions.
>>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>
> Sorry, but I'm not really getting your idea here of using both
> conf_mutex and data_lock to protect ar->peers. Can you elaborate more,
> please? Why can't we just use conf_mutex then? What am I missing?

Originally ar->peers was protected by data_lock. The reason for that
the list is accessed from a tasklet context for htt peer map/unmap
events. Originally those events allocated/freed peers. This however is
cumbersome to work with when you want to iterate over peers and issue
blocking/sleepable calls (e.g. flush tx via wmi).

Having conf_mutex-only protected conf_mutex would require htt peer
map/unmap event processing to be moved into sleepable context (e.g.
into a worker).

That's why I've made ar->peers being write-protected by both so that
it can be read while holding any of these locks.

I'll try to make the commit message clearer.


Micha?


From kvalo at qca.qualcomm.com  Thu Apr 10 02:59:07 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 10 Apr 2014 09:59:07 +0300
Subject: [RFTv2 3/5] ath10k: rework peer accounting
In-Reply-To: <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Wed, 9 Apr 2014 12:48:49 +0200")
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>
Message-ID: <87k3axhdqc.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> It was troublesome to iterate over peers and
> perform sleepable calls. This will be necessary
> for some upcomming changes to tx flushing.
>
> Make peer allocation and initial setup
> protected by both ar->conf_mutex and
> ar->data_lock. This way it's possible to iterate
> over peers with conf_mutex and call sleepable
> functions.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

First comments, but I need to read this much more carefully still:

> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -199,9 +199,14 @@ struct ath10k_dfs_stats {
>  #define ATH10K_MAX_NUM_PEER_IDS (1 << 11) /* htt rx_desc limit */
>  
>  struct ath10k_peer {
> +	/* protected by conf_mutex + data_lock */
>  	struct list_head list;

This really needs a lot more documentation. And besides, don't we
actually want to protect struct ath10k::peers, not this?

> +/* hold conf_mutex for simple iteration, or conf_mutex+data_lock for
> + * modifications */
>  struct ath10k_peer *ath10k_peer_find(struct ath10k *ar, int vdev_id,
>  				     const u8 *addr)
>  {
>  	struct ath10k_peer *peer;
>  
> -	lockdep_assert_held(&ar->data_lock);
> -
>  	list_for_each_entry(peer, &ar->peers, list) {
>  		if (peer->vdev_id != vdev_id)
>  			continue;

The comment here makes me suspicious. How can we safely iterate the list
if we don't take data_lock? Doesn't it mean that the list can change
while we have conf_mutex?

-- 
Kalle Valo


From michal.kazior at tieto.com  Thu Apr 10 03:11:13 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 10 Apr 2014 09:11:13 +0200
Subject: [RFTv2 3/5] ath10k: rework peer accounting
In-Reply-To: <87k3axhdqc.fsf@kamboji.qca.qualcomm.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>
 <87k3axhdqc.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CA+BoTQ=c+dTcK_diBKi6VJVgUkyBv21bDkRf+9GvGyhhqqMuNQ@mail.gmail.com>

On 10 April 2014 08:59, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> It was troublesome to iterate over peers and
>> perform sleepable calls. This will be necessary
>> for some upcomming changes to tx flushing.
>>
>> Make peer allocation and initial setup
>> protected by both ar->conf_mutex and
>> ar->data_lock. This way it's possible to iterate
>> over peers with conf_mutex and call sleepable
>> functions.
>>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>
> First comments, but I need to read this much more carefully still:
>
>> --- a/drivers/net/wireless/ath/ath10k/core.h
>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>> @@ -199,9 +199,14 @@ struct ath10k_dfs_stats {
>>  #define ATH10K_MAX_NUM_PEER_IDS (1 << 11) /* htt rx_desc limit */
>>
>>  struct ath10k_peer {
>> +     /* protected by conf_mutex + data_lock */
>>       struct list_head list;
>
> This really needs a lot more documentation. And besides, don't we
> actually want to protect struct ath10k::peers, not this?

Parts of the structure needs to be locked differently.

I suppose we can say we just protect everything with data_lock except
`struct list_head list` which needs to be write-protected by both
conf_mutex and data_lock. But then again, addr and vdev_id don't need
any locking as they are immutable (and set before adding to the list).


>
>> +/* hold conf_mutex for simple iteration, or conf_mutex+data_lock for
>> + * modifications */
>>  struct ath10k_peer *ath10k_peer_find(struct ath10k *ar, int vdev_id,
>>                                    const u8 *addr)
>>  {
>>       struct ath10k_peer *peer;
>>
>> -     lockdep_assert_held(&ar->data_lock);
>> -
>>       list_for_each_entry(peer, &ar->peers, list) {
>>               if (peer->vdev_id != vdev_id)
>>                       continue;
>
> The comment here makes me suspicious. How can we safely iterate the list
> if we don't take data_lock? Doesn't it mean that the list can change
> while we have conf_mutex?

The idea is you need BOTH locks to modify the list structure, but you
need only one of them to iterate over the list safely and
consistently. This means writer will not alter the list structure
until there are no readers.


Micha?


From kvalo at qca.qualcomm.com  Thu Apr 10 03:18:40 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 10 Apr 2014 10:18:40 +0300
Subject: [RFTv2 3/5] ath10k: rework peer accounting
In-Reply-To: <CA+BoTQ=c+dTcK_diBKi6VJVgUkyBv21bDkRf+9GvGyhhqqMuNQ@mail.gmail.com>
 (Michal Kazior's message of "Thu, 10 Apr 2014 09:11:13 +0200")
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>
 <87k3axhdqc.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=c+dTcK_diBKi6VJVgUkyBv21bDkRf+9GvGyhhqqMuNQ@mail.gmail.com>
Message-ID: <87fvllhctr.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

>>> +/* hold conf_mutex for simple iteration, or conf_mutex+data_lock for
>>> + * modifications */
>>>  struct ath10k_peer *ath10k_peer_find(struct ath10k *ar, int vdev_id,
>>>                                    const u8 *addr)
>>>  {
>>>       struct ath10k_peer *peer;
>>>
>>> -     lockdep_assert_held(&ar->data_lock);
>>> -
>>>       list_for_each_entry(peer, &ar->peers, list) {
>>>               if (peer->vdev_id != vdev_id)
>>>                       continue;
>>
>> The comment here makes me suspicious. How can we safely iterate the list
>> if we don't take data_lock? Doesn't it mean that the list can change
>> while we have conf_mutex?
>
> The idea is you need BOTH locks to modify the list structure, but you
> need only one of them to iterate over the list safely and
> consistently. This means writer will not alter the list structure
> until there are no readers.

Still not understanding this. Why not then use conf_mutex always, why do
we need data_lock at all?

Or are you saying that one can iterate the list by either taking
conf_mutex or by taking data_lock, depending on context?

-- 
Kalle Valo


From michal.kazior at tieto.com  Thu Apr 10 03:43:13 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 10 Apr 2014 09:43:13 +0200
Subject: [RFTv2 3/5] ath10k: rework peer accounting
In-Reply-To: <87fvllhctr.fsf@kamboji.qca.qualcomm.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>
 <87k3axhdqc.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=c+dTcK_diBKi6VJVgUkyBv21bDkRf+9GvGyhhqqMuNQ@mail.gmail.com>
 <87fvllhctr.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CA+BoTQkL8Vp_hjOP-=RZL97QXScF+WVX=BGf6d-HY8cQmu=WCQ@mail.gmail.com>

On 10 April 2014 09:18, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>>>> +/* hold conf_mutex for simple iteration, or conf_mutex+data_lock for
>>>> + * modifications */
>>>>  struct ath10k_peer *ath10k_peer_find(struct ath10k *ar, int vdev_id,
>>>>                                    const u8 *addr)
>>>>  {
>>>>       struct ath10k_peer *peer;
>>>>
>>>> -     lockdep_assert_held(&ar->data_lock);
>>>> -
>>>>       list_for_each_entry(peer, &ar->peers, list) {
>>>>               if (peer->vdev_id != vdev_id)
>>>>                       continue;
>>>
>>> The comment here makes me suspicious. How can we safely iterate the list
>>> if we don't take data_lock? Doesn't it mean that the list can change
>>> while we have conf_mutex?
>>
>> The idea is you need BOTH locks to modify the list structure, but you
>> need only one of them to iterate over the list safely and
>> consistently. This means writer will not alter the list structure
>> until there are no readers.
>
> Still not understanding this. Why not then use conf_mutex always, why do
> we need data_lock at all?

htt peer map/unmap which is in tasklet context needs to iterate over
the list. It can't take conf_mutex.


> Or are you saying that one can iterate the list by either taking
> conf_mutex or by taking data_lock, depending on context?

Yes.


Micha?


From michal.kazior at tieto.com  Thu Apr 10 04:50:46 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 10 Apr 2014 10:50:46 +0200
Subject: [RFTv2 0/5] ath10k: ath10k: fix flushing and tx stalls
In-Reply-To: <53462B92.7010408@candelatech.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
 <5345BFA8.7040500@candelatech.com>
 <5345DE8F.2060808@candelatech.com>
 <CA+BoTQnorw7Z8ve9pvGY-RgZP2N+RWNd14Xa_yxM3q1+7ryNfw@mail.gmail.com>
 <53462B92.7010408@candelatech.com>
Message-ID: <CA+BoTQ=kNdXRfnq+7ju2Bf7S_TfWPfchvRZ=PePdR4Y4_5mwuQ@mail.gmail.com>

On 10 April 2014 07:26, Ben Greear <greearb at candelatech.com> wrote:
> On 04/09/2014 10:10 PM, Michal Kazior wrote:
>> On 10 April 2014 01:58, Ben Greear <greearb at candelatech.com> wrote:
>>> ath10k: ep 2 got 1 credits tot 2
>>> sta219: send auth to 04:f0:21:03:38:99 (try 1/3) at: 1397086238.721985
>>> ath10k: ep 2 used 1 credits, remaining 1 dbg 1896910888 (0x71109028)
>>> ath10k: mac flushing peer 04:f0:21:03:38:99 on vdev 20 mgmt tid for
>>> unicast mgmt (204 msecs)
>>> ath10k: ep 2 used 1 credits, remaining 0 dbg 1896910878 (0x7110901e)
>>> ath10k: Creating vdev id: 22  map: 12582912
>>> ath10k: mac vdev create 22 (add interface) type 2 subtype 0
>>> sta219: send auth to 04:f0:21:03:38:99 (try 2/3) at: 1397086239.28088
>>> [firmware logging msg]
>>> ath10k: failed to create WMI vdev 22: -11
>>
>>
>> Hmm.. If I read this correctly it means that MGMT_TX and
>> PEER_FLUSH_TIDS commands are both stuck in firmware. This most likely
>> means firmware stops processing everything altogether. Having HTC
>> debug prints from ath10k_htc_notify_tx_completion() could provide more
>> insight perhaps. I suspect MGMT_TX is the trigger in all cases.
>>
>> I'm still suspicious of your firmware changes. You connect multiple
>> stations to the exact same AP. Is peer mapping working correctly? Are
>> tid queues mapped correctly in all cases? Perhaps there's some kind of
>> inconsistency that leads to this mess? I think firmware wasn't
>> originally designed to support your usecase. Or maybe firmware just
>> breaks when you try to run a hundred or so of vdevs :-D
>
>
> I have at least attempted to rectify all of that, but indeed this
> particular lockup seems like a firmware issue.  I personally suspect
> that I just find many bugs 32 times faster than simpler systems will :P
>
> The firmware has it's own sort of tx-to-host-credits logic, so if it runs
> out of space it might not be able to send any messages back to
> the host.  I've crawled through a lot of that code and didn't
> see any obvious ways to leak buffers, but it's far from simple
> code, so I could still be wrong.

I don't think that's the problem here.

Firmware seems to generate traffic to host while tx credits aren't
replenished (I've looked in traces you've send in the other email)
including wmi mgmt rx. From the traces it also looks like htc tx
completion is done for flush command suggesting it has been probably
processed by hif layer and maybe htc layer but there are no tx credits
replenished. There's even a ton of htt tx completion indications
although it seems new htt tx commands are never completed (in the
traces). This could suggest htt service is dead as well as wmi or it
just queues frames on a paused queue.

Tx credits for wmi should be replenished right away for all wmi
commands except mgmt tx and bcn tx (as they cannot be immediately
done). If tx credits are not replenished for flush command (which is
the case) it might not have reached the target wmi service at all.
>From what I understand this could happen if endpoint is paused but
this probably shouldn't happen as this is for wmi data path
synchronization apparently which is a legacy thing and should be hit.
Maybe there's a different way for wmi service to stop responding or to
prevent it from receiving and processing commands?


> Maybe I could add a small scratch area in firmware memory and place debug
> info there and read it from host over the PCI bus like when we
> dump the crash info...  This time of night I really hate firmware :P

Sounds reasonable to debug and pinpoint the cause of this problem.
Perhaps some counters to check if certain code paths are hit when you
expect them to be?


Micha?


From Nick.Shu at spirent.com  Thu Apr 10 10:09:33 2014
From: Nick.Shu at spirent.com (Shu, Nick)
Date: Thu, 10 Apr 2014 14:09:33 +0000
Subject: ath10k driver and firmware upgrade
In-Reply-To: <87a9btiyzn.fsf@kamboji.qca.qualcomm.com>
References: <153F35912E69C446A72CF7D6417EBADE7CF57F@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
 <87a9btiyzn.fsf@kamboji.qca.qualcomm.com>
Message-ID: <153F35912E69C446A72CF7D6417EBADE7CFA0A@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>

Thanks, All:
I did get the valid MAC after using firmware 10.1.467.2-1.
But if you look at the firmware site instruction, it says that this one is for AP, not for STA, that's why I picked it.
Anyway, glad to solve the problem with help from you all.

Nick

-----Original Message-----
From: Kalle Valo [mailto:kvalo at qca.qualcomm.com]
Sent: Wednesday, April 09, 2014 11:35 PM
To: Shu, Nick
Cc: ath10k at lists.infradead.org
Subject: Re: ath10k driver and firmware upgrade

Hi Nick,

"Shu, Nick" <Nick.Shu at spirent.com> writes:

> I have a question about upgrade the diver and firmware for my wifi ac
> pcie card. I read through the docs in your /ath10k website and did the
> driver and firmware update. After that, here is what I read back from
> system:
>
> root at coast198:/home/spirent# ethtool -i wlan0
> driver: ath10k_pci
> version: 3.11.0-12-generic
> firmware-version: 999.999.0.636
> bus-info: 0000:03:00.0
> supports-statistics: yes
> supports-test: no
> supports-eeprom-access: no
> supports-register-dump: no
> supports-priv-flags: no
>
> So, I can see the firmware has been updated (I used
> firmware-2.bin_999.999.0.636 for STA, right?).

Like Ben said, if you still see 00:03:07:12:34:56 you should use firmware version 10.1.467.2-1.

> But how can I find out have drivers been changed?

I added some tips to the wiki:

----------------------------------------------------------------------
To check that you are really using ath10k from backports make sure that compat module is loaded and ath10k_pci module uses it:

$ lsmod | grep compat
compat                 36104  6 iwldvm,iwlwifi,ath10k_pci,ath10k_core,mac80211,cfg80211

To check version of backports project:

$ dmesg | grep backport
[   23.210662] Loading modules backported from Linux version next-20140221-0-gfaa2e6f
[   23.210665] Backport generated by backports.git
backports-20140221-0-g8e94650
----------------------------------------------------------------------

http://wireless.kernel.org/en/users/Drivers/ath10k/backports

> I did following to change the driver:
> 1. Download the tarball from "backports-3.13.2-1" to my PC.
> 2. FTP it to my Linux box (test server running on Ubuntu 13.10 server).
> 3. Unpack it to my working directory.
> 4. Run "make defconfig-ath10k"
>         "make"
>         "make install".
> 5. But auto install failed because of some initramfs issue (no key? from error message), so I manually "rmmod" all drivers ( ath10k_pci.ko, ath10k_core.ko, mac80211.ko, ath.ko, cfg80211.ko, compat.ko) and then "Insmod" all drivers back.
> 6. Run "update-initramfs -u" and reboot.
>
> Did I do everything correct?

The initramfs issues look odd, I haven't seen those before. But otherwise this looks good.

> I used "dhcpcd wlan0" to get a valid IP address from a Netgear wifiac
> ac access point, but from access point manager, the MAC for my card is
> still "00:03:07:12:34:56". From your last email, you said this default
> MAC was caused by wrong driver and firmware, so why it's still there
> after I changed driver and firmware? Do I miss something?

The problem is that firmware 999.999.0.636 doesn't support all hw versions, that's why you need to use firmware from 10.1 branch.

--
Kalle Valo
E-mail confidentiality.
--------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.

Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.

Or if within the US,

Spirent Communications,
26750 Agoura Road, Calabasas, CA, 91302, USA.
Tel No. 1-818-676- 2300


From michal.kazior at tieto.com  Thu Apr 10 06:05:55 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 10 Apr 2014 12:05:55 +0200
Subject: [PATCH] ath10k: double check bmi xfer pointers
In-Reply-To: <53461A8A.4030209@candelatech.com>
References: <53461A8A.4030209@candelatech.com>
Message-ID: <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>

If for some reason copy engine ring buffer became
corrupt ath10k could crash the machine due to
invalid pointer dereference. It's very unlikely
but devices can never be fully trusted so verify
if the bmi xfer pointer read back from copy engine
matches the original pointer. The bug looked as
follows:

 BUG: unable to handle kernel paging request at ffffffff815d6133
...
 Call Trace:
 [<ffffffff810fdaf4>] ? mark_held_locks+0x71/0x99
 [<ffffffff810c6b6d>] ? __local_bh_enable_ip+0xaa/0xd9
 [<ffffffff810fd7eb>] lock_acquire+0x82/0x9d
 [<ffffffff810f5999>] ? complete+0x19/0x45
 [<ffffffff810c6b72>] ? __local_bh_enable_ip+0xaf/0xd9
 [<ffffffff815d5f9b>] _raw_spin_lock_irqsave+0x47/0x5a
 [<ffffffff810f5999>] ? complete+0x19/0x45
 [<ffffffff810f5999>] complete+0x19/0x45
 [<ffffffffa056d977>] ath10k_pci_hif_exchange_bmi_msg+0x267/0x3f4 [ath10k_pci]
 [<ffffffffa0471b42>] ath10k_hif_exchange_bmi_msg+0xe/0x10 [ath10k_core]
 [<ffffffffa0471f01>] ath10k_bmi_write_memory+0xc4/0x12d [ath10k_core]
 [<ffffffffa046877f>] ath10k_core_start+0x207/0x828 [ath10k_core]
 [<ffffffffa0469723>] ath10k_core_register+0x5ca/0x77f [ath10k_core]
...

Reported-By: Ben Greear <greearb at candelatech.com>
Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/pci.c | 30 ++++++++++++++++++++++--------
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index bf1083d..85e84c9 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1390,35 +1390,49 @@ err_dma:
 	return ret;
 }
 
-static void ath10k_pci_bmi_send_done(struct ath10k_ce_pipe *ce_state)
+static void ath10k_pci_bmi_send_done(struct ath10k_ce_pipe *ce_state,
+				     struct bmi_xfer *xfer)
 {
-	struct bmi_xfer *xfer;
+	void *ptr;
 	u32 ce_data;
 	unsigned int nbytes;
 	unsigned int transfer_id;
 
-	if (ath10k_ce_completed_send_next(ce_state, (void **)&xfer, &ce_data,
+	if (ath10k_ce_completed_send_next(ce_state, (void **)&ptr, &ce_data,
 					  &nbytes, &transfer_id))
 		return;
 
+	if (xfer != ptr) {
+		ath10k_warn("failed to verify bmi xfer tx pointer (got %p expected %p)\n",
+			    ptr, xfer);
+		return;
+	}
+
 	if (xfer->wait_for_resp)
 		return;
 
 	complete(&xfer->done);
 }
 
-static void ath10k_pci_bmi_recv_data(struct ath10k_ce_pipe *ce_state)
+static void ath10k_pci_bmi_recv_data(struct ath10k_ce_pipe *ce_state,
+				     struct bmi_xfer *xfer)
 {
-	struct bmi_xfer *xfer;
+	void *ptr;
 	u32 ce_data;
 	unsigned int nbytes;
 	unsigned int transfer_id;
 	unsigned int flags;
 
-	if (ath10k_ce_completed_recv_next(ce_state, (void **)&xfer, &ce_data,
+	if (ath10k_ce_completed_recv_next(ce_state, (void **)&ptr, &ce_data,
 					  &nbytes, &transfer_id, &flags))
 		return;
 
+	if (xfer != ptr) {
+		ath10k_warn("failed to verify bmi xfer rx pointer (got %p expected %p)\n",
+			    ptr, xfer);
+		return;
+	}
+
 	if (!xfer->wait_for_resp) {
 		ath10k_warn("unexpected: BMI data received; ignoring\n");
 		return;
@@ -1435,8 +1449,8 @@ static int ath10k_pci_bmi_wait(struct ath10k_ce_pipe *tx_pipe,
 	unsigned long timeout = jiffies + BMI_COMMUNICATION_TIMEOUT_HZ;
 
 	while (time_before_eq(jiffies, timeout)) {
-		ath10k_pci_bmi_send_done(tx_pipe);
-		ath10k_pci_bmi_recv_data(rx_pipe);
+		ath10k_pci_bmi_send_done(tx_pipe, xfer);
+		ath10k_pci_bmi_recv_data(rx_pipe, xfer);
 
 		if (completion_done(&xfer->done))
 			return 0;
-- 
1.8.5.3



From greearb at candelatech.com  Thu Apr 10 09:41:15 2014
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 10 Apr 2014 06:41:15 -0700
Subject: Question on ath10k_mgmt_tx_flush
Message-ID: <53469F7B.2080202@candelatech.com>

Can we optimize this method to return early if the tx-credits
are fully replenished (ie, == 2) instead of just sleeping the
2 x beacon-interval?  That would indicate all messages
have been flushed, right?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Thu Apr 10 09:42:43 2014
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 10 Apr 2014 06:42:43 -0700
Subject: [PATCH] ath10k: double check bmi xfer pointers
In-Reply-To: <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <53469FD3.8040001@candelatech.com>

On 04/10/2014 03:05 AM, Michal Kazior wrote:
> If for some reason copy engine ring buffer became
> corrupt ath10k could crash the machine due to
> invalid pointer dereference. It's very unlikely
> but devices can never be fully trusted so verify
> if the bmi xfer pointer read back from copy engine
> matches the original pointer. The bug looked as
> follows:

Thanks for fixing this.  I'll add this patch to my
tree and run more tests today.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Thu Apr 10 14:59:46 2014
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 10 Apr 2014 11:59:46 -0700
Subject: Another crash in ath10k.
Message-ID: <5346EA22.2070100@candelatech.com>

This is also from a hacked-upon kernel, so problem could be my fault.

Thanks,
Ben


kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
BUG: unable to handle kernel paging request at ffff880216300600
IP: [<ffff880216300600>] 0xffff880216300600
PGD 2504067 PUD 2507067 PMD 80000002162001e3
Oops: 0011 [#1] PREEMPT SMP
Modules linked in: nf_nat_ipv4 nf_nat 8021q garp stp mrp llc macvlan wanlink(O) pktgen lockd f71882fg coretemp hwmon iTCO_wdt iTCO_vendor_support joydev cdc_acm 
microcode pcspkr ath9k ath9k_common ath9k_hw ath10k_pci ath10k_core ath serio_raw snd_hda_codec_hdmi i2c_i801 snd_hda_codec_realtek snd_hda_codec_generic 
mac80211 cfg80211 snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device lpc_ich e1000e ptp pps_core snd_pcm snd_timer snd soundcore uinput sunrpc ipv6 
i915 video i2c_algo_bit drm_kms_helper drm i2c_core [last unloaded: iptable_nat]
CPU: 2 PID: 8752 Comm: ip Tainted: G        WC O 3.14.0+ #17
Hardware name: To be filled by O.E.M. To be filled by O.E.M./HURONRIVER, BIOS 4.6.5 05/02/2012
task: ffff8800c3fca150 ti: ffff8800d295e000 task.ti: ffff8800d295e000
RIP: 0010:[<ffff880216300600>]  [<ffff880216300600>] 0xffff880216300600
RSP: 0018:ffff8800d295f460  EFLAGS: 00010246
RAX: 0000000080000000 RBX: ffff88020f907700 RCX: 0000000000000002
RDX: 0000000000000016 RSI: 0000000000000001 RDI: ffff88020f907700
RBP: ffff8800d295f478 R08: 0000000000000000 R09: ffffffff81511c6c
R10: ffffffff81511c6c R11: 0000000000000296 R12: 00000000000001a5
R13: ffff88020f907700 R14: 00000000000001a4 R15: ffff8800d20f3c20
FS:  00007f957df66740(0000) GS:ffff88021fb00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff880216300600 CR3: 00000000d5706000 CR4: 00000000000407e0
Stack:
  ffffffff81512789 0000000000000000 ffff88020f907700 ffff8800d295f498
  ffffffff815127c5 0000000000000000 ffff88020f907700 ffff8800d295f4b8
  ffffffff81512811 0000000000000000 ffff88020f907700 ffff8800d295f4d8
Call Trace:
  [<ffffffff81512789>] ? skb_release_head_state+0x65/0x93
  [<ffffffff815127c5>] skb_release_all+0xe/0x24
  [<ffffffff81512811>] __kfree_skb+0xe/0x75
  [<ffffffff81512c94>] consume_skb+0x32/0x36
  [<ffffffff81519fdf>] __dev_kfree_skb_any+0x3b/0x3d
  [<ffffffffa04c6a8f>] dev_kfree_skb_any+0xe/0x10 [ath10k_core]
  [<ffffffffa04c7f04>] ath10k_htt_rx_detach+0x8f/0xf8 [ath10k_core]
  [<ffffffffa04c6973>] ath10k_htt_detach+0xe/0x1b [ath10k_core]
  [<ffffffffa04c4fba>] ath10k_core_stop+0x4f/0x70 [ath10k_core]
  [<ffffffffa04c1aea>] ath10k_halt+0xd2/0x155 [ath10k_core]
  [<ffffffffa04c1ba5>] ath10k_stop+0x38/0x89 [ath10k_core]
  [<ffffffffa039ab8a>] ieee80211_stop_device+0x58/0x84 [mac80211]
  [<ffffffffa04bc3b6>] ? spin_lock_bh+0x9/0xb [ath10k_core]
  [<ffffffffa03871d3>] ieee80211_do_stop+0x5ec/0x644 [mac80211]
  [<ffffffff810fdcca>] ? trace_hardirqs_on+0xd/0xf
  [<ffffffff810c6b72>] ? __local_bh_enable_ip+0xaf/0xd9
  [<ffffffff815d5cf6>] ? _raw_spin_unlock_bh+0x31/0x35
  [<ffffffff815382f3>] ? dev_deactivate_many+0x129/0x172
  [<ffffffffa0387240>] ieee80211_stop+0x15/0x19 [mac80211]
  [<ffffffff81519cea>] __dev_close_many+0x95/0xba
  [<ffffffff81519d8e>] __dev_close+0x48/0x67
  [<ffffffff81520445>] __dev_change_flags+0xa6/0x14a
  [<ffffffff8152051c>] dev_change_flags+0x23/0x59
  [<ffffffff81529ff1>] do_setlink+0x2d0/0x78c
  [<ffffffff810fdaf4>] ? mark_held_locks+0x71/0x99
  [<ffffffff81158b5b>] ? get_page_from_freelist+0x5b1/0x789
  [<ffffffff8152ccb0>] rtnl_newlink+0x361/0x591
  [<ffffffff8152ca53>] ? rtnl_newlink+0x104/0x591
  [<ffffffff810fc927>] ? __lock_acquire+0x390/0xe48
  [<ffffffff810fdaf4>] ? mark_held_locks+0x71/0x99
  [<ffffffff815d3d19>] ? mutex_lock_nested+0x340/0x3e0
  [<ffffffff8152c93c>] rtnetlink_rcv_msg+0x186/0x199
  [<ffffffff815d3d21>] ? mutex_lock_nested+0x348/0x3e0
  [<ffffffff81529941>] ? rtnl_lock+0x12/0x14
  [<ffffffff81529941>] ? rtnl_lock+0x12/0x14
  [<ffffffff8152c7b6>] ? __rtnl_unlock+0x12/0x12
  [<ffffffff8154238a>] netlink_rcv_skb+0x3d/0x8b
  [<ffffffff81529964>] rtnetlink_rcv+0x21/0x28
  [<ffffffff81541b68>] netlink_unicast+0xc6/0x147
  [<ffffffff81542189>] netlink_sendmsg+0x5a0/0x5e6
  [<ffffffff810fcb85>] ? __lock_acquire+0x5ee/0xe48
  [<ffffffff81507230>] __sock_sendmsg_nosec+0x25/0x27
  [<ffffffff815099d7>] sock_sendmsg+0x5a/0x7b
  [<ffffffff810fd73c>] ? lock_release+0x14e/0x17b
  [<ffffffff8116d3be>] ? might_fault+0x9e/0xa5
  [<ffffffff8116d375>] ? might_fault+0x55/0xa5
  [<ffffffff81514a1d>] ? verify_iovec+0x60/0xb3
  [<ffffffff8150a00c>] ___sys_sendmsg+0x226/0x2d9
  [<ffffffff810fcb85>] ? __lock_acquire+0x5ee/0xe48
  [<ffffffff815d8fc3>] ? __do_page_fault+0x33a/0x3e9
  [<ffffffff811b58d6>] ? rcu_read_unlock+0x21/0x23
  [<ffffffff810fd7fd>] ? lock_acquire+0x94/0x9d
  [<ffffffff81115cc3>] ? read_seqcount_begin.constprop.25+0x73/0x90
  [<ffffffff8150ad08>] __sys_sendmsg+0x3d/0x5b
  [<ffffffff8150ad33>] SyS_sendmsg+0xd/0x19
  [<ffffffff815dac7d>] system_call_fastpath+0x1a/0x1f
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 17 00 17 02 88 ff ff 
00 00 00 00 00 00 00 00 c0 06 30 16 02
RIP  [<ffff880216300600>] 0xffff880216300600
  RSP <ffff8800d295f460>
CR2: ffff880216300600
---[ end trace ba1206597cf05a01 ]---

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From aaronmray at ohioitguy.com  Thu Apr 10 19:20:09 2014
From: aaronmray at ohioitguy.com (Aaron Ray)
Date: Thu, 10 Apr 2014 19:20:09 -0400
Subject: WDS and adhoc support with ath10k
In-Reply-To: <CAGsNzD+vQosTK8-ikrxwzrSXY8kzc+GHg5QutB8KdNsHCE8-9w@mail.gmail.com>
References: <CAGsNzDJ4hDBa82bUFTQkUqjuRuKOaOVMJDsFZUUvdPGf+iKBdQ@mail.gmail.com>
 <CAEFj985jaYoB0fgoY7G0vstcPJTTtGGLy_unAaTWUKvKGDwChw@mail.gmail.com>
 <CAGsNzD+vQosTK8-ikrxwzrSXY8kzc+GHg5QutB8KdNsHCE8-9w@mail.gmail.com>
Message-ID: <CAGsNzDKvcp453sPLMEa1DTmstCoQT-hVCc=nPucSnmOp3PrerA@mail.gmail.com>

Thanks for the response. I'm currently in AP mode, and this was the result:

root at OpenWrt:~# iw dev wlan0 set 4addr on
command failed: Operation not supported (-122)

I thought for sure that command was going to fix it. The link seems to
be up and running fine, it's the extended addressing that seems to not
be working. I've noticed arp requests are going unanswered.

On Thu, Apr 10, 2014 at 7:19 PM, Aaron Ray <aaronmray at ohioitguy.com> wrote:
> Thanks for the response. I'm currently in AP mode, and this was the result:
>
> root at OpenWrt:~# iw dev wlan0 set 4addr on
> command failed: Operation not supported (-122)
>
> I thought for sure that command was going to fix it. The link seems to be up
> and running fine, it's the extended addressing that seems to not be working.
> I've noticed arp requests are going unanswered.
>
>
> On Thu, Apr 10, 2014 at 2:17 AM, Yeoh Chun-Yeow <yeohchunyeow at gmail.com>
> wrote:
>>
>> Just make sure that the adhoc mode is working first before proceed to WDS.
>>
>> Be sure the firmware version is as follow:
>> [   13.810000] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw
>> 999.999.0.636 api 2 htt 2.1
>>
>> I haven't tried the adhoc mode with WDS, but did try for managed and
>> AP interface.
>>
>> I think that you need to turn on the 4addr flag in iw:
>> iw dev wlan0 set 4addr on
>>
>> ----
>> Chun-Yeow
>>
>> On Thu, Apr 10, 2014 at 12:07 AM, Aaron Ray <aaronmray at ohioitguy.com>
>> wrote:
>> > I've been exploring WDS support in OpenWRT and ath10k. I'm running the
>> > latest openwrt trunk as of this weekend and I'm NOT able to get WDS
>> > working on my ath10k card.
>> >
>> > No sta adapter is created also iw doesn't list any support for WDS.
>> > I'd like to get this working if anyone has any ideas.
>> >
>> > _______________________________________________
>> > ath10k mailing list
>> > ath10k at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/ath10k
>
>


From yeohchunyeow at gmail.com  Thu Apr 10 20:57:29 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Fri, 11 Apr 2014 08:57:29 +0800
Subject: WDS and adhoc support with ath10k
In-Reply-To: <CAGsNzDKvcp453sPLMEa1DTmstCoQT-hVCc=nPucSnmOp3PrerA@mail.gmail.com>
References: <CAGsNzDJ4hDBa82bUFTQkUqjuRuKOaOVMJDsFZUUvdPGf+iKBdQ@mail.gmail.com>
 <CAEFj985jaYoB0fgoY7G0vstcPJTTtGGLy_unAaTWUKvKGDwChw@mail.gmail.com>
 <CAGsNzD+vQosTK8-ikrxwzrSXY8kzc+GHg5QutB8KdNsHCE8-9w@mail.gmail.com>
 <CAGsNzDKvcp453sPLMEa1DTmstCoQT-hVCc=nPucSnmOp3PrerA@mail.gmail.com>
Message-ID: <CAEFj984r21nCirRaTm4qr3qTcjm9Rf3xPs8Fr2P2XeaodvaeHg@mail.gmail.com>

Take a look on hostapd.conf, and if you have set bridge parameter,
then WDS is turned on in AP mode.

bridge=br0

# WDS (4-address frame) mode with per-station virtual interfaces
# (only supported with driver=nl80211)
# This mode allows associated stations to use 4-address frames to allow layer 2
# bridging to be used.
#wds_sta=1

# If bridge parameter is set, the WDS STA interface will be added to the same
# bridge by default. This can be overridden with the wds_bridge parameter to
# use a separate bridge.
#wds_bridge=wds-br0

-----
Chun-Yeow

On Fri, Apr 11, 2014 at 7:20 AM, Aaron Ray <aaronmray at ohioitguy.com> wrote:
> Thanks for the response. I'm currently in AP mode, and this was the result:
>
> root at OpenWrt:~# iw dev wlan0 set 4addr on
> command failed: Operation not supported (-122)
>
> I thought for sure that command was going to fix it. The link seems to
> be up and running fine, it's the extended addressing that seems to not
> be working. I've noticed arp requests are going unanswered.
>
> On Thu, Apr 10, 2014 at 7:19 PM, Aaron Ray <aaronmray at ohioitguy.com> wrote:
>> Thanks for the response. I'm currently in AP mode, and this was the result:
>>
>> root at OpenWrt:~# iw dev wlan0 set 4addr on
>> command failed: Operation not supported (-122)
>>
>> I thought for sure that command was going to fix it. The link seems to be up
>> and running fine, it's the extended addressing that seems to not be working.
>> I've noticed arp requests are going unanswered.
>>
>>
>> On Thu, Apr 10, 2014 at 2:17 AM, Yeoh Chun-Yeow <yeohchunyeow at gmail.com>
>> wrote:
>>>
>>> Just make sure that the adhoc mode is working first before proceed to WDS.
>>>
>>> Be sure the firmware version is as follow:
>>> [   13.810000] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw
>>> 999.999.0.636 api 2 htt 2.1
>>>
>>> I haven't tried the adhoc mode with WDS, but did try for managed and
>>> AP interface.
>>>
>>> I think that you need to turn on the 4addr flag in iw:
>>> iw dev wlan0 set 4addr on
>>>
>>> ----
>>> Chun-Yeow
>>>
>>> On Thu, Apr 10, 2014 at 12:07 AM, Aaron Ray <aaronmray at ohioitguy.com>
>>> wrote:
>>> > I've been exploring WDS support in OpenWRT and ath10k. I'm running the
>>> > latest openwrt trunk as of this weekend and I'm NOT able to get WDS
>>> > working on my ath10k card.
>>> >
>>> > No sta adapter is created also iw doesn't list any support for WDS.
>>> > I'd like to get this working if anyone has any ideas.
>>> >
>>> > _______________________________________________
>>> > ath10k mailing list
>>> > ath10k at lists.infradead.org
>>> > http://lists.infradead.org/mailman/listinfo/ath10k
>>
>>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From greearb at candelatech.com  Fri Apr 11 00:59:11 2014
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 10 Apr 2014 21:59:11 -0700
Subject: [RFTv2 3/5] ath10k: rework peer accounting
In-Reply-To: <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>
Message-ID: <5347769F.2020808@candelatech.com>

On 04/09/2014 03:48 AM, Michal Kazior wrote:
> It was troublesome to iterate over peers and
> perform sleepable calls. This will be necessary
> for some upcomming changes to tx flushing.

Just FYI, I tried all yesterday to get my system stable with all
of your RFT patches applied, but it just has all sorts of issues.
I think much of it relates to the management flush logic, perhaps
all the time it spends under lock (including RTNL lock I think)
just makes my system fall apart.

Possibly related to my peculiar environment & firmware, for sure.

I backed out your last two, leaving this one and the two previous,
and it runs better.  I still see the tx-credits hang (this time,
when I tried resetting all 32 stations while transmitting packets),
but at least the stations come up and can transmit packets most of
the time.

Even in the 'mostly working' state, resetting interfaces while
they and other vifs are under heavy packet load can effectively
lock up my user-space app, and things like 'ifconfig -a'
can take 10s of seconds to complete.  So, I probably need
to mitigate more of the sleeps related to flushing somehow.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From michal.kazior at tieto.com  Fri Apr 11 01:21:32 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 11 Apr 2014 07:21:32 +0200
Subject: Question on ath10k_mgmt_tx_flush
In-Reply-To: <53469F7B.2080202@candelatech.com>
References: <53469F7B.2080202@candelatech.com>
Message-ID: <CA+BoTQmc=n7ifUh+8Lq_1P=t4KJyDDFjcs3Z1mW1nHFO+WR2hw@mail.gmail.com>

On 10 April 2014 15:41, Ben Greear <greearb at candelatech.com> wrote:
> Can we optimize this method to return early if the tx-credits
> are fully replenished (ie, == 2) instead of just sleeping the
> 2 x beacon-interval?  That would indicate all messages
> have been flushed, right?

Yeah. You're _almost_ right. Every odd mgmt frame will trigger tx
credit replenishment, even if you set NEEDS_CREDITS htc tx flag for
all packets. It seems that tx credits aren't replenished until you
submit an even number of mgmt tx:

 [tx credits =2]
 vdev create [-1, =1]
 [replenish +1, =2]
 mgmt tx [-1, =1]
 [frame is seen on air, means it left tx queue, but no replenishment]
 vdev set param [-1, =0]
 [replenish +1, =1]
 mgmt tx [-1, =0]
 [frame seen on air]
 [replenish +2, =2]

However once you flush peer tids you get the tx credit immediately.
This means you don't ever reach having 2 mgmt tx consuming 2 tx
credits (unless things go terribly terribly wrong at which point it's
probably already beyond help).

A very ugly hack would be to try and send out mgmt tx in pairs - a
requested frame and a dummy frame (such that firmware will not buffer
it) so that you use tx credit replenishment as tx completion
indication.


Micha?


From kvalo at qca.qualcomm.com  Fri Apr 11 01:25:20 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 11 Apr 2014 08:25:20 +0300
Subject: [PATCH v2 0/2] ath10k: fix radar/cac
In-Reply-To: <1396610926-5787-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 4 Apr 2014 13:28:44 +0200")
References: <1396337123-12622-1-git-send-email-michal.kazior@tieto.com>
 <1396610926-5787-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87bnw8h1z3.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> Hi,
>
> This loosely depends on `ath10k: refactor monitor
> code`. Without it patch this patchset introduces
> some (harmless) runtime warnings.
>
> This v2 introduces a non-functional patch to avoid
> forward declaration. The [1/2] has a little
> conflict with `ath10k: refactor monitor code`
> which renames ath10k_monitor_stop() to
> ath10k_monitor_vdev_stop().
>
> Part of the original CAC problem is also addressed
> in `mac80211: fix radar_enabled propagation`.
>
>
> Michal Kazior (2):
>   ath10k: reorder functions
>   ath10k: refactor radar detection code

Thanks, both patches applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Fri Apr 11 01:27:16 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 11 Apr 2014 08:27:16 +0300
Subject: [PATCH v2] ath10k: improve htc tx credit debugging prints
In-Reply-To: <1396956100-26668-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Tue, 8 Apr 2014 13:21:40 +0200")
References: <1396955920-25863-1-git-send-email-michal.kazior@tieto.com>
 <1396956100-26668-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <877g6wh1vv.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> This way it's easier to track and debug htc tx
> credit issues.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Fri Apr 11 01:40:56 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 11 Apr 2014 08:40:56 +0300
Subject: [PATCH] ath10k: double check bmi xfer pointers
In-Reply-To: <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Thu, 10 Apr 2014 12:05:55 +0200")
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <8738hkh193.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> If for some reason copy engine ring buffer became
> corrupt ath10k could crash the machine due to
> invalid pointer dereference. It's very unlikely
> but devices can never be fully trusted so verify
> if the bmi xfer pointer read back from copy engine
> matches the original pointer.

The big question is why does this happen? Does this happen only with
Ben's firmware or is it a more generic problem?

-- 
Kalle Valo


From michal.kazior at tieto.com  Fri Apr 11 01:47:44 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 11 Apr 2014 07:47:44 +0200
Subject: [PATCH] ath10k: double check bmi xfer pointers
In-Reply-To: <8738hkh193.fsf@kamboji.qca.qualcomm.com>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>

On 11 April 2014 07:40, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> If for some reason copy engine ring buffer became
>> corrupt ath10k could crash the machine due to
>> invalid pointer dereference. It's very unlikely
>> but devices can never be fully trusted so verify
>> if the bmi xfer pointer read back from copy engine
>> matches the original pointer.
>
> The big question is why does this happen? Does this happen only with
> Ben's firmware or is it a more generic problem?

I'll look more into this.


Micha?


From kvalo at qca.qualcomm.com  Fri Apr 11 02:22:50 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 11 Apr 2014 09:22:50 +0300
Subject: [RFTv2 3/5] ath10k: rework peer accounting
In-Reply-To: <CA+BoTQkL8Vp_hjOP-=RZL97QXScF+WVX=BGf6d-HY8cQmu=WCQ@mail.gmail.com>
 (Michal Kazior's message of "Thu, 10 Apr 2014 09:43:13 +0200")
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>
 <87k3axhdqc.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=c+dTcK_diBKi6VJVgUkyBv21bDkRf+9GvGyhhqqMuNQ@mail.gmail.com>
 <87fvllhctr.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQkL8Vp_hjOP-=RZL97QXScF+WVX=BGf6d-HY8cQmu=WCQ@mail.gmail.com>
Message-ID: <87r454fkqt.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> On 10 April 2014 09:18, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior at tieto.com> writes:
>>
>>> The idea is you need BOTH locks to modify the list structure, but you
>>> need only one of them to iterate over the list safely and
>>> consistently. This means writer will not alter the list structure
>>> until there are no readers.
>>
>> Still not understanding this. Why not then use conf_mutex always, why do
>> we need data_lock at all?
>
> htt peer map/unmap which is in tasklet context needs to iterate over
> the list. It can't take conf_mutex.
>
>> Or are you saying that one can iterate the list by either taking
>> conf_mutex or by taking data_lock, depending on context?
>
> Yes.

Thanks, finally I understand this. At least the comment below needs to
be changed to cover all cases:

--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -100,13 +100,13 @@ exit:
 		wake_up(&htt->empty_tx_wq);
 }
 
+/* hold conf_mutex for simple iteration, or conf_mutex+data_lock for
+ * modifications */
 struct ath10k_peer *ath10k_peer_find(struct ath10k *ar, int vdev_id,
 				     const u8 *addr)
 {
 	struct ath10k_peer *peer;
 
-	lockdep_assert_held(&ar->data_lock);
-
 	list_for_each_entry(peer, &ar->peers, list) {
 		if (peer->vdev_id != vdev_id)
 			continue;

The other thing is that I really like the idea of documenting locking
requirements with lockdep_assert_held() and I hate to lose that in this
function. I started to think should we come up with our own macro for
checking if either of two locks is held? When I look at the original
macro I think it should be pretty easy:

#define lockdep_assert_held(l)	do {				\
		WARN_ON(debug_locks && !lockdep_is_held(l));	\
	} while (0)

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Fri Apr 11 02:31:56 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 11 Apr 2014 09:31:56 +0300
Subject: [RFTv2 3/5] ath10k: rework peer accounting
In-Reply-To: <CA+BoTQ=c+dTcK_diBKi6VJVgUkyBv21bDkRf+9GvGyhhqqMuNQ@mail.gmail.com>
 (Michal Kazior's message of "Thu, 10 Apr 2014 09:11:13 +0200")
References: <1396611464-5940-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-1-git-send-email-michal.kazior@tieto.com>
 <1397040531-6224-4-git-send-email-michal.kazior@tieto.com>
 <87k3axhdqc.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=c+dTcK_diBKi6VJVgUkyBv21bDkRf+9GvGyhhqqMuNQ@mail.gmail.com>
Message-ID: <87mwfsfkbn.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> On 10 April 2014 08:59, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior at tieto.com> writes:
>>
>>> It was troublesome to iterate over peers and
>>> perform sleepable calls. This will be necessary
>>> for some upcomming changes to tx flushing.
>>>
>>> Make peer allocation and initial setup
>>> protected by both ar->conf_mutex and
>>> ar->data_lock. This way it's possible to iterate
>>> over peers with conf_mutex and call sleepable
>>> functions.
>>>
>>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>>
>> First comments, but I need to read this much more carefully still:
>>
>>> --- a/drivers/net/wireless/ath/ath10k/core.h
>>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>>> @@ -199,9 +199,14 @@ struct ath10k_dfs_stats {
>>>  #define ATH10K_MAX_NUM_PEER_IDS (1 << 11) /* htt rx_desc limit */
>>>
>>>  struct ath10k_peer {
>>> +     /* protected by conf_mutex + data_lock */
>>>       struct list_head list;
>>
>> This really needs a lot more documentation. And besides, don't we
>> actually want to protect struct ath10k::peers, not this?
>
> Parts of the structure needs to be locked differently.
>
> I suppose we can say we just protect everything with data_lock except
> `struct list_head list` which needs to be write-protected by both
> conf_mutex and data_lock. But then again, addr and vdev_id don't need
> any locking as they are immutable (and set before adding to the list).

I guess this depends from the point of view. In my opinion struct
ath10k::peers is the actual list and that's why the main documentation
needs to be above struct ath10k::peers field. And I would guess that's
there most people check there for documentation first.

But if we have special rules within struct ath10k_peer (excluding the
list field), we can document that within struct ath10k_peer.

-- 
Kalle Valo


From michal.kazior at tieto.com  Fri Apr 11 03:58:54 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 11 Apr 2014 09:58:54 +0200
Subject: [PATCH] ath10k: double check bmi xfer pointers
In-Reply-To: <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
Message-ID: <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>

On 11 April 2014 07:47, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 11 April 2014 07:40, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior at tieto.com> writes:
>>
>>> If for some reason copy engine ring buffer became
>>> corrupt ath10k could crash the machine due to
>>> invalid pointer dereference. It's very unlikely
>>> but devices can never be fully trusted so verify
>>> if the bmi xfer pointer read back from copy engine
>>> matches the original pointer.
>>
>> The big question is why does this happen? Does this happen only with
>> Ben's firmware or is it a more generic problem?
>
> I'll look more into this.

Hmm.. After going through the code a few times I think the bug is
actually something else.

If the crash happened in complete() it means the completion structure
wasn't set up properly. However it is always initialized in
ath10k_pci_hif_exchange_bmi_msg() before proceeding. This means xfer
pointer read back from ath10k_ce_completed_send_next() or
ath10k_ce_completed_recv_next() is wrong. Since the pointer to it is
kept on host getting wrong xfer means sw_index must be wrong. If I
assume indexes are managed correctly (i.e. no overflows, locking is
fine) then it is the entry the sw_index points to that is actually
unexpected.

This could happen if concurrent transfers occur on pipe 0 or 1 (used
for bmi communication) during device bootup. This could be either a
concurrent bmi transfer or a non-bmi buffer or an old bmi xfer data.
The latter shouldn't be the case because
ath10k_pci_hif_exchange_bmi_msg() cleans up after itself. Concurrent
access doesn't seem to be the case either.

I conclude the bug is not present in the vanilla ath10k code.

TL;DR drop the patch, please


Micha?


From johannes at sipsolutions.net  Fri Apr 11 03:59:38 2014
From: johannes at sipsolutions.net (Johannes Berg)
Date: Fri, 11 Apr 2014 09:59:38 +0200
Subject: [PATCH v2 1/2] mac80211: add option to generate CCMP IVs only
 for mgmt frames
In-Reply-To: <1397033857-2523-1-git-send-email-marek.kwaczynski@tieto.com>
 (sfid-20140409_105814_570743_B097AC2A)
References: <1397033857-2523-1-git-send-email-marek.kwaczynski@tieto.com>
 (sfid-20140409_105814_570743_B097AC2A)
Message-ID: <1397203178.4420.6.camel@jlt4.sipsolutions.net>

On Wed, 2014-04-09 at 10:57 +0200, Marek Kwaczynski wrote:
> Some chips can encrypt managment frames in HW, but
> require generated IV in the frame. Add a key flag
> that allows us to achieve this.

> + * @IEEE80211_KEY_FLAG_GENERATE_MGMT_IV_TX: This flag should be set by the
> + *	driver for a CCMP key to indicate that is requires IV generation
> + *	only for managment frames (MFP).

Maybe IEEE80211_KEY_FLAG_GENERATE_IV_MGMT would be better and matching
the IEEE80211_KEY_FLAG_GENERATE_IV better?

>   */
>  enum ieee80211_key_flags {
> -	IEEE80211_KEY_FLAG_GENERATE_IV	= 1<<1,
> +	IEEE80211_KEY_FLAG_GENERATE_IV		= 1<<1,

Since you're touching all these, please convert them all to BIT().

> @@ -625,8 +625,9 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
>  				tx->key = NULL;
>  			else
>  				skip_hw = (tx->key->conf.flags &
> -					   IEEE80211_KEY_FLAG_SW_MGMT_TX) &&
> -					ieee80211_is_mgmt(hdr->frame_control);
> +				   (IEEE80211_KEY_FLAG_SW_MGMT_TX |
> +				    IEEE80211_KEY_FLAG_GENERATE_MGMT_IV_TX)) &&
> +				    ieee80211_is_mgmt(hdr->frame_control);

This seems wrong, you don't want to skip_hw in this case, you just want
to have the IV generated.

> +	/* hwaccel - with software CCMP header or the HW needs
> +	 * generated the IV
> +	 */
> +	if (info->control.hw_key ||
> +	    (key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_MGMT_IV_TX))
>  		return 0;

This seems equally wrong, and it looks like maybe in this case two
wrongs make a right, but I think you should probably put it in the
place(s) where IEEE80211_KEY_FLAG_GENERATE_IV is checked.

johannes



From greearb at candelatech.com  Fri Apr 11 09:25:26 2014
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 11 Apr 2014 06:25:26 -0700
Subject: Question on ath10k_mgmt_tx_flush
In-Reply-To: <CA+BoTQmc=n7ifUh+8Lq_1P=t4KJyDDFjcs3Z1mW1nHFO+WR2hw@mail.gmail.com>
References: <53469F7B.2080202@candelatech.com>
 <CA+BoTQmc=n7ifUh+8Lq_1P=t4KJyDDFjcs3Z1mW1nHFO+WR2hw@mail.gmail.com>
Message-ID: <5347ED46.3000406@candelatech.com>

On 04/10/2014 10:21 PM, Michal Kazior wrote:
> On 10 April 2014 15:41, Ben Greear <greearb at candelatech.com> wrote:
>> Can we optimize this method to return early if the tx-credits
>> are fully replenished (ie, == 2) instead of just sleeping the
>> 2 x beacon-interval?  That would indicate all messages
>> have been flushed, right?
>
> Yeah. You're _almost_ right. Every odd mgmt frame will trigger tx
> credit replenishment, even if you set NEEDS_CREDITS htc tx flag for
> all packets. It seems that tx credits aren't replenished until you
> submit an even number of mgmt tx:
>
>   [tx credits =2]
>   vdev create [-1, =1]
>   [replenish +1, =2]
>   mgmt tx [-1, =1]
>   [frame is seen on air, means it left tx queue, but no replenishment]
>   vdev set param [-1, =0]
>   [replenish +1, =1]
>   mgmt tx [-1, =0]
>   [frame seen on air]
>   [replenish +2, =2]
>
> However once you flush peer tids you get the tx credit immediately.
> This means you don't ever reach having 2 mgmt tx consuming 2 tx
> credits (unless things go terribly terribly wrong at which point it's
> probably already beyond help).
>
> A very ugly hack would be to try and send out mgmt tx in pairs - a
> requested frame and a dummy frame (such that firmware will not buffer
> it) so that you use tx credit replenishment as tx completion
> indication.

If you ignore how firmware replenishes the tx-credits for now,
is it safe to assume that if you have 2 tx-credits while in
the flush routine, then everything is indeed flushed and
we can skip the sleep?

I imagine both I and the QCA firmware guys can make the
firmware properly replenish tx-credits one at a time instead
of the only-on-even/odd behaviour you found.

But even without that, we might be able to speed up the
flush 1/2 of the time?

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From vh.nguyen at actiasodielec.fr  Fri Apr 11 08:09:27 2014
From: vh.nguyen at actiasodielec.fr (Vu Hai NGUYEN)
Date: Fri, 11 Apr 2014 17:09:27 +0200
Subject: load module ath10k:  ieee80211 phy0: Failed to initialize wep: -2
In-Reply-To: <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>,
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
Message-ID: <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>

Hello everyone,
I try to load the module of driver ath10k on a cpu marvell 370 which ran linux 3.2.36, my module wifi is  WLE900VX.
These modules was built from backport 3.13.2-1. 
After loading the module, I use the command "lsmod" and saw that 6 modules was loaded.
But my "dmesg" show an error:
ieee80211 phy0: Failed to initialize wep: -2
And the interface ath0 can not be recognized.
Does any one have any idea about this problem????
Thank you in advanced and have a nice weekend :D


NGUYEN Vu Hai
Acita-Sodielec
Route de Mayres - B.P. 9
12100 St GEORGES DE LUZENCON
FRANCE


From michal.kazior at tieto.com  Sun Apr 13 23:31:44 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 14 Apr 2014 08:31:44 +0200
Subject: Question on ath10k_mgmt_tx_flush
In-Reply-To: <5347ED46.3000406@candelatech.com>
References: <53469F7B.2080202@candelatech.com>
 <CA+BoTQmc=n7ifUh+8Lq_1P=t4KJyDDFjcs3Z1mW1nHFO+WR2hw@mail.gmail.com>
 <5347ED46.3000406@candelatech.com>
Message-ID: <CA+BoTQ=oyXd4qCOhBQE5QCu+KYaqB+_9qSdaTL_z_m2C=c=WYg@mail.gmail.com>

On 11 April 2014 15:25, Ben Greear <greearb at candelatech.com> wrote:
> On 04/10/2014 10:21 PM, Michal Kazior wrote:
>>
>> On 10 April 2014 15:41, Ben Greear <greearb at candelatech.com> wrote:
>>>
>>> Can we optimize this method to return early if the tx-credits
>>> are fully replenished (ie, == 2) instead of just sleeping the
>>> 2 x beacon-interval?  That would indicate all messages
>>> have been flushed, right?
>>
>>
>> Yeah. You're _almost_ right. Every odd mgmt frame will trigger tx
>> credit replenishment, even if you set NEEDS_CREDITS htc tx flag for
>> all packets. It seems that tx credits aren't replenished until you
>> submit an even number of mgmt tx:
>>
>>   [tx credits =2]
>>   vdev create [-1, =1]
>>   [replenish +1, =2]
>>   mgmt tx [-1, =1]
>>   [frame is seen on air, means it left tx queue, but no replenishment]
>>   vdev set param [-1, =0]
>>   [replenish +1, =1]
>>   mgmt tx [-1, =0]
>>   [frame seen on air]
>>   [replenish +2, =2]
>>
>> However once you flush peer tids you get the tx credit immediately.
>> This means you don't ever reach having 2 mgmt tx consuming 2 tx
>> credits (unless things go terribly terribly wrong at which point it's
>> probably already beyond help).
>>
>> A very ugly hack would be to try and send out mgmt tx in pairs - a
>> requested frame and a dummy frame (such that firmware will not buffer
>> it) so that you use tx credit replenishment as tx completion
>> indication.
>
>
> If you ignore how firmware replenishes the tx-credits for now,
> is it safe to assume that if you have 2 tx-credits while in
> the flush routine, then everything is indeed flushed and
> we can skip the sleep?

You want to always skip the sleep between mgmt tx and flush commands?
I'm afraid this won't work because tx flush command can end up with
queued frame being dropped or transmitted regardless of destination
station powersave state if submitted too soon.


> I imagine both I and the QCA firmware guys can make the
> firmware properly replenish tx-credits one at a time instead
> of the only-on-even/odd behaviour you found.

That would be nice.


> But even without that, we might be able to speed up the
> flush 1/2 of the time?

Yes, although I'm not very fond of the idea of applying a hack on top
of another hack.


Micha?


From michal.kazior at tieto.com  Sun Apr 13 23:39:58 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 14 Apr 2014 08:39:58 +0200
Subject: load module ath10k: ieee80211 phy0: Failed to initialize wep: -2
In-Reply-To: <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
Message-ID: <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>

On 11 April 2014 17:09, Vu Hai NGUYEN <vh.nguyen at actiasodielec.fr> wrote:
> Hello everyone,
> I try to load the module of driver ath10k on a cpu marvell 370 which ran linux 3.2.36, my module wifi is  WLE900VX.
> These modules was built from backport 3.13.2-1.
> After loading the module, I use the command "lsmod" and saw that 6 modules was loaded.
> But my "dmesg" show an error:
> ieee80211 phy0: Failed to initialize wep: -2
> And the interface ath0 can not be recognized.
> Does any one have any idea about this problem????

I'm guessing here, but I suspect you tried to load a backports driver
against cfg80211/mac80211 modules from your distro kernel.


Micha?


From michal.kazior at tieto.com  Mon Apr 14 00:20:06 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 14 Apr 2014 09:20:06 +0200
Subject: [PATCHv2 0/4] ath10k: AP-related fixes
In-Reply-To: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
References: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397460010-19153-1-git-send-email-michal.kazior@tieto.com>

Hi,

This is a bunch of fixes I've found while
investigating tx credit issues.

I've only experienced problem fixed by 4/4
firsthand. Other patches are preemptive fixes :-)

v2:
 * minor tweaks

Michal Kazior (4):
  ath10k: make sure to not leak beacon dma mapping
  ath10k: make sure to not use invalid beacon pointer
  ath10k: prevent beacon memory leak
  ath10k: fix firmware recovery with ap interface

 drivers/net/wireless/ath/ath10k/mac.c | 16 ++++++++++++++++
 drivers/net/wireless/ath/ath10k/wmi.c |  2 ++
 2 files changed, 18 insertions(+)

-- 
1.8.5.3



From michal.kazior at tieto.com  Mon Apr 14 00:20:07 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 14 Apr 2014 09:20:07 +0200
Subject: [PATCHv2 1/4] ath10k: make sure to not leak beacon dma mapping
In-Reply-To: <1397460010-19153-1-git-send-email-michal.kazior@tieto.com>
References: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
 <1397460010-19153-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397460010-19153-2-git-send-email-michal.kazior@tieto.com>

If for some reason mac80211 wouldn't stop
beaconing gracefully and just removed interface of
a running AP/IBSS interface it was possible to
leak pending beacon DMA mapping. It's very
unlikely but better safe than sorry.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 8385a7a..22e8239 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2771,6 +2771,9 @@ static void ath10k_remove_interface(struct ieee80211_hw *hw,
 
 	spin_lock_bh(&ar->data_lock);
 	if (arvif->beacon) {
+		dma_unmap_single(arvif->ar->dev,
+				 ATH10K_SKB_CB(arvif->beacon)->paddr,
+				 arvif->beacon->len, DMA_TO_DEVICE);
 		dev_kfree_skb_any(arvif->beacon);
 		arvif->beacon = NULL;
 	}
-- 
1.8.5.3



From michal.kazior at tieto.com  Mon Apr 14 00:20:08 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 14 Apr 2014 09:20:08 +0200
Subject: [PATCHv2 2/4] ath10k: make sure to not use invalid beacon pointer
In-Reply-To: <1397460010-19153-1-git-send-email-michal.kazior@tieto.com>
References: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
 <1397460010-19153-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397460010-19153-3-git-send-email-michal.kazior@tieto.com>

If DMA mapping of next beacon failed it was
possible for next SWBA to access a pointer that
was already unmapped and freed. This could cause
memory corruption.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
v2:
 * move arvif->beacon=NULL after dev_kfree_skb() [Kalle]

 drivers/net/wireless/ath/ath10k/wmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index fe4d5f1..11176cc 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1431,6 +1431,7 @@ static void ath10k_wmi_event_host_swba(struct ath10k *ar, struct sk_buff *skb)
 					 ATH10K_SKB_CB(arvif->beacon)->paddr,
 					 arvif->beacon->len, DMA_TO_DEVICE);
 			dev_kfree_skb_any(arvif->beacon);
+			arvif->beacon = NULL;
 		}
 
 		ATH10K_SKB_CB(bcn)->paddr = dma_map_single(arvif->ar->dev,
-- 
1.8.5.3



From michal.kazior at tieto.com  Mon Apr 14 00:20:09 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 14 Apr 2014 09:20:09 +0200
Subject: [PATCHv2 3/4] ath10k: prevent beacon memory leak
In-Reply-To: <1397460010-19153-1-git-send-email-michal.kazior@tieto.com>
References: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
 <1397460010-19153-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397460010-19153-4-git-send-email-michal.kazior@tieto.com>

If DMA mapping of next beacon failed ath10k leaked
the beacon.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 11176cc..72cc4f2 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1441,6 +1441,7 @@ static void ath10k_wmi_event_host_swba(struct ath10k *ar, struct sk_buff *skb)
 					ATH10K_SKB_CB(bcn)->paddr);
 		if (ret) {
 			ath10k_warn("failed to map beacon: %d\n", ret);
+			dev_kfree_skb_any(bcn);
 			goto skip;
 		}
 
-- 
1.8.5.3



From michal.kazior at tieto.com  Mon Apr 14 00:20:10 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 14 Apr 2014 09:20:10 +0200
Subject: [PATCHv2 4/4] ath10k: fix firmware recovery with ap interface
In-Reply-To: <1397460010-19153-1-git-send-email-michal.kazior@tieto.com>
References: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
 <1397460010-19153-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397460010-19153-5-git-send-email-michal.kazior@tieto.com>

Beacon data wasn't properly cleared during early
phase of recovery. This in turn caused firmware to
crash because the beacon data was submitted before
vdevs were fully re-configured. Ultimately the
device was considered wedged and nothing worked
until driver was reloaded.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 22e8239..e2c01dc 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2291,6 +2291,8 @@ static void ath10k_tx(struct ieee80211_hw *hw,
  */
 void ath10k_halt(struct ath10k *ar)
 {
+	struct ath10k_vif *arvif;
+
 	lockdep_assert_held(&ar->conf_mutex);
 
 	if (ath10k_monitor_is_enabled(ar)) {
@@ -2313,6 +2315,17 @@ void ath10k_halt(struct ath10k *ar)
 		ar->scan.in_progress = false;
 		ieee80211_scan_completed(ar->hw, true);
 	}
+
+	list_for_each_entry(arvif, &ar->arvifs, list) {
+		if (!arvif->beacon)
+			continue;
+
+		dma_unmap_single(arvif->ar->dev,
+				 ATH10K_SKB_CB(arvif->beacon)->paddr,
+				 arvif->beacon->len, DMA_TO_DEVICE);
+		dev_kfree_skb_any(arvif->beacon);
+		arvif->beacon = NULL;
+	}
 	spin_unlock_bh(&ar->data_lock);
 }
 
-- 
1.8.5.3



From michal.kazior at tieto.com  Mon Apr 14 00:22:23 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 14 Apr 2014 09:22:23 +0200
Subject: [PATCHv2 0/3] ath10k: improve recovery speed
In-Reply-To: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
References: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397460146-19450-1-git-send-email-michal.kazior@tieto.com>

Hi,

Patch 1/3 is just a cleanup I wanted to keep
separate from 2/3 which actually improves recovery
speed.

With this I'm able to recover from a `hard`
simualtion crash in ~3 seconds instead of ~10.

This should decrease the chance of CQM kicking in
on connected clients (due to beacon loss) when
ath10k is acting as AP.

v2:
 * add a comment in the code


Michal Kazior (3):
  ath10k: differentiate between target init failures
  ath10k: don't wait for device init if it crashed
  ath10k: skip suspending when recovering

 drivers/net/wireless/ath/ath10k/core.c |  6 ++++--
 drivers/net/wireless/ath/ath10k/pci.c  | 18 +++++++++++++++++-
 2 files changed, 21 insertions(+), 3 deletions(-)

-- 
1.8.5.3



From michal.kazior at tieto.com  Mon Apr 14 00:22:26 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 14 Apr 2014 09:22:26 +0200
Subject: [PATCHv2 3/3] ath10k: skip suspending when recovering
In-Reply-To: <1397460146-19450-1-git-send-email-michal.kazior@tieto.com>
References: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
 <1397460146-19450-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397460146-19450-4-git-send-email-michal.kazior@tieto.com>

It doesn't make much sense to even try suspending
the device when recovering. Recovering means the
device is unresponsive and waiting for suspend
procedure means taking a 3 second timeout waiting
for tx credits.

This speeds up firmware recovery significantly.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 6abde37..75b3dfb 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -680,8 +680,8 @@ static void ath10k_core_restart(struct work_struct *work)
 
 	switch (ar->state) {
 	case ATH10K_STATE_ON:
-		ath10k_halt(ar);
 		ar->state = ATH10K_STATE_RESTARTING;
+		ath10k_halt(ar);
 		ieee80211_restart_hw(ar->hw);
 		break;
 	case ATH10K_STATE_OFF:
@@ -908,7 +908,9 @@ void ath10k_core_stop(struct ath10k *ar)
 	lockdep_assert_held(&ar->conf_mutex);
 
 	/* try to suspend target */
-	ath10k_wait_for_suspend(ar, WMI_PDEV_SUSPEND_AND_DISABLE_INTR);
+	if (ar->state != ATH10K_STATE_RESTARTING)
+		ath10k_wait_for_suspend(ar, WMI_PDEV_SUSPEND_AND_DISABLE_INTR);
+
 	ath10k_debug_stop(ar);
 	ath10k_htc_stop(&ar->htc);
 	ath10k_htt_detach(&ar->htt);
-- 
1.8.5.3



From michal.kazior at tieto.com  Mon Apr 14 00:22:25 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 14 Apr 2014 09:22:25 +0200
Subject: [PATCHv2 2/3] ath10k: don't wait for device init if it crashed
In-Reply-To: <1397460146-19450-1-git-send-email-michal.kazior@tieto.com>
References: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
 <1397460146-19450-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397460146-19450-3-git-send-email-michal.kazior@tieto.com>

When warm resetting it's possible for device to
crash during initialization. Instead of waiting 3
seconds just return failure as soon as
FW_IND_EVENT_PENDING is set.

This speeds up device bootup and recovery in some
cases.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
v2:
 * add a comment before if() [Kalle]

 drivers/net/wireless/ath/ath10k/pci.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index cd3b00c..66b1f30 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2452,6 +2452,10 @@ static int ath10k_pci_wait_for_target_init(struct ath10k *ar)
 		if (val == 0xffffffff)
 			continue;
 
+		/* the device has crashed so don't bother trying anymore */
+		if (val & FW_IND_EVENT_PENDING)
+			break;
+
 		if (val & FW_IND_INITIALIZED)
 			break;
 
@@ -2470,6 +2474,12 @@ static int ath10k_pci_wait_for_target_init(struct ath10k *ar)
 		goto out;
 	}
 
+	if (val & FW_IND_EVENT_PENDING) {
+		ath10k_warn("device has crashed during init\n");
+		ret = -ECOMM;
+		goto out;
+	}
+
 	if (!(val & FW_IND_INITIALIZED)) {
 		ath10k_err("failed to receive initialized event from target: %08x\n",
 			   val);
-- 
1.8.5.3



From michal.kazior at tieto.com  Mon Apr 14 00:22:24 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 14 Apr 2014 09:22:24 +0200
Subject: [PATCHv2 1/3] ath10k: differentiate between target init failures
In-Reply-To: <1397460146-19450-1-git-send-email-michal.kazior@tieto.com>
References: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
 <1397460146-19450-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1397460146-19450-2-git-send-email-michal.kazior@tieto.com>

This just makes it easier to tell apart different
kinds of bringup failure.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/pci.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index bf1083d..cd3b00c 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2464,7 +2464,13 @@ static int ath10k_pci_wait_for_target_init(struct ath10k *ar)
 		mdelay(10);
 	} while (time_before(jiffies, timeout));
 
-	if (val == 0xffffffff || !(val & FW_IND_INITIALIZED)) {
+	if (val == 0xffffffff) {
+		ath10k_err("failed to read device register, device is gone\n");
+		ret = -EIO;
+		goto out;
+	}
+
+	if (!(val & FW_IND_INITIALIZED)) {
 		ath10k_err("failed to receive initialized event from target: %08x\n",
 			   val);
 		ret = -ETIMEDOUT;
-- 
1.8.5.3



From kvalo at qca.qualcomm.com  Mon Apr 14 01:05:11 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Mon, 14 Apr 2014 11:05:11 +0300
Subject: [PATCH] ath10k: double check bmi xfer pointers
In-Reply-To: <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 (Michal Kazior's message of "Fri, 11 Apr 2014 09:58:54 +0200")
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
Message-ID: <877g6sfia0.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> I conclude the bug is not present in the vanilla ath10k code.
>
> TL;DR drop the patch, please

Hehe. Thanks, I have dropped the patch.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Mon Apr 14 01:10:15 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Mon, 14 Apr 2014 11:10:15 +0300
Subject: load module ath10k: ieee80211 phy0: Failed to initialize wep: -2
In-Reply-To: <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>
 (Michal Kazior's message of "Mon, 14 Apr 2014 08:39:58 +0200")
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
 <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>
Message-ID: <8738hgfi1k.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> On 11 April 2014 17:09, Vu Hai NGUYEN <vh.nguyen at actiasodielec.fr> wrote:
>> Hello everyone,
>> I try to load the module of driver ath10k on a cpu marvell 370 which ran linux 3.2.36, my module wifi is  WLE900VX.
>> These modules was built from backport 3.13.2-1.
>> After loading the module, I use the command "lsmod" and saw that 6 modules was loaded.
>> But my "dmesg" show an error:
>> ieee80211 phy0: Failed to initialize wep: -2
>> And the interface ath0 can not be recognized.

ath0 interface? ath10k does not use interface names like that, that
smells like the proprietary driver.

>> Does any one have any idea about this problem????
>
> I'm guessing here, but I suspect you tried to load a backports driver
> against cfg80211/mac80211 modules from your distro kernel.

Another option is that there's a some sort of problem with the crypto
modules.

-- 
Kalle Valo


From marek.kwaczynski at tieto.com  Mon Apr 14 02:27:21 2014
From: marek.kwaczynski at tieto.com (Marek Kwaczynski)
Date: Mon, 14 Apr 2014 11:27:21 +0200
Subject: [PATCH 1/2 V3] mac80211: add option to generate CCMP IVs only for
 mgmt frames
Message-ID: <1397467642-23544-1-git-send-email-marek.kwaczynski@tieto.com>

Some chips can encrypt managment frames in HW, but
require generated IV in the frame. Add a key flag
that allows us to achieve this.

Signed-off-by: Marek Kwaczynski <marek.kwaczynski at tieto.com>
---
 include/net/mac80211.h |   16 ++++++++++------
 net/mac80211/wpa.c     |    5 ++++-
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 2de7ff4..80d7a5e 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1202,14 +1202,18 @@ struct ieee80211_vif *wdev_to_ieee80211_vif(struct wireless_dev *wdev);
  *	fall back to software crypto. Note that this flag deals only with
  *	RX, if your crypto engine can't deal with TX you can also set the
  *	%IEEE80211_KEY_FLAG_SW_MGMT_TX flag to encrypt such frames in SW.
+ * @IEEE80211_KEY_FLAG_GENERATE_IV_MGMT: This flag should be set by the
+ *	driver for a CCMP key to indicate that is requires IV generation
+ *	only for managment frames (MFP).
  */
 enum ieee80211_key_flags {
-	IEEE80211_KEY_FLAG_GENERATE_IV	= 1<<1,
-	IEEE80211_KEY_FLAG_GENERATE_MMIC= 1<<2,
-	IEEE80211_KEY_FLAG_PAIRWISE	= 1<<3,
-	IEEE80211_KEY_FLAG_SW_MGMT_TX	= 1<<4,
-	IEEE80211_KEY_FLAG_PUT_IV_SPACE = 1<<5,
-	IEEE80211_KEY_FLAG_RX_MGMT	= 1<<6,
+	IEEE80211_KEY_FLAG_GENERATE_IV		= BIT(1),
+	IEEE80211_KEY_FLAG_GENERATE_MMIC	= BIT(2),
+	IEEE80211_KEY_FLAG_PAIRWISE		= BIT(3),
+	IEEE80211_KEY_FLAG_SW_MGMT_TX		= BIT(4),
+	IEEE80211_KEY_FLAG_PUT_IV_SPACE		= BIT(5),
+	IEEE80211_KEY_FLAG_RX_MGMT		= BIT(6),
+	IEEE80211_KEY_FLAG_GENERATE_IV_MGMT	= BIT(7),
 };
 
 /**
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index b8600e3..5b16a36 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -406,7 +406,10 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
 
 	if (info->control.hw_key &&
 	    !(info->control.hw_key->flags & IEEE80211_KEY_FLAG_GENERATE_IV) &&
-	    !(info->control.hw_key->flags & IEEE80211_KEY_FLAG_PUT_IV_SPACE)) {
+	    !(info->control.hw_key->flags & IEEE80211_KEY_FLAG_PUT_IV_SPACE) &&
+	    !((info->control.hw_key->flags &
+	      IEEE80211_KEY_FLAG_GENERATE_IV_MGMT) &&
+	      ieee80211_is_mgmt(hdr->frame_control))) {
 		/*
 		 * hwaccel has no need for preallocated room for CCMP
 		 * header or MIC fields
-- 
1.7.9.5



From marek.kwaczynski at tieto.com  Mon Apr 14 02:27:22 2014
From: marek.kwaczynski at tieto.com (Marek Kwaczynski)
Date: Mon, 14 Apr 2014 11:27:22 +0200
Subject: [PATCH 2/2 V3] ath10k: Fix pmf for action frames
In-Reply-To: <1397467642-23544-1-git-send-email-marek.kwaczynski@tieto.com>
References: <1397467642-23544-1-git-send-email-marek.kwaczynski@tieto.com>
Message-ID: <1397467642-23544-2-git-send-email-marek.kwaczynski@tieto.com>

Fix sending and receiveing protected managment frames.
Lack of protected flag for received protected action frames
causes report these frames as unprotected robust action frames.
If the driver in AP mode sent frame with protected flag and
CCMP header using IEEE80211_KEY_FLAG_SW_MGMT_TX flag,
the FW encrypted frames once again. From user side all
received SA Query Requests and Responses were skipped and
all protected action frames were sent as malformed packets.

Signed-off-by: Marek Kwaczynski <marek.kwaczynski at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c |    5 ++++-
 drivers/net/wireless/ath/ath10k/wmi.c |   24 ++++++++++++++++++++----
 2 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 58ec5a7..38035dc 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -54,7 +54,10 @@ static int ath10k_send_key(struct ath10k_vif *arvif,
 	switch (key->cipher) {
 	case WLAN_CIPHER_SUITE_CCMP:
 		arg.key_cipher = WMI_CIPHER_AES_CCM;
-		key->flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
+		if (arvif->vdev_type == WMI_VDEV_TYPE_AP)
+			key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV_MGMT;
+		else
+			key->flags |= IEEE80211_KEY_FLAG_SW_MGMT_TX;
 		break;
 	case WLAN_CIPHER_SUITE_TKIP:
 		arg.key_cipher = WMI_CIPHER_TKIP;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index d4b48ef..6d8a097 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -639,6 +639,7 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 	struct sk_buff *wmi_skb;
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	int len;
+	u32 buf_len = skb->len;
 	u16 fc;
 
 	hdr = (struct ieee80211_hdr *)skb->data;
@@ -648,6 +649,15 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 		return -EINVAL;
 
 	len = sizeof(cmd->hdr) + skb->len;
+
+	if ((ieee80211_is_action(hdr->frame_control) ||
+	     ieee80211_is_deauth(hdr->frame_control) ||
+	     ieee80211_is_disassoc(hdr->frame_control)) &&
+	     ieee80211_has_protected(hdr->frame_control)) {
+		len += IEEE80211_CCMP_MIC_LEN;
+		buf_len += IEEE80211_CCMP_MIC_LEN;
+	}
+
 	len = round_up(len, 4);
 
 	wmi_skb = ath10k_wmi_alloc_skb(len);
@@ -659,7 +669,7 @@ int ath10k_wmi_mgmt_tx(struct ath10k *ar, struct sk_buff *skb)
 	cmd->hdr.vdev_id = __cpu_to_le32(ATH10K_SKB_CB(skb)->vdev_id);
 	cmd->hdr.tx_rate = 0;
 	cmd->hdr.tx_power = 0;
-	cmd->hdr.buf_len = __cpu_to_le32((u32)(skb->len));
+	cmd->hdr.buf_len = __cpu_to_le32(buf_len);
 
 	memcpy(cmd->hdr.peer_macaddr.addr, ieee80211_get_DA(hdr), ETH_ALEN);
 	memcpy(cmd->buf, skb->data, skb->len);
@@ -957,10 +967,16 @@ static int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
 	 * frames with Protected Bit set. */
 	if (ieee80211_has_protected(hdr->frame_control) &&
 	    !ieee80211_is_auth(hdr->frame_control)) {
-		status->flag |= RX_FLAG_DECRYPTED | RX_FLAG_IV_STRIPPED |
-				RX_FLAG_MMIC_STRIPPED;
-		hdr->frame_control = __cpu_to_le16(fc &
+		status->flag |= RX_FLAG_DECRYPTED;
+
+		if (!ieee80211_is_action(hdr->frame_control) &&
+		    !ieee80211_is_deauth(hdr->frame_control) &&
+		    !ieee80211_is_disassoc(hdr->frame_control)) {
+			status->flag |= RX_FLAG_IV_STRIPPED |
+					RX_FLAG_MMIC_STRIPPED;
+			hdr->frame_control = __cpu_to_le16(fc &
 					~IEEE80211_FCTL_PROTECTED);
+		}
 	}
 
 	ath10k_dbg(ATH10K_DBG_MGMT,
-- 
1.7.9.5



From greearb at candelatech.com  Mon Apr 14 08:45:18 2014
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Apr 2014 08:45:18 -0700
Subject: Question on ath10k_mgmt_tx_flush
In-Reply-To: <CA+BoTQ=oyXd4qCOhBQE5QCu+KYaqB+_9qSdaTL_z_m2C=c=WYg@mail.gmail.com>
References: <53469F7B.2080202@candelatech.com>
 <CA+BoTQmc=n7ifUh+8Lq_1P=t4KJyDDFjcs3Z1mW1nHFO+WR2hw@mail.gmail.com>
 <5347ED46.3000406@candelatech.com>
 <CA+BoTQ=oyXd4qCOhBQE5QCu+KYaqB+_9qSdaTL_z_m2C=c=WYg@mail.gmail.com>
Message-ID: <534C028E.4000302@candelatech.com>

On 04/13/2014 11:31 PM, Michal Kazior wrote:
> On 11 April 2014 15:25, Ben Greear <greearb at candelatech.com> wrote:
>> On 04/10/2014 10:21 PM, Michal Kazior wrote:
>>>
>>> On 10 April 2014 15:41, Ben Greear <greearb at candelatech.com> wrote:
>>>>
>>>> Can we optimize this method to return early if the tx-credits
>>>> are fully replenished (ie, == 2) instead of just sleeping the
>>>> 2 x beacon-interval?  That would indicate all messages
>>>> have been flushed, right?
>>>
>>>
>>> Yeah. You're _almost_ right. Every odd mgmt frame will trigger tx
>>> credit replenishment, even if you set NEEDS_CREDITS htc tx flag for
>>> all packets. It seems that tx credits aren't replenished until you
>>> submit an even number of mgmt tx:
>>>
>>>   [tx credits =2]
>>>   vdev create [-1, =1]
>>>   [replenish +1, =2]
>>>   mgmt tx [-1, =1]
>>>   [frame is seen on air, means it left tx queue, but no replenishment]
>>>   vdev set param [-1, =0]
>>>   [replenish +1, =1]
>>>   mgmt tx [-1, =0]
>>>   [frame seen on air]
>>>   [replenish +2, =2]
>>>
>>> However once you flush peer tids you get the tx credit immediately.
>>> This means you don't ever reach having 2 mgmt tx consuming 2 tx
>>> credits (unless things go terribly terribly wrong at which point it's
>>> probably already beyond help).
>>>
>>> A very ugly hack would be to try and send out mgmt tx in pairs - a
>>> requested frame and a dummy frame (such that firmware will not buffer
>>> it) so that you use tx credit replenishment as tx completion
>>> indication.
>>
>>
>> If you ignore how firmware replenishes the tx-credits for now,
>> is it safe to assume that if you have 2 tx-credits while in
>> the flush routine, then everything is indeed flushed and
>> we can skip the sleep?
> 
> You want to always skip the sleep between mgmt tx and flush commands?
> I'm afraid this won't work because tx flush command can end up with
> queued frame being dropped or transmitted regardless of destination
> station powersave state if submitted too soon.

I just want to know if I can skip the sleep if we currently have 2 tx-credits.

>From your answer below, that seems to be a yes.  So, 1/2 of the time (on avg)
is worth the hack to me, and if/when I fix the firmware (and/or if QCA fixes
the firmware), then we should have 2 tx-credits more often and only sleep when
there really is work to do.

>> I imagine both I and the QCA firmware guys can make the
>> firmware properly replenish tx-credits one at a time instead
>> of the only-on-even/odd behaviour you found.
> 
> That would be nice.
> 
> 
>> But even without that, we might be able to speed up the
>> flush 1/2 of the time?
> 
> Yes, although I'm not very fond of the idea of applying a hack on top
> of another hack.

What is your preferred fix for this?

Thanks,
Ben

> 
> 
> Micha?
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From vh.nguyen at actiasodielec.fr  Mon Apr 14 08:49:21 2014
From: vh.nguyen at actiasodielec.fr (Vu Hai NGUYEN)
Date: Mon, 14 Apr 2014 17:49:21 +0200
Subject: load module ath10k: ieee80211 phy0: Failed to initialize wep: -2
In-Reply-To: <8738hgfi1k.fsf@kamboji.qca.qualcomm.com>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
 <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>,
 <8738hgfi1k.fsf@kamboji.qca.qualcomm.com>
Message-ID: <EE97821C81277E459BEA5C6384C6F241012F06CC4838@srvexch01.SODIELEC.local>

Thank you guys,
My mistake, the interface is wlan0, not ath0 (which is created before from the driver Aquila supplied by Atheros)
And the problem about cfg80211/mac80211 is because that I didn't activate cfg80211 in my new kernel of linux when I re-compile my project. (I just take the modules ath10k that I compiled before from the kernel that I had modified to compile ath10k and then put in my new project)

NGUYEN Vu Hai
Acita-Sodielec
Route de Mayres - B.P. 9
12100 St GEORGES DE LUZENCON
FRANCE

________________________________________
De : Kalle Valo [kvalo at qca.qualcomm.com]
Date d'envoi : lundi 14 avril 2014 10:10
? : Michal Kazior
Cc : Vu Hai NGUYEN; Patrick CARNEIRO RODRIGUEZ; ath10k at lists.infradead.org
Objet : Re: load module ath10k: ieee80211 phy0: Failed to initialize wep: -2

Michal Kazior <michal.kazior at tieto.com> writes:

> On 11 April 2014 17:09, Vu Hai NGUYEN <vh.nguyen at actiasodielec.fr> wrote:
>> Hello everyone,
>> I try to load the module of driver ath10k on a cpu marvell 370 which ran linux 3.2.36, my module wifi is  WLE900VX.
>> These modules was built from backport 3.13.2-1.
>> After loading the module, I use the command "lsmod" and saw that 6 modules was loaded.
>> But my "dmesg" show an error:
>> ieee80211 phy0: Failed to initialize wep: -2
>> And the interface ath0 can not be recognized.

ath0 interface? ath10k does not use interface names like that, that
smells like the proprietary driver.

>> Does any one have any idea about this problem????
>
> I'm guessing here, but I suspect you tried to load a backports driver
> against cfg80211/mac80211 modules from your distro kernel.

Another option is that there's a some sort of problem with the crypto
modules.

--
Kalle Valo


From greearb at candelatech.com  Mon Apr 14 12:36:14 2014
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Apr 2014 12:36:14 -0700
Subject: Modified ath10k firmware is now available for non-commercial use.
Message-ID: <534C38AE.3070504@candelatech.com>

Our modified ath10k firmware binary is now available for download.  It may only be used
for non-commercial purposes unless you get a commercial license from my company.

The main thing this firmware supports that upstream firmware does not
is lots of virtual stations connected to the same AP.  We have some
additional stability fixes we found in testing, and probably have introduced
some bugs as well.  We will be putting ongoing effort into improving
this firmware.

We also have the ability to decode firmware stack dumps (found in
dmesg and/or /var/log/messages) if they come from our firmware.
We cannot share the details of the decode nor tools to decode it,
but we will try to fix the problems and/or describe the results of
our decode in general terms.

The firmware should work with stock 3.14 or other recent kernels,
but we have done most testing using our own modified 3.14 kernel.
Our kernel patches are required to support the additional stations,
software-crypt, and other features specific to our firmware.

If you use our firmware and manage to crash it, please send to me the pertinent
part of /var/log/messages (or dmesg), including any ath10k related ascii
hex dumps.  Other non-crash bug reports are welcome too.

Please do not bother the QCA developers with any bugs specific to our
firmware (or our kernel patches).

Links to the firmware binary, our 3.14.0+ kernel source, and related
info is found here:

http://www.candelatech.com/vsta.php

Please let me know if you have any questions.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From yeohchunyeow at gmail.com  Mon Apr 14 18:38:03 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Tue, 15 Apr 2014 09:38:03 +0800
Subject: Modified ath10k firmware is now available for non-commercial use.
In-Reply-To: <534C38AE.3070504@candelatech.com>
References: <534C38AE.3070504@candelatech.com>
Message-ID: <CAEFj986VEybhQbG4OQptLMGakTD1fOTbbz9H+-TJKPef7ehG9g@mail.gmail.com>

On Tue, Apr 15, 2014 at 3:36 AM, Ben Greear <greearb at candelatech.com> wrote:
> Our modified ath10k firmware binary is now available for download.  It may only be used
> for non-commercial purposes unless you get a commercial license from my company.
>
> The main thing this firmware supports that upstream firmware does not
> is lots of virtual stations connected to the same AP.
Is this firmware mainly for STA mode or AP mode or both?

> We have some
> additional stability fixes we found in testing, and probably have introduced
> some bugs as well.  We will be putting ongoing effort into improving
> this firmware.
>
> We also have the ability to decode firmware stack dumps (found in
> dmesg and/or /var/log/messages) if they come from our firmware.
> We cannot share the details of the decode nor tools to decode it,
> but we will try to fix the problems and/or describe the results of
> our decode in general terms.
>
> The firmware should work with stock 3.14 or other recent kernels,
> but we have done most testing using our own modified 3.14 kernel.
> Our kernel patches are required to support the additional stations,
> software-crypt, and other features specific to our firmware.
>
Raw Tx mode without the firmware stripping off the QoS control field
is supported?

> If you use our firmware and manage to crash it, please send to me the pertinent
> part of /var/log/messages (or dmesg), including any ath10k related ascii
> hex dumps.  Other non-crash bug reports are welcome too.
>
> Please do not bother the QCA developers with any bugs specific to our
> firmware (or our kernel patches).
>
> Links to the firmware binary, our 3.14.0+ kernel source, and related
> info is found here:
>
> http://www.candelatech.com/vsta.php
>
> Please let me know if you have any questions.
>
Thanks for your great work.

----
Chun-Yeow


From greearb at candelatech.com  Mon Apr 14 19:02:51 2014
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Apr 2014 19:02:51 -0700
Subject: Modified ath10k firmware is now available for non-commercial use.
In-Reply-To: <CAEFj986VEybhQbG4OQptLMGakTD1fOTbbz9H+-TJKPef7ehG9g@mail.gmail.com>
References: <534C38AE.3070504@candelatech.com>
 <CAEFj986VEybhQbG4OQptLMGakTD1fOTbbz9H+-TJKPef7ehG9g@mail.gmail.com>
Message-ID: <534C934B.1@candelatech.com>

On 04/14/2014 06:38 PM, Yeoh Chun-Yeow wrote:
> On Tue, Apr 15, 2014 at 3:36 AM, Ben Greear <greearb at candelatech.com> wrote:
>> Our modified ath10k firmware binary is now available for download.  It may only be used
>> for non-commercial purposes unless you get a commercial license from my company.
>>
>> The main thing this firmware supports that upstream firmware does not
>> is lots of virtual stations connected to the same AP.
> Is this firmware mainly for STA mode or AP mode or both?

It should work for both.  Most testing has been in STA mode.  It is based on
top of the .467 (AP) firmware...

>> We have some
>> additional stability fixes we found in testing, and probably have introduced
>> some bugs as well.  We will be putting ongoing effort into improving
>> this firmware.
>>
>> We also have the ability to decode firmware stack dumps (found in
>> dmesg and/or /var/log/messages) if they come from our firmware.
>> We cannot share the details of the decode nor tools to decode it,
>> but we will try to fix the problems and/or describe the results of
>> our decode in general terms.
>>
>> The firmware should work with stock 3.14 or other recent kernels,
>> but we have done most testing using our own modified 3.14 kernel.
>> Our kernel patches are required to support the additional stations,
>> software-crypt, and other features specific to our firmware.
>>
> Raw Tx mode without the firmware stripping off the QoS control field
> is supported?

No, probably not, but you can disable hwcrypt for RX pkts, at least.

Might could add the raw tx mode some day, but I've higher
priority tasks first....

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From kvalo at qca.qualcomm.com  Mon Apr 14 22:31:28 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 15 Apr 2014 08:31:28 +0300
Subject: ath.git master branch rebased to 3.15-rc1
Message-ID: <87r44zduq7.fsf@kamboji.qca.qualcomm.com>

Hi,

now that wireless-testing was rebased to 3.15-rc1 I had to also rebase
master branch of my ath.git tree. So please be careful next time you
pull from my tree.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Mon Apr 14 23:34:31 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 15 Apr 2014 09:34:31 +0300
Subject: Pull request: ath 20140415
Message-ID: <87mwfndrt4.fsf@kamboji.qca.qualcomm.com>

Hi John,

here's a pull request for ath6kl and ath10k with changes accumulated
just before and during the merge window. Please let me know if there any
problems.

Here's the list of changes:

----------------------------------------------------------------------

For ath6kl Kalle fixed a bunch of checkpatch warnings.

In ath10k we had more changes, major ones being:

* fix memory allocation failures after a firmware crash (Michal)

* some rework of DFS configuration to enable it correctly in all cases
  (Michal)

* add a new firmware crash option to make it possible to crash 10.1
  firmware for testing purposes (Marek P)

* fix RTS/CTS protection in certain cases (Marek K)

* fix wrong RSSI and rate reporting in some cases (Janusz)

* fix firmware stats reporting (Chun, Ben & Bartosz)

----------------------------------------------------------------------

The following changes since commit 70dd77b4c50da518b57b8b9b125a8c9aabe9bc1a:

  ath10k: do not overwrite max_antenna_gain (2014-03-07 10:14:10 +0200)

are available in the git repository at:

  git://github.com/kvalo/ath.git for-linville

for you to fetch changes up to 4bfee8e8c13fc9477eb9420efd5a5d12e32ac614:

  ath10k: improve htc tx credit debugging prints (2014-04-11 08:35:56 +0300)

----------------------------------------------------------------
Bartosz Markowski (1):
      ath10k: update wal_dbg_tx_stats structure with missing parameter.

Ben Greear (4):
      ath10k: better firmware loading error messages
      ath10k: add otp and firmware boot error messages
      ath10k: fix getting stats from firmware
      ath10k: add the Rx rate in FW stats

Chun-Yeow Yeoh (3):
      ath10k: allow the supported rate change by reassociate peer
      ath10k: fix the peer mac address in getting stats
      ath10k: add extra pdev stats on 10.1 firmware

Janusz Dziedzic (12):
      ath10k: add ath10k_htt_rx_amsdu_allowed function
      ath10k: Fill per-ppdu info in rx_info only once
      ath10k: move rx related functions to htt_rx.c
      ath10k: rename process_rx_rates to ath10k_htt_rx_h_rates
      ath10k: introduce ieee80211_rx_status to htt_rx_info
      ath10k: setup rx channel per ppdu
      ath10k: kill not needed fields from htt_rx_info
      ath10k: return error when ath10k_htt_rx_amsdu_pop() fail
      ath10k: improve way we play with attention flags
      ath10k: finally kill htt_rx_info
      ath10k: introduce rx_status htt template
      ath10k: fix rssi and rate reporting

Kalle Valo (18):
      ath6kl: fix struct hif_scatter_req list handling
      ath6kl: fix blank lines before and after braces
      ath6kl: use braces on both arms of if statement
      ath6kl: remove spaces before semicolon
      ath6kl: remove unnecessary line continuations
      ath6kl: update Kconfig descriptions
      ath10k: separate result parameter in ath10k_bmi_execute()
      ath10k: check otp.bin result
      ath10k: unify warning messages in mac.c
      ath10k: cleanup ath10k_pci_wait_for_target_init()
      ath10k: add module parameter to disable cold reset
      ath10k: fix name of target_ps module parameter
      ath10k: advertise only firmware API 2 files
      ath10k: delete ar_pci->fw_indicator_address
      ath10k: improve pci debug messages
      ath10k: add module parameter values to the pci info print
      ath10k: print chip id during boot
      ath10k: cleanup debug messages in ath10k_wmi_event_host_swba()

Marek Kwaczynski (1):
      ath10k: add recalc RTS/CTS protection method

Marek Puzyniak (2):
      ath10k: add soft/hard firmware crash option to simulate_fw_crash
      ath10k: update regulatory domain settings for 10.x firmware

Michal Kazior (7):
      ath10k: convert pci_alloc_consistent() to dma_alloc_coherent()
      ath10k: split ce initialization and allocation
      ath10k: deinit copy engine before resetting
      ath10k: refactor monitor code
      ath10k: reorder functions
      ath10k: refactor radar detection code
      ath10k: improve htc tx credit debugging prints

 drivers/net/wireless/ath/ath10k/bmi.c      |   13 +-
 drivers/net/wireless/ath/ath10k/bmi.h      |    2 +-
 drivers/net/wireless/ath/ath10k/ce.c       |  356 +++++++------
 drivers/net/wireless/ath/ath10k/ce.h       |   15 +-
 drivers/net/wireless/ath/ath10k/core.c     |   85 ++--
 drivers/net/wireless/ath/ath10k/core.h     |   18 +-
 drivers/net/wireless/ath/ath10k/debug.c    |  109 +++-
 drivers/net/wireless/ath/ath10k/htc.c      |   12 +-
 drivers/net/wireless/ath/ath10k/htt.h      |   21 +-
 drivers/net/wireless/ath/ath10k/htt_rx.c   |  513 ++++++++++++-------
 drivers/net/wireless/ath/ath10k/hw.h       |    1 +
 drivers/net/wireless/ath/ath10k/mac.c      |  763 +++++++++++++++-------------
 drivers/net/wireless/ath/ath10k/pci.c      |  219 +++++---
 drivers/net/wireless/ath/ath10k/pci.h      |    3 -
 drivers/net/wireless/ath/ath10k/txrx.c     |  183 -------
 drivers/net/wireless/ath/ath10k/txrx.h     |    1 -
 drivers/net/wireless/ath/ath10k/wmi.c      |   62 ++-
 drivers/net/wireless/ath/ath10k/wmi.h      |   98 +++-
 drivers/net/wireless/ath/ath6kl/Kconfig    |   30 +-
 drivers/net/wireless/ath/ath6kl/cfg80211.c |    9 +-
 drivers/net/wireless/ath/ath6kl/core.c     |    6 +-
 drivers/net/wireless/ath/ath6kl/debug.c    |    4 -
 drivers/net/wireless/ath/ath6kl/debug.h    |    2 +-
 drivers/net/wireless/ath/ath6kl/hif.c      |    3 -
 drivers/net/wireless/ath/ath6kl/hif.h      |    4 +-
 drivers/net/wireless/ath/ath6kl/htc_mbox.c |   23 +-
 drivers/net/wireless/ath/ath6kl/htc_pipe.c |   10 +-
 drivers/net/wireless/ath/ath6kl/init.c     |    1 -
 drivers/net/wireless/ath/ath6kl/main.c     |   10 +-
 drivers/net/wireless/ath/ath6kl/sdio.c     |   17 +-
 drivers/net/wireless/ath/ath6kl/target.h   |    2 +-
 drivers/net/wireless/ath/ath6kl/txrx.c     |   31 +-
 drivers/net/wireless/ath/ath6kl/usb.c      |    2 -
 drivers/net/wireless/ath/ath6kl/wmi.c      |   19 +-
 drivers/net/wireless/ath/ath6kl/wmi.h      |    1 -
 35 files changed, 1499 insertions(+), 1149 deletions(-)

-- 
Kalle Valo


From michal.kazior at tieto.com  Mon Apr 14 23:41:56 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 15 Apr 2014 08:41:56 +0200
Subject: Question on ath10k_mgmt_tx_flush
In-Reply-To: <534C028E.4000302@candelatech.com>
References: <53469F7B.2080202@candelatech.com>
 <CA+BoTQmc=n7ifUh+8Lq_1P=t4KJyDDFjcs3Z1mW1nHFO+WR2hw@mail.gmail.com>
 <5347ED46.3000406@candelatech.com>
 <CA+BoTQ=oyXd4qCOhBQE5QCu+KYaqB+_9qSdaTL_z_m2C=c=WYg@mail.gmail.com>
 <534C028E.4000302@candelatech.com>
Message-ID: <CA+BoTQ=MbQ3a6FMH-mVFhM7ToXys559AAHO_fB-u59bVdPpZKg@mail.gmail.com>

On 14 April 2014 17:45, Ben Greear <greearb at candelatech.com> wrote:
> On 04/13/2014 11:31 PM, Michal Kazior wrote:
>> On 11 April 2014 15:25, Ben Greear <greearb at candelatech.com> wrote:
>>> On 04/10/2014 10:21 PM, Michal Kazior wrote:
>>>>
>>>> On 10 April 2014 15:41, Ben Greear <greearb at candelatech.com> wrote:
>>>>>
>>>>> Can we optimize this method to return early if the tx-credits
>>>>> are fully replenished (ie, == 2) instead of just sleeping the
>>>>> 2 x beacon-interval?  That would indicate all messages
>>>>> have been flushed, right?
>>>>
>>>>
>>>> Yeah. You're _almost_ right. Every odd mgmt frame will trigger tx
>>>> credit replenishment, even if you set NEEDS_CREDITS htc tx flag for
>>>> all packets. It seems that tx credits aren't replenished until you
>>>> submit an even number of mgmt tx:
>>>>
>>>>   [tx credits =2]
>>>>   vdev create [-1, =1]
>>>>   [replenish +1, =2]
>>>>   mgmt tx [-1, =1]
>>>>   [frame is seen on air, means it left tx queue, but no replenishment]
>>>>   vdev set param [-1, =0]
>>>>   [replenish +1, =1]
>>>>   mgmt tx [-1, =0]
>>>>   [frame seen on air]
>>>>   [replenish +2, =2]
>>>>
>>>> However once you flush peer tids you get the tx credit immediately.
>>>> This means you don't ever reach having 2 mgmt tx consuming 2 tx
>>>> credits (unless things go terribly terribly wrong at which point it's
>>>> probably already beyond help).
>>>>
>>>> A very ugly hack would be to try and send out mgmt tx in pairs - a
>>>> requested frame and a dummy frame (such that firmware will not buffer
>>>> it) so that you use tx credit replenishment as tx completion
>>>> indication.
>>>
>>>
>>> If you ignore how firmware replenishes the tx-credits for now,
>>> is it safe to assume that if you have 2 tx-credits while in
>>> the flush routine, then everything is indeed flushed and
>>> we can skip the sleep?
>>
>> You want to always skip the sleep between mgmt tx and flush commands?
>> I'm afraid this won't work because tx flush command can end up with
>> queued frame being dropped or transmitted regardless of destination
>> station powersave state if submitted too soon.
>
> I just want to know if I can skip the sleep if we currently have 2 tx-credits.

No, not really. At least not in any sane way I can think of.

Problem 1:
If you submit a frame that gets stuck for 10 seconds and you don't
flush it (and you have no idea when it is safe to flush other than
timing this with arbitrary numbers like beacon intervals) and you try
to queue another frame that gets stuck you end up with 0 tx credits.

Problem 2:
If you submit a frame and immediately call tx flush you can end up not
sending out the frame at all or ignoring client power save state I'm
afraid.

I was thinking of a more clever hack that would involve sending dummy
frames (i.e. spurious probe responses) to tickle firmware and force it
replenish tx credit after sending the actual requested mgmt frame.
This is ugly, intrusive, wrong and I'm not even sure if this can even
work.


> From your answer below, that seems to be a yes.  So, 1/2 of the time (on avg)
> is worth the hack to me, and if/when I fix the firmware (and/or if QCA fixes
> the firmware), then we should have 2 tx-credits more often and only sleep when
> there really is work to do.

The problem is you don't have a way of knowing if mgmt tx is stuck or
not both because there is no tx completion and tx credits aren't
replenished in a sane way. If any of those were ok, we could have a
wait_for_completion() instead of a msleep() and thus cut down wait
times for frames that don't get stuck.


>>> I imagine both I and the QCA firmware guys can make the
>>> firmware properly replenish tx-credits one at a time instead
>>> of the only-on-even/odd behaviour you found.
>>
>> That would be nice.
>>
>>
>>> But even without that, we might be able to speed up the
>>> flush 1/2 of the time?
>>
>> Yes, although I'm not very fond of the idea of applying a hack on top
>> of another hack.
>
> What is your preferred fix for this?

Fix the firmware, obviously.

999.999.0.636 uses htt for mgmt tx so the problem doesn't exist there.
That's solely a 10.1 branch issue and I doubt this will be ever fixed
in this branch...


Micha?


From vh.nguyen at actiasodielec.fr  Tue Apr 15 01:20:45 2014
From: vh.nguyen at actiasodielec.fr (Vu Hai NGUYEN)
Date: Tue, 15 Apr 2014 10:20:45 +0200
Subject: Report Firmware  firmware-2.bin_10.1.467.2-1 Error
In-Reply-To: <EE97821C81277E459BEA5C6384C6F241012F06CC4838@srvexch01.SODIELEC.local>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
 <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>,
 <8738hgfi1k.fsf@kamboji.qca.qualcomm.com>,
 <EE97821C81277E459BEA5C6384C6F241012F06CC4838@srvexch01.SODIELEC.local>
Message-ID: <EE97821C81277E459BEA5C6384C6F241012F06CC4839@srvexch01.SODIELEC.local>

Hi guys,
When I load the firmware-2.bin_10.1.467.2-1 I got this error when I put my device in mode ACCESS POINT:
"PCI express error: irq - 228, Pex number: 0, Interrupt Cause Register value: 10"
But if I use the version 999.999.0.x. I don't have this error.
So I just report it here, I don't know what kind of other information do you guys need to know what may cause that error.
Please feel free to ask me to provide other information
Sincerely,

NGUYEN Vu Hai
Acita-Sodielec
Route de Mayres - B.P. 9
12100 St GEORGES DE LUZENCON
FRANCE


From kvalo at qca.qualcomm.com  Tue Apr 15 04:02:30 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 15 Apr 2014 14:02:30 +0300
Subject: Report Firmware  firmware-2.bin_10.1.467.2-1 Error
In-Reply-To: <EE97821C81277E459BEA5C6384C6F241012F06CC4839@srvexch01.SODIELEC.local>
 (Vu Hai NGUYEN's message of "Tue, 15 Apr 2014 10:20:45 +0200")
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
 <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>
 <8738hgfi1k.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4838@srvexch01.SODIELEC.local>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4839@srvexch01.SODIELEC.local>
Message-ID: <87eh0yetyx.fsf@kamboji.qca.qualcomm.com>

Vu Hai NGUYEN <vh.nguyen at actiasodielec.fr> writes:

> When I load the firmware-2.bin_10.1.467.2-1 I got this error when I
> put my device in mode ACCESS POINT: "PCI express error: irq - 228, Pex
> number: 0, Interrupt Cause Register value: 10" But if I use the
> version 999.999.0.x. I don't have this error.

I wonder if this has something to do with cold reset causing PCI bus
errors? But we need more information to say more. Can you send the full
dmesg output (from the beginning of kernel boot) along with detailed
descriptions of your host platform and what kind qca98xx board you have.

Even better is if you can also send a debug log output using debug mask
value 0x432. More info:

http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Useful_debug_masks

-- 
Kalle Valo


From yeohchunyeow at gmail.com  Wed Apr 16 03:01:49 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Wed, 16 Apr 2014 18:01:49 +0800
Subject: Firmware 636 crashed with 4addr
Message-ID: <CAEFj987O5CJtdO37FZOsYDgja9YrCEt-Uxka2FYHAx86WPbwbQ@mail.gmail.com>

Hi, all

Anyone knows the reason of the following firmware crashed whenever the
managed interface is set with 4addr on and bridged to a bridge
interface.

ifconfig br-lan up
iw wlan0 set 4addr on
brctl addif br-lan wlan0
[   78.130000] device wlan0 entered promiscuous mode
[   78.130000] br-lan: port 1(wlan0) entered forwarding state
[   78.140000] br-lan: port 1(wlan0) entered forwarding state
[   79.140000] ath10k: firmware crashed!
[   79.150000] ath10k: hardware name qca988x hw2.0 version 0x4100016c
[   79.150000] ath10k: firmware version: 999.999.0.636
[   79.160000] ath10k: target register Dump Location: 0x0040AC14
[   79.170000] ath10k: target Register Dump
[   79.170000] ath10k: [00]: 0x4100016C 0x00000000 0x009C4521 0x00000000
[   79.180000] ath10k: [04]: 0x009C4521 0x00060530 0x00000019 0x00955A00
[   79.180000] ath10k: [08]: 0x00014855 0x00000000 0x0040CC94 0x00000020
[   79.190000] ath10k: [12]: 0x00000000 0x00000000 0x00958360 0x0095836B
[   79.200000] ath10k: [16]: 0x80991091 0x0040AD94 0x0042EADC 0x00000000
[   79.200000] ath10k: [20]: 0x0000FFFF 0x00000000 0x00000045 0x004340C0
[   79.210000] ath10k: [24]: 0x809A0978 0x0040AD94 0x00439304 0x052157C7
[   79.220000] ath10k: [28]: 0x809AD1A2 0x0040ADE4 0x00439304 0x0043F8BC
[   79.220000] ath10k: [32]: 0x00000001 0x00000018 0x00000000 0x0042F664
[   79.230000] ath10k: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
[   79.230000] ath10k: [40]: 0x00000000 0x00000000 0x00000045 0x00412700
[   79.240000] ath10k: [44]: 0x00439C00 0x00000000 0x00000000 0x00400000
[   79.250000] ath10k: [48]: 0x809AE0B4 0x0040AE04 0x00400000 0x0043F8BC
[   79.250000] ath10k: [52]: 0x00000001 0x00000000 0x004231F0 0x00400000
[   79.260000] ath10k: [56]: 0x809AE17E 0x0040AE44 0x0040FE6C 0x0040D310
[   82.270000] ath10k: failed to to request monitor vdev 1 stop: -11
[   87.270000] ath10k: failed to synchronise monitor vdev 1: -145
[   87.270000] ath10k: failed to stop monitor vdev: -145
[   90.280000] ath10k: failed to request wmi monitor vdev 1 removal: -11
[   90.280000] ath10k: failed to delete monitor vdev: -11

Further investigation shows that this is not happening to firmware
10.1.467.2-1.

----
Chun-Yeow


From michal.kazior at tieto.com  Wed Apr 16 03:16:44 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 16 Apr 2014 12:16:44 +0200
Subject: Firmware 636 crashed with 4addr
In-Reply-To: <CAEFj987O5CJtdO37FZOsYDgja9YrCEt-Uxka2FYHAx86WPbwbQ@mail.gmail.com>
References: <CAEFj987O5CJtdO37FZOsYDgja9YrCEt-Uxka2FYHAx86WPbwbQ@mail.gmail.com>
Message-ID: <CA+BoTQ=ihvm8-bWyyt6vFr2QqfqRONtbSrALGr6WGcLNYGRukg@mail.gmail.com>

On 16 April 2014 12:01, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
> Hi, all
>
> Anyone knows the reason of the following firmware crashed whenever the
> managed interface is set with 4addr on and bridged to a bridge
> interface.
>
> ifconfig br-lan up
> iw wlan0 set 4addr on
> brctl addif br-lan wlan0
> [   78.130000] device wlan0 entered promiscuous mode
> [   78.130000] br-lan: port 1(wlan0) entered forwarding state
> [   78.140000] br-lan: port 1(wlan0) entered forwarding state
> [   79.140000] ath10k: firmware crashed!
> [   79.150000] ath10k: hardware name qca988x hw2.0 version 0x4100016c
> [   79.150000] ath10k: firmware version: 999.999.0.636
> [   79.160000] ath10k: target register Dump Location: 0x0040AC14
> [   79.170000] ath10k: target Register Dump
> [   79.170000] ath10k: [00]: 0x4100016C 0x00000000 0x009C4521 0x00000000
> [   79.180000] ath10k: [04]: 0x009C4521 0x00060530 0x00000019 0x00955A00
> [   79.180000] ath10k: [08]: 0x00014855 0x00000000 0x0040CC94 0x00000020
> [   79.190000] ath10k: [12]: 0x00000000 0x00000000 0x00958360 0x0095836B
> [   79.200000] ath10k: [16]: 0x80991091 0x0040AD94 0x0042EADC 0x00000000
> [   79.200000] ath10k: [20]: 0x0000FFFF 0x00000000 0x00000045 0x004340C0
> [   79.210000] ath10k: [24]: 0x809A0978 0x0040AD94 0x00439304 0x052157C7
> [   79.220000] ath10k: [28]: 0x809AD1A2 0x0040ADE4 0x00439304 0x0043F8BC
> [   79.220000] ath10k: [32]: 0x00000001 0x00000018 0x00000000 0x0042F664
> [   79.230000] ath10k: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
> [   79.230000] ath10k: [40]: 0x00000000 0x00000000 0x00000045 0x00412700
> [   79.240000] ath10k: [44]: 0x00439C00 0x00000000 0x00000000 0x00400000
> [   79.250000] ath10k: [48]: 0x809AE0B4 0x0040AE04 0x00400000 0x0043F8BC
> [   79.250000] ath10k: [52]: 0x00000001 0x00000000 0x004231F0 0x00400000
> [   79.260000] ath10k: [56]: 0x809AE17E 0x0040AE44 0x0040FE6C 0x0040D310
> [   82.270000] ath10k: failed to to request monitor vdev 1 stop: -11
> [   87.270000] ath10k: failed to synchronise monitor vdev 1: -145
> [   87.270000] ath10k: failed to stop monitor vdev: -145
> [   90.280000] ath10k: failed to request wmi monitor vdev 1 removal: -11
> [   90.280000] ath10k: failed to delete monitor vdev: -11
>
> Further investigation shows that this is not happening to firmware
> 10.1.467.2-1.

I'm suspecting this is because of monitor vdev.

Firmware 999.999.0.636 is incapable of running monitor vdev alone,
i.e. it has to be paired with another non-monitor vdev.

Please try to first connect the interface *before* adding it to the
bridge. I'm guessing this should work. Be aware, that if you then
disconnect from AP without first removing the interface from the
bridge you'll most likely crash the firmware too.


Micha?


From yeohchunyeow at gmail.com  Wed Apr 16 03:25:39 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Wed, 16 Apr 2014 18:25:39 +0800
Subject: Firmware 636 crashed with 4addr
In-Reply-To: <CA+BoTQ=ihvm8-bWyyt6vFr2QqfqRONtbSrALGr6WGcLNYGRukg@mail.gmail.com>
References: <CAEFj987O5CJtdO37FZOsYDgja9YrCEt-Uxka2FYHAx86WPbwbQ@mail.gmail.com>
 <CA+BoTQ=ihvm8-bWyyt6vFr2QqfqRONtbSrALGr6WGcLNYGRukg@mail.gmail.com>
Message-ID: <CAEFj984A6LF0XG593RU+r3VrmnMgk1iONkvJr+=rSAv8w8o6Gg@mail.gmail.com>

Hi, Michal

> Please try to first connect the interface *before* adding it to the
> bridge. I'm guessing this should work.

Do you mean that connect to AP first? Actually, I connect to the AP
first before bridging.

---
Chun-Yeow


From michal.kazior at tieto.com  Wed Apr 16 03:31:11 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 16 Apr 2014 12:31:11 +0200
Subject: Firmware 636 crashed with 4addr
In-Reply-To: <CAEFj984A6LF0XG593RU+r3VrmnMgk1iONkvJr+=rSAv8w8o6Gg@mail.gmail.com>
References: <CAEFj987O5CJtdO37FZOsYDgja9YrCEt-Uxka2FYHAx86WPbwbQ@mail.gmail.com>
 <CA+BoTQ=ihvm8-bWyyt6vFr2QqfqRONtbSrALGr6WGcLNYGRukg@mail.gmail.com>
 <CAEFj984A6LF0XG593RU+r3VrmnMgk1iONkvJr+=rSAv8w8o6Gg@mail.gmail.com>
Message-ID: <CA+BoTQ==WHLUkY622_PJKXmGDU5cbiHa4shNhDycfP5DkJCLeg@mail.gmail.com>

On 16 April 2014 12:25, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
> Hi, Michal
>
>> Please try to first connect the interface *before* adding it to the
>> bridge. I'm guessing this should work.
>
> Do you mean that connect to AP first? Actually, I connect to the AP
> first before bridging.

Hmm... Are you able to reproduce this with (more) logs or traces?


Micha?


From yeohchunyeow at gmail.com  Wed Apr 16 03:40:20 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Wed, 16 Apr 2014 18:40:20 +0800
Subject: Firmware 636 crashed with 4addr
In-Reply-To: <CA+BoTQ==WHLUkY622_PJKXmGDU5cbiHa4shNhDycfP5DkJCLeg@mail.gmail.com>
References: <CAEFj987O5CJtdO37FZOsYDgja9YrCEt-Uxka2FYHAx86WPbwbQ@mail.gmail.com>
 <CA+BoTQ=ihvm8-bWyyt6vFr2QqfqRONtbSrALGr6WGcLNYGRukg@mail.gmail.com>
 <CAEFj984A6LF0XG593RU+r3VrmnMgk1iONkvJr+=rSAv8w8o6Gg@mail.gmail.com>
 <CA+BoTQ==WHLUkY622_PJKXmGDU5cbiHa4shNhDycfP5DkJCLeg@mail.gmail.com>
Message-ID: <CAEFj9876W=i4rfO2rJ+f5+_0ffojmS9KX5XtzuZ+PyumVAPYZA@mail.gmail.com>

Sure, any specific logs or traces that you want?

Will do it later.

---
Chun-Yeow

On Wed, Apr 16, 2014 at 6:31 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 16 April 2014 12:25, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
>> Hi, Michal
>>
>>> Please try to first connect the interface *before* adding it to the
>>> bridge. I'm guessing this should work.
>>
>> Do you mean that connect to AP first? Actually, I connect to the AP
>> first before bridging.
>
> Hmm... Are you able to reproduce this with (more) logs or traces?
>
>
> Micha?


From michal.kazior at tieto.com  Wed Apr 16 03:43:27 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 16 Apr 2014 12:43:27 +0200
Subject: Firmware 636 crashed with 4addr
In-Reply-To: <CAEFj9876W=i4rfO2rJ+f5+_0ffojmS9KX5XtzuZ+PyumVAPYZA@mail.gmail.com>
References: <CAEFj987O5CJtdO37FZOsYDgja9YrCEt-Uxka2FYHAx86WPbwbQ@mail.gmail.com>
 <CA+BoTQ=ihvm8-bWyyt6vFr2QqfqRONtbSrALGr6WGcLNYGRukg@mail.gmail.com>
 <CAEFj984A6LF0XG593RU+r3VrmnMgk1iONkvJr+=rSAv8w8o6Gg@mail.gmail.com>
 <CA+BoTQ==WHLUkY622_PJKXmGDU5cbiHa4shNhDycfP5DkJCLeg@mail.gmail.com>
 <CAEFj9876W=i4rfO2rJ+f5+_0ffojmS9KX5XtzuZ+PyumVAPYZA@mail.gmail.com>
Message-ID: <CA+BoTQn_cvXXRp52SF3=AFC1Hmx_+yoX=m4sv8XMrJreL9n=sA@mail.gmail.com>

On 16 April 2014 12:40, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
> Sure, any specific logs or traces that you want?

I think hexdumps aren't necessary. debug_mask=0xffffff3f should suffice.


> Will do it later.

Okay :-)


Micha?


From vh.nguyen at actiasodielec.fr  Wed Apr 16 04:51:04 2014
From: vh.nguyen at actiasodielec.fr (Vu Hai NGUYEN)
Date: Wed, 16 Apr 2014 13:51:04 +0200
Subject: Report Firmware  firmware-2.bin_10.1.467.2-1 Error
In-Reply-To: <87eh0yetyx.fsf@kamboji.qca.qualcomm.com>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
 <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>
 <8738hgfi1k.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4838@srvexch01.SODIELEC.local>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4839@srvexch01.SODIELEC.local>,
 <87eh0yetyx.fsf@kamboji.qca.qualcomm.com>
Message-ID: <EE97821C81277E459BEA5C6384C6F241012F06CC483A@srvexch01.SODIELEC.local>

Thank you for your response,
I didn't power down my cible to reboot, I just upload new program with new firmware and run it. The problem is when that error appear my console keep print it and I Have no longer access to my system, I can not type another command (dmesg) , then I have to reset my platform. I'll try to get the dmesg and sent you later.
My host platform is using processor Marvell Armada 370 and my module of wifi is Compex WLE900VX.
There's another problem: when I used the firmware version 999.999 some times when I ran my program and change the parameter of configuration, the firmware crash and I got a output dmesg which indicate a strange version of firmware (1.0.0.636 ???) : 

ath10k: firmware crashed!                                                       
ath10k: hardware name qca988x hw2.0 version 0x4100016c                          
ath10k: firmware version: 1.0.0.636 
ath10k: target register Dump Location: 0x00401930                               
ath10k: target Register Dump                                                    
ath10k: [00]: 0x4100016C 0x00000000 0x0098E3A9 0x00000000                       
ath10k: [04]: 0x00000000 0x00000000 0x00000000 0x00000000                       
ath10k: [08]: 0x00000000 0x00000000 0x00000000 0x00000000                       
ath10k: [12]: 0x00000000 0x00000000 0x00000000 0x00000000                       
ath10k: [16]: 0x00000000 0x00000000 0x00000000 0x0098E3A9                       
ath10k: [20]: 0x00000000 0x00401930 0x00000000 0x00000000                       
ath10k: [24]: 0x00000000 0x00000000 0x00000000 0x00000000                       
ath10k: [28]: 0x00000000 0x00000000 0x00000000 0x00000000                       
ath10k: [32]: 0x00000000 0x00000000 0x00000000 0x00000000                       
ath10k: [36]: 0x00000000 0x00000000 0x00000000 0x00000000                       
ath10k: [40]: 0x00000000 0x00000000 0x00000000 0x00000000                       
ath10k: [44]: 0x00000000 0x00000000 0x00000000 0x00000000                       
ath10k: [48]: 0x00000000 0x00000000 0x00000000 0x00000000                       
ath10k: [52]: 0x00000000 0x00000000 0x00000000 0x00000000                       
ath10k: [56]: 0x00000000 0x00000000 0x00000000 0x00000000    

and then It reload the firmware 999.999.  :

ath10k: firmware 999.999.0.636 booted

You can see the output of my dmesg 


NGUYEN Vu Hai
Acita-Sodielec
Route de Mayres - B.P. 9
12100 St GEORGES DE LUZENCON
FRANCE

________________________________________
De : Kalle Valo [kvalo at qca.qualcomm.com]
Date d'envoi : mardi 15 avril 2014 13:02
? : Vu Hai NGUYEN
Cc : ath10k at lists.infradead.org; Patrick CARNEIRO RODRIGUEZ
Objet : Re: Report Firmware  firmware-2.bin_10.1.467.2-1 Error

Vu Hai NGUYEN <vh.nguyen at actiasodielec.fr> writes:

> When I load the firmware-2.bin_10.1.467.2-1 I got this error when I
> put my device in mode ACCESS POINT: "PCI express error: irq - 228, Pex
> number: 0, Interrupt Cause Register value: 10" But if I use the
> version 999.999.0.x. I don't have this error.

I wonder if this has something to do with cold reset causing PCI bus
errors? But we need more information to say more. Can you send the full
dmesg output (from the beginning of kernel boot) along with detailed
descriptions of your host platform and what kind qca98xx board you have.

Even better is if you can also send a debug log output using debug mask
value 0x432. More info:

http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Useful_debug_masks

--
Kalle Valo


From vh.nguyen at actiasodielec.fr  Wed Apr 16 04:51:29 2014
From: vh.nguyen at actiasodielec.fr (Vu Hai NGUYEN)
Date: Wed, 16 Apr 2014 13:51:29 +0200
Subject: Report Firmware  firmware-2.bin_10.1.467.2-1 Error
In-Reply-To: <EE97821C81277E459BEA5C6384C6F241012F06CC483A@srvexch01.SODIELEC.local>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
 <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>
 <8738hgfi1k.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4838@srvexch01.SODIELEC.local>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4839@srvexch01.SODIELEC.local>,
 <87eh0yetyx.fsf@kamboji.qca.qualcomm.com>,
 <EE97821C81277E459BEA5C6384C6F241012F06CC483A@srvexch01.SODIELEC.local>
Message-ID: <EE97821C81277E459BEA5C6384C6F241012F06CC483B@srvexch01.SODIELEC.local>

I forgot to join the dmesg output, you can see detail in the attached file
Sincerely,

NGUYEN Vu Hai
Acita-Sodielec
Route de Mayres - B.P. 9
12100 St GEORGES DE LUZENCON
FRANCE

________________________________________
De : Vu Hai NGUYEN
Date d'envoi : mercredi 16 avril 2014 13:51
? : ath10k at lists.infradead.org
Cc : Patrick CARNEIRO RODRIGUEZ
Objet : RE : Report Firmware  firmware-2.bin_10.1.467.2-1 Error

Thank you for your response,
I didn't power down my cible to reboot, I just upload new program with new firmware and run it. The problem is when that error appear my console keep print it and I Have no longer access to my system, I can not type another command (dmesg) , then I have to reset my platform. I'll try to get the dmesg and sent you later.
My host platform is using processor Marvell Armada 370 and my module of wifi is Compex WLE900VX.
There's another problem: when I used the firmware version 999.999 some times when I ran my program and change the parameter of configuration, the firmware crash and I got a output dmesg which indicate a strange version of firmware (1.0.0.636 ???) :

ath10k: firmware crashed!
ath10k: hardware name qca988x hw2.0 version 0x4100016c
ath10k: firmware version: 1.0.0.636
ath10k: target register Dump Location: 0x00401930
ath10k: target Register Dump
ath10k: [00]: 0x4100016C 0x00000000 0x0098E3A9 0x00000000
ath10k: [04]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k: [08]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k: [12]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k: [16]: 0x00000000 0x00000000 0x00000000 0x0098E3A9
ath10k: [20]: 0x00000000 0x00401930 0x00000000 0x00000000
ath10k: [24]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k: [28]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k: [32]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k: [40]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k: [44]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k: [48]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k: [52]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k: [56]: 0x00000000 0x00000000 0x00000000 0x00000000

and then It reload the firmware 999.999.  :

ath10k: firmware 999.999.0.636 booted

You can see the output of my dmesg


NGUYEN Vu Hai
Acita-Sodielec
Route de Mayres - B.P. 9
12100 St GEORGES DE LUZENCON
FRANCE

________________________________________
De : Kalle Valo [kvalo at qca.qualcomm.com]
Date d'envoi : mardi 15 avril 2014 13:02
? : Vu Hai NGUYEN
Cc : ath10k at lists.infradead.org; Patrick CARNEIRO RODRIGUEZ
Objet : Re: Report Firmware  firmware-2.bin_10.1.467.2-1 Error

Vu Hai NGUYEN <vh.nguyen at actiasodielec.fr> writes:

> When I load the firmware-2.bin_10.1.467.2-1 I got this error when I
> put my device in mode ACCESS POINT: "PCI express error: irq - 228, Pex
> number: 0, Interrupt Cause Register value: 10" But if I use the
> version 999.999.0.x. I don't have this error.

I wonder if this has something to do with cold reset causing PCI bus
errors? But we need more information to say more. Can you send the full
dmesg output (from the beginning of kernel boot) along with detailed
descriptions of your host platform and what kind qca98xx board you have.

Even better is if you can also send a debug log output using debug mask
value 0x432. More info:

http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Useful_debug_masks

--
Kalle Valo
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmesg.txt
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20140416/27fcfb0b/attachment-0001.txt>

From greearb at candelatech.com  Wed Apr 16 09:58:07 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 16 Apr 2014 09:58:07 -0700
Subject: Locking the htt_tx_detach path?
Message-ID: <534EB69F.9040307@candelatech.com>

I have a patch in my tree that attempts to reset firmware when
the firmware fails to return tx credits after too much time.

The trace below is a crash that happened when this logic
kicked in.  Could easily just be my bug, of course, but when
looking at the related code I, I am suspicious that we should
grab the tx-lock in the detach method and check
that we are stopped before trying to transmit?

Maybe like this un-tested patch?

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 22a4542..ba733e2 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -144,9 +144,14 @@ static void ath10k_htt_tx_cleanup_pending(struct ath10k_htt *htt)
 void ath10k_htt_tx_detach(struct ath10k_htt *htt)
 {
        ath10k_htt_tx_cleanup_pending(htt);
+
+       spin_lock_bh(&htt->tx_lock);
        kfree(htt->pending_tx);
        kfree(htt->used_msdu_ids);
        dma_pool_destroy(htt->tx_pool);
+       htt->tx_pool = NULL;
+       spin_unlock_bh(&htt->tx_lock);
+
        return;
 }

@@ -403,6 +408,13 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
                goto err;

        spin_lock_bh(&htt->tx_lock);
+
+       /* Check if we are detached... */
+       if (! htt->tx_pool) {
+               spin_unlock_bh(&htt->tx_lock);
+               goto err_tx_dec;
+       }
+
        res = ath10k_htt_tx_alloc_msdu_id(htt);
        if (res < 0) {
                spin_unlock_bh(&htt->tx_lock);




The crash below appears to be because the htt->tx_pool is NULL
in this code from htt_tx.c: (ath10k_htt_tx)

	/* Since HTT 3.0 there is no separate mgmt tx command. However in case
	 * of mgmt tx using TX_FRM there is not tx fragment list. Instead of tx
	 * fragment list host driver specifies directly frame pointer. */
	use_frags = htt->target_version_major < 3 ||
		    !ieee80211_is_mgmt(hdr->frame_control);

	skb_cb->htt.txbuf = dma_pool_alloc(htt->tx_pool, GFP_ATOMIC,
					   &paddr);


ath10k: failed with wmi_cmd_timeout 2 times, attempting hardware reset.
wlan0: Failed to send nullfunc to AP 00:c3:09:bf:a9:bb after 1000ms, disconnecting
sta2: Failed to send nullfunc to AP 00:c3:09:bf:a9:bb after 1000ms, disconnecting
sta3: Failed to send nullfunc to AP 00:c3:09:bf:a9:bb after 1000ms, disconnecting
sta4: Failed to send nullfunc to AP 00:c3:09:bf:a9:bb after 1000ms, disconnecting
sta5: Failed to send nullfunc to AP 00:c3:09:bf:a9:bb after 1000ms, disconnecting
sta6: Failed to send nullfunc to AP 00:c3:09:bf:a9:bb after 1000ms, disconnecting
ath10k: failed with wmi_cmd_timeout 2 times, attempting hardware reset.
BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff8116a1e1>] dma_pool_alloc+0x1a5/0x1dd
PGD c7f4f067 PUD c785e067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: nf_nat_ipv4 nf_nat 8021q garp stp mrp llc fuse macvlan wanlink(O) pktgen ip6table_filter ip6_tables ebtable_nat ebtables f71882fg coretemp
hwmon iTCO_wdt iTCO_vendor_support intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm snd_hda_codec_hdmi snd_hda_codec_realtek microcode
snd_hda_codec_generic joydev pcspkr serio_raw snd_hda_intel i2c_i801 lpc_ich snd_hda_codec ath10k_pci snd_hwdep ath10k_core ath snd_seq snd_seq_device mac80211
snd_pcm cfg80211 e1000e snd_timer snd ptp soundcore pps_core shpchp uinput ipv6 i915 i2c_algo_bit drm_kms_helper ata_generic pata_acpi drm i2c_core video [last
unloaded: iptable_nat]
CPU: 0 PID: 6019 Comm: dhclient Tainted: G        WC O 3.14.0+ #6
Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 03/19/2013
task: ffff8800cbd4b100 ti: ffff8800c6a92000 task.ti: ffff8800c6a92000
RIP: 0010:[<ffffffff8116a1e1>]  [<ffffffff8116a1e1>] dma_pool_alloc+0x1a5/0x1dd
RSP: 0018:ffff8800c6a93758  EFLAGS: 00010003
ath10k: core-restart, going to state RESTARTING from ON
ieee80211 wiphy0: Hardware restart was requested
ath10k: failed to start hw scan: -70
ath10k: failed to set wmm params: -70
ath10k: failed to set wmm params: -70
ath10k: failed to set wmm params: -70
ath10k: failed to set wmm params: -70
RAX: 0000000000000292 RBX: ffff8800c906a130 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000292 RDI: ffff8802095b0790
RBP: ffff8800c6a93798 R08: 0000000000000032 R09: ffff8800c6a93798
R10: 63390e21f004bba9 R11: bf09c30000000188 R12: ffff8802095b0780
R13: ffff8802095b0580 R14: ffff8802095b0790 R15: 0000000000000020
FS:  00007f296b976740(0000) GS:ffff88021f200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000cc883000 CR4: 00000000001407f0
Stack:
 0000000000000000 ffff8800c6a93860 0040ffffffffff10 ffff8800c906a130
 ffff8800c906a100 ffff8802146c6758 0000000000000000 ffff880215447098
 ffff8800c6a93898 ffffffffa03883be 0000000000000000 0000000200000000
Call Trace:
 [<ffffffffa03883be>] ath10k_htt_tx+0x102/0x3f3 [ath10k_core]
 [<ffffffff8100a877>] ? __switch_to+0x255/0x41c
 [<ffffffff810d0ee7>] ? finish_task_switch+0x4d/0xd9
 [<ffffffffa037f09f>] ath10k_tx_htt+0xa4/0xcc [ath10k_core]
 [<ffffffffa037f3bb>] ath10k_tx+0x2f4/0x303 [ath10k_core]
 [<ffffffffa0303412>] __ieee80211_tx+0x2d8/0x359 [mac80211]
 [<ffffffffa0300f60>] ? ieee80211_tx_prepare+0xe0/0x339 [mac80211]
 [<ffffffff810d6170>] ? update_entity_load_avg+0x1e3/0x27f
 [<ffffffffa0303545>] ieee80211_tx+0xb2/0xc5 [mac80211]
 [<ffffffffa03039e5>] ieee80211_xmit+0x137/0x143 [mac80211]
 [<ffffffff81506895>] ? __alloc_skb+0x8d/0x19c
 [<ffffffffa03045ec>] ieee80211_subif_start_xmit+0xb8a/0xbb2 [mac80211]
 [<ffffffff81512991>] ? dev_queue_xmit_nit+0x195/0x1a4
 [<ffffffff81512e16>] dev_hard_start_xmit+0x320/0x41e
 [<ffffffff8152b232>] sch_direct_xmit+0x70/0x14f
 [<ffffffff81513152>] __dev_queue_xmit+0x23e/0x472
 [<ffffffff815133af>] dev_queue_xmit+0xd/0xf
 [<ffffffff815aa46e>] packet_sendmsg+0xc05/0xc6f
 [<ffffffff814fc242>] ? __sock_sendmsg+0x59/0x64
 [<ffffffff814fc242>] __sock_sendmsg+0x59/0x64
 [<ffffffff814fc9bf>] sock_aio_write+0xa7/0xab
 [<ffffffff81185532>] do_sync_write+0x59/0x79
 [<ffffffff811858f6>] ? rw_verify_area+0xa8/0xcb
 [<ffffffff81186814>] vfs_write+0xc3/0x120
 [<ffffffff81186949>] SyS_write+0x54/0x81
 [<ffffffff815c52f9>] system_call_fastpath+0x16/0x1b
Code: 48 89 13 4c 89 63 08 49 89 1c 24 eb 0c 48 89 df e8 5f e9 00 00 31 d2 eb 38 41 8b 4d 24 49 8b 55 10 48 89 c6 41 ff 45 20 4c 89 f7 <8b> 14 0a 41 89 55 24 48
89 ca 49 03 4d 18 49 03 55 10 48 8b 5d
RIP  [<ffffffff8116a1e1>] dma_pool_alloc+0x1a5/0x1dd
 RSP <ffff8800c6a93758>
CR2: 0000000000000000
---[ end trace fdbfb3d787b878e5 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
drm_kms_helper: panic occurred, switching back to text console
Rebooting in 10 seconds..


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Wed Apr 16 17:42:37 2014
From: greearb at candelatech.com (greearb at candelatech.com)
Date: Wed, 16 Apr 2014 17:42:37 -0700
Subject: [PATCH] ath10k:  Hold tx-lock while detaching htt.
Message-ID: <1397695357-14028-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb at candelatech.com>

And check for null pool in the tx path (which would
indicate we are detaching).

Signed-off-by: Ben Greear <greearb at candelatech.com>
---
 drivers/net/wireless/ath/ath10k/htt_tx.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 22a4542..0698d6f 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -143,10 +143,19 @@ static void ath10k_htt_tx_cleanup_pending(struct ath10k_htt *htt)
 
 void ath10k_htt_tx_detach(struct ath10k_htt *htt)
 {
+	struct dma_pool *tx_pool_tmp;
+
 	ath10k_htt_tx_cleanup_pending(htt);
+
+	spin_lock_bh(&htt->tx_lock);
 	kfree(htt->pending_tx);
 	kfree(htt->used_msdu_ids);
-	dma_pool_destroy(htt->tx_pool);
+	tx_pool_tmp = htt->tx_pool;
+	htt->tx_pool = NULL;
+	spin_unlock_bh(&htt->tx_lock);
+
+	dma_pool_destroy(tx_pool_tmp);
+
 	return;
 }
 
@@ -403,6 +412,13 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
 		goto err;
 
 	spin_lock_bh(&htt->tx_lock);
+
+	/* Check if we are detached... */
+	if (! htt->tx_pool) {
+		spin_unlock_bh(&htt->tx_lock);
+		goto err_tx_dec;
+	}
+
 	res = ath10k_htt_tx_alloc_msdu_id(htt);
 	if (res < 0) {
 		spin_unlock_bh(&htt->tx_lock);
-- 
1.7.11.7



From greearb at candelatech.com  Wed Apr 16 18:03:17 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 16 Apr 2014 18:03:17 -0700
Subject: Question on ath10k_mgmt_tx_flush
In-Reply-To: <CA+BoTQ=MbQ3a6FMH-mVFhM7ToXys559AAHO_fB-u59bVdPpZKg@mail.gmail.com>
References: <53469F7B.2080202@candelatech.com>
 <CA+BoTQmc=n7ifUh+8Lq_1P=t4KJyDDFjcs3Z1mW1nHFO+WR2hw@mail.gmail.com>
 <5347ED46.3000406@candelatech.com>
 <CA+BoTQ=oyXd4qCOhBQE5QCu+KYaqB+_9qSdaTL_z_m2C=c=WYg@mail.gmail.com>
 <534C028E.4000302@candelatech.com>
 <CA+BoTQ=MbQ3a6FMH-mVFhM7ToXys559AAHO_fB-u59bVdPpZKg@mail.gmail.com>
Message-ID: <534F2855.2030305@candelatech.com>

On 04/14/2014 11:41 PM, Michal Kazior wrote:
> On 14 April 2014 17:45, Ben Greear <greearb at candelatech.com> wrote:
>> On 04/13/2014 11:31 PM, Michal Kazior wrote:
>>> On 11 April 2014 15:25, Ben Greear <greearb at candelatech.com> wrote:
>>>> On 04/10/2014 10:21 PM, Michal Kazior wrote:
>>>>>
>>>>> On 10 April 2014 15:41, Ben Greear <greearb at candelatech.com> wrote:
>>>>>>
>>>>>> Can we optimize this method to return early if the tx-credits
>>>>>> are fully replenished (ie, == 2) instead of just sleeping the
>>>>>> 2 x beacon-interval?  That would indicate all messages
>>>>>> have been flushed, right?
>>>>>
>>>>>
>>>>> Yeah. You're _almost_ right. Every odd mgmt frame will trigger tx
>>>>> credit replenishment, even if you set NEEDS_CREDITS htc tx flag for
>>>>> all packets. It seems that tx credits aren't replenished until you
>>>>> submit an even number of mgmt tx:
>>>>>
>>>>>   [tx credits =2]
>>>>>   vdev create [-1, =1]
>>>>>   [replenish +1, =2]
>>>>>   mgmt tx [-1, =1]
>>>>>   [frame is seen on air, means it left tx queue, but no replenishment]
>>>>>   vdev set param [-1, =0]
>>>>>   [replenish +1, =1]
>>>>>   mgmt tx [-1, =0]
>>>>>   [frame seen on air]
>>>>>   [replenish +2, =2]
>>>>>
>>>>> However once you flush peer tids you get the tx credit immediately.
>>>>> This means you don't ever reach having 2 mgmt tx consuming 2 tx
>>>>> credits (unless things go terribly terribly wrong at which point it's
>>>>> probably already beyond help).
>>>>>
>>>>> A very ugly hack would be to try and send out mgmt tx in pairs - a
>>>>> requested frame and a dummy frame (such that firmware will not buffer
>>>>> it) so that you use tx credit replenishment as tx completion
>>>>> indication.
>>>>
>>>>
>>>> If you ignore how firmware replenishes the tx-credits for now,
>>>> is it safe to assume that if you have 2 tx-credits while in
>>>> the flush routine, then everything is indeed flushed and
>>>> we can skip the sleep?
>>>
>>> You want to always skip the sleep between mgmt tx and flush commands?
>>> I'm afraid this won't work because tx flush command can end up with
>>> queued frame being dropped or transmitted regardless of destination
>>> station powersave state if submitted too soon.
>>
>> I just want to know if I can skip the sleep if we currently have 2 tx-credits.
> 
> No, not really. At least not in any sane way I can think of.

I managed to hack the firmware and ath10k today so I can get tx
rate reported (perhaps at least mostly correctly, even).  Since this
can only work with my firmware, patch was not sent to the list.


So, I'm back to working on this tx-flush issue again.

I may not have been clear in my question above, as your answer makes no
sense to me :)

My question is:  If the driver/firmware supports max of 2 tx-credits, and we currently
have 2 tx-credits available (ie, there are no pending things in firmware
because we have all credits available), then can we skip the sleep when
flushing?


Second question:  Assuming this is true, if I just make sure the firmware
returns all credits as soon as they are freed up, should that be good
enough to not waste any time sleeping during flush when we do not need
to flush?

And even with stock firmware, we should be able to skip the sleep at
least when we get lucky with current tx-credits-available count...


Thanks,
Ben

> 
> Problem 1:
> If you submit a frame that gets stuck for 10 seconds and you don't
> flush it (and you have no idea when it is safe to flush other than
> timing this with arbitrary numbers like beacon intervals) and you try
> to queue another frame that gets stuck you end up with 0 tx credits.
> 
> Problem 2:
> If you submit a frame and immediately call tx flush you can end up not
> sending out the frame at all or ignoring client power save state I'm
> afraid.
> 
> I was thinking of a more clever hack that would involve sending dummy
> frames (i.e. spurious probe responses) to tickle firmware and force it
> replenish tx credit after sending the actual requested mgmt frame.
> This is ugly, intrusive, wrong and I'm not even sure if this can even
> work.
> 
> 
>> From your answer below, that seems to be a yes.  So, 1/2 of the time (on avg)
>> is worth the hack to me, and if/when I fix the firmware (and/or if QCA fixes
>> the firmware), then we should have 2 tx-credits more often and only sleep when
>> there really is work to do.
> 
> The problem is you don't have a way of knowing if mgmt tx is stuck or
> not both because there is no tx completion and tx credits aren't
> replenished in a sane way. If any of those were ok, we could have a
> wait_for_completion() instead of a msleep() and thus cut down wait
> times for frames that don't get stuck.
> 
> 
>>>> I imagine both I and the QCA firmware guys can make the
>>>> firmware properly replenish tx-credits one at a time instead
>>>> of the only-on-even/odd behaviour you found.
>>>
>>> That would be nice.
>>>
>>>
>>>> But even without that, we might be able to speed up the
>>>> flush 1/2 of the time?
>>>
>>> Yes, although I'm not very fond of the idea of applying a hack on top
>>> of another hack.
>>
>> What is your preferred fix for this?
> 
> Fix the firmware, obviously.
> 
> 999.999.0.636 uses htt for mgmt tx so the problem doesn't exist there.
> That's solely a 10.1 branch issue and I doubt this will be ever fixed
> in this branch...
> 
> 
> Micha?
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From yeohchunyeow at gmail.com  Wed Apr 16 21:45:37 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 17 Apr 2014 12:45:37 +0800
Subject: Firmware 636 crashed with 4addr
In-Reply-To: <CA+BoTQn_cvXXRp52SF3=AFC1Hmx_+yoX=m4sv8XMrJreL9n=sA@mail.gmail.com>
References: <CAEFj987O5CJtdO37FZOsYDgja9YrCEt-Uxka2FYHAx86WPbwbQ@mail.gmail.com>
 <CA+BoTQ=ihvm8-bWyyt6vFr2QqfqRONtbSrALGr6WGcLNYGRukg@mail.gmail.com>
 <CAEFj984A6LF0XG593RU+r3VrmnMgk1iONkvJr+=rSAv8w8o6Gg@mail.gmail.com>
 <CA+BoTQ==WHLUkY622_PJKXmGDU5cbiHa4shNhDycfP5DkJCLeg@mail.gmail.com>
 <CAEFj9876W=i4rfO2rJ+f5+_0ffojmS9KX5XtzuZ+PyumVAPYZA@mail.gmail.com>
 <CA+BoTQn_cvXXRp52SF3=AFC1Hmx_+yoX=m4sv8XMrJreL9n=sA@mail.gmail.com>
Message-ID: <CAEFj986pdpL4pCv9sjMU1reRzd_dCkVjc5=ceH_ywSwziwXb2A@mail.gmail.com>

Hi, Michal

Hopefully this is sufficient. Please see the attached file.

I up the wlan, connect to AP, set 4addr on, then bridge the wlan0 to
bridge interface.

---
Chun-Yeow

On Wed, Apr 16, 2014 at 6:43 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 16 April 2014 12:40, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
>> Sure, any specific logs or traces that you want?
>
> I think hexdumps aren't necessary. debug_mask=0xffffff3f should suffice.
>
>
>> Will do it later.
>
> Okay :-)
>
>
> Micha?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ath10k-dbg.log
Type: text/x-log
Size: 124391 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20140417/d40fc411/attachment-0001.bin>

From michal.kazior at tieto.com  Wed Apr 16 23:04:15 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 17 Apr 2014 08:04:15 +0200
Subject: Question on ath10k_mgmt_tx_flush
In-Reply-To: <534F2855.2030305@candelatech.com>
References: <53469F7B.2080202@candelatech.com>
 <CA+BoTQmc=n7ifUh+8Lq_1P=t4KJyDDFjcs3Z1mW1nHFO+WR2hw@mail.gmail.com>
 <5347ED46.3000406@candelatech.com>
 <CA+BoTQ=oyXd4qCOhBQE5QCu+KYaqB+_9qSdaTL_z_m2C=c=WYg@mail.gmail.com>
 <534C028E.4000302@candelatech.com>
 <CA+BoTQ=MbQ3a6FMH-mVFhM7ToXys559AAHO_fB-u59bVdPpZKg@mail.gmail.com>
 <534F2855.2030305@candelatech.com>
Message-ID: <CA+BoTQn-1Gr2m9CDSt5YtrnTZL_SE6Syd4ADDWOkYsL4xtz-6Q@mail.gmail.com>

On 17 April 2014 03:03, Ben Greear <greearb at candelatech.com> wrote:
> On 04/14/2014 11:41 PM, Michal Kazior wrote:
>> On 14 April 2014 17:45, Ben Greear <greearb at candelatech.com> wrote:
>>> On 04/13/2014 11:31 PM, Michal Kazior wrote:
>>>> On 11 April 2014 15:25, Ben Greear <greearb at candelatech.com> wrote:
>>>>> On 04/10/2014 10:21 PM, Michal Kazior wrote:
>>>>>>
>>>>>> On 10 April 2014 15:41, Ben Greear <greearb at candelatech.com> wrote:
>>>>>>>
>>>>>>> Can we optimize this method to return early if the tx-credits
>>>>>>> are fully replenished (ie, == 2) instead of just sleeping the
>>>>>>> 2 x beacon-interval?  That would indicate all messages
>>>>>>> have been flushed, right?
>>>>>>
>>>>>>
>>>>>> Yeah. You're _almost_ right. Every odd mgmt frame will trigger tx
>>>>>> credit replenishment, even if you set NEEDS_CREDITS htc tx flag for
>>>>>> all packets. It seems that tx credits aren't replenished until you
>>>>>> submit an even number of mgmt tx:
>>>>>>
>>>>>>   [tx credits =2]
>>>>>>   vdev create [-1, =1]
>>>>>>   [replenish +1, =2]
>>>>>>   mgmt tx [-1, =1]
>>>>>>   [frame is seen on air, means it left tx queue, but no replenishment]
>>>>>>   vdev set param [-1, =0]
>>>>>>   [replenish +1, =1]
>>>>>>   mgmt tx [-1, =0]
>>>>>>   [frame seen on air]
>>>>>>   [replenish +2, =2]
>>>>>>
>>>>>> However once you flush peer tids you get the tx credit immediately.
>>>>>> This means you don't ever reach having 2 mgmt tx consuming 2 tx
>>>>>> credits (unless things go terribly terribly wrong at which point it's
>>>>>> probably already beyond help).
>>>>>>
>>>>>> A very ugly hack would be to try and send out mgmt tx in pairs - a
>>>>>> requested frame and a dummy frame (such that firmware will not buffer
>>>>>> it) so that you use tx credit replenishment as tx completion
>>>>>> indication.
>>>>>
>>>>>
>>>>> If you ignore how firmware replenishes the tx-credits for now,
>>>>> is it safe to assume that if you have 2 tx-credits while in
>>>>> the flush routine, then everything is indeed flushed and
>>>>> we can skip the sleep?
>>>>
>>>> You want to always skip the sleep between mgmt tx and flush commands?
>>>> I'm afraid this won't work because tx flush command can end up with
>>>> queued frame being dropped or transmitted regardless of destination
>>>> station powersave state if submitted too soon.
>>>
>>> I just want to know if I can skip the sleep if we currently have 2 tx-credits.
>>
>> No, not really. At least not in any sane way I can think of.
>
> I managed to hack the firmware and ath10k today so I can get tx
> rate reported (perhaps at least mostly correctly, even).  Since this
> can only work with my firmware, patch was not sent to the list.
>
>
> So, I'm back to working on this tx-flush issue again.
>
> I may not have been clear in my question above, as your answer makes no
> sense to me :)
>
> My question is:  If the driver/firmware supports max of 2 tx-credits, and we currently
> have 2 tx-credits available (ie, there are no pending things in firmware
> because we have all credits available), then can we skip the sleep when
> flushing?

If you do mgmt_tx+flush without any wait you'll end up disregarding
station powersave or drop frame before it is actually transmitted.
With stock firmware there's no way to wait for wmi mgmt tx completion
other than to sleep because tx credits are replenished in pairs. If
you send a mgmt tx and don't flush you risk getting stuck with next
mgmt tx at which point you can't even flush because you're out of
credits.


> Second question:  Assuming this is true, if I just make sure the firmware
> returns all credits as soon as they are freed up, should that be good
> enough to not waste any time sleeping during flush when we do not need
> to flush?

Yes, this is sufficient as a tx completion but is the most hacky way to do it.


> And even with stock firmware, we should be able to skip the sleep at
> least when we get lucky with current tx-credits-available count...

I don't think you can do that.

Even if you have 2 tx credits available and submit mgmt tx - what do
you do from then on? You won't receive tx credit replenishment when
the tx completes unless you submit flush or another mgmt tx. Flush can
drop frames/disregard powersave and next mgmt tx can get stuck. You
could try pushing dummy mgmt tx (spurious probe resp?) assuming it
never gets stuck but that's way beyond an acceptable workaround..

There really isn't any way other than to have a reliable tx completion
indication so that wmi tx worker can flush mgmt frames if they take
too long to complete.

I'd be happy to proven wrong though.


Micha?


From michal.kazior at tieto.com  Wed Apr 16 23:12:06 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 17 Apr 2014 08:12:06 +0200
Subject: [PATCH] ath10k: Hold tx-lock while detaching htt.
In-Reply-To: <1397695357-14028-1-git-send-email-greearb@candelatech.com>
References: <1397695357-14028-1-git-send-email-greearb@candelatech.com>
Message-ID: <CA+BoTQ=Q3s6_9tXq02_3S0=q5qv4U4V1F_qHoN1X1pfWV9CKBA@mail.gmail.com>

On 17 April 2014 02:42,  <greearb at candelatech.com> wrote:
> From: Ben Greear <greearb at candelatech.com>
>
> And check for null pool in the tx path (which would
> indicate we are detaching).

Shouldn't we just make sure tx is stopped before we try to detach htt?
Stoping mac80211 queues and synchronize_net() should be sufficient I
think.


> @@ -403,6 +412,13 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
>                 goto err;
>
>         spin_lock_bh(&htt->tx_lock);
> +
> +       /* Check if we are detached... */
> +       if (! htt->tx_pool) {
> +               spin_unlock_bh(&htt->tx_lock);

Setting `res` would be nice to indicate an error. And there's a space after !.


Micha?


From michal.kazior at tieto.com  Wed Apr 16 23:15:46 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 17 Apr 2014 08:15:46 +0200
Subject: Firmware 636 crashed with 4addr
In-Reply-To: <CAEFj986pdpL4pCv9sjMU1reRzd_dCkVjc5=ceH_ywSwziwXb2A@mail.gmail.com>
References: <CAEFj987O5CJtdO37FZOsYDgja9YrCEt-Uxka2FYHAx86WPbwbQ@mail.gmail.com>
 <CA+BoTQ=ihvm8-bWyyt6vFr2QqfqRONtbSrALGr6WGcLNYGRukg@mail.gmail.com>
 <CAEFj984A6LF0XG593RU+r3VrmnMgk1iONkvJr+=rSAv8w8o6Gg@mail.gmail.com>
 <CA+BoTQ==WHLUkY622_PJKXmGDU5cbiHa4shNhDycfP5DkJCLeg@mail.gmail.com>
 <CAEFj9876W=i4rfO2rJ+f5+_0ffojmS9KX5XtzuZ+PyumVAPYZA@mail.gmail.com>
 <CA+BoTQn_cvXXRp52SF3=AFC1Hmx_+yoX=m4sv8XMrJreL9n=sA@mail.gmail.com>
 <CAEFj986pdpL4pCv9sjMU1reRzd_dCkVjc5=ceH_ywSwziwXb2A@mail.gmail.com>
Message-ID: <CA+BoTQ=U7NDb-J6P-_9o0x46eyk+-mYbsGB5UhDgHizp2fnM1A@mail.gmail.com>

On 17 April 2014 06:45, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
> Hi, Michal
>
> Hopefully this is sufficient. Please see the attached file.

Unfortunately it's too short. I can't tell anything from it. I need it
to include it all the way from the moment the device is booted and
used.


> I up the wlan, connect to AP, set 4addr on, then bridge the wlan0 to
> bridge interface.

I need these steps to be visible in logs. I should've mentioned that
earlier.. sorry for the trouble.


Micha?


From greearb at candelatech.com  Wed Apr 16 23:35:06 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 16 Apr 2014 23:35:06 -0700
Subject: Question on ath10k_mgmt_tx_flush
In-Reply-To: <CA+BoTQn-1Gr2m9CDSt5YtrnTZL_SE6Syd4ADDWOkYsL4xtz-6Q@mail.gmail.com>
References: <53469F7B.2080202@candelatech.com>	<CA+BoTQmc=n7ifUh+8Lq_1P=t4KJyDDFjcs3Z1mW1nHFO+WR2hw@mail.gmail.com>	<5347ED46.3000406@candelatech.com>	<CA+BoTQ=oyXd4qCOhBQE5QCu+KYaqB+_9qSdaTL_z_m2C=c=WYg@mail.gmail.com>	<534C028E.4000302@candelatech.com>	<CA+BoTQ=MbQ3a6FMH-mVFhM7ToXys559AAHO_fB-u59bVdPpZKg@mail.gmail.com>	<534F2855.2030305@candelatech.com>
 <CA+BoTQn-1Gr2m9CDSt5YtrnTZL_SE6Syd4ADDWOkYsL4xtz-6Q@mail.gmail.com>
Message-ID: <534F761A.6040309@candelatech.com>

On 04/16/2014 11:04 PM, Michal Kazior wrote:
> On 17 April 2014 03:03, Ben Greear <greearb at candelatech.com> wrote:
>> On 04/14/2014 11:41 PM, Michal Kazior wrote:
>>> On 14 April 2014 17:45, Ben Greear <greearb at candelatech.com> wrote:
>>>> On 04/13/2014 11:31 PM, Michal Kazior wrote:
>>>>> On 11 April 2014 15:25, Ben Greear <greearb at candelatech.com> wrote:
>>>>>> On 04/10/2014 10:21 PM, Michal Kazior wrote:
>>>>>>>
>>>>>>> On 10 April 2014 15:41, Ben Greear <greearb at candelatech.com> wrote:
>>>>>>>>
>>>>>>>> Can we optimize this method to return early if the tx-credits
>>>>>>>> are fully replenished (ie, == 2) instead of just sleeping the
>>>>>>>> 2 x beacon-interval?  That would indicate all messages
>>>>>>>> have been flushed, right?
>>>>>>>
>>>>>>>
>>>>>>> Yeah. You're _almost_ right. Every odd mgmt frame will trigger tx
>>>>>>> credit replenishment, even if you set NEEDS_CREDITS htc tx flag for
>>>>>>> all packets. It seems that tx credits aren't replenished until you
>>>>>>> submit an even number of mgmt tx:
>>>>>>>
>>>>>>>    [tx credits =2]
>>>>>>>    vdev create [-1, =1]
>>>>>>>    [replenish +1, =2]
>>>>>>>    mgmt tx [-1, =1]
>>>>>>>    [frame is seen on air, means it left tx queue, but no replenishment]
>>>>>>>    vdev set param [-1, =0]
>>>>>>>    [replenish +1, =1]
>>>>>>>    mgmt tx [-1, =0]
>>>>>>>    [frame seen on air]
>>>>>>>    [replenish +2, =2]
>>>>>>>
>>>>>>> However once you flush peer tids you get the tx credit immediately.
>>>>>>> This means you don't ever reach having 2 mgmt tx consuming 2 tx
>>>>>>> credits (unless things go terribly terribly wrong at which point it's
>>>>>>> probably already beyond help).
>>>>>>>
>>>>>>> A very ugly hack would be to try and send out mgmt tx in pairs - a
>>>>>>> requested frame and a dummy frame (such that firmware will not buffer
>>>>>>> it) so that you use tx credit replenishment as tx completion
>>>>>>> indication.
>>>>>>
>>>>>>
>>>>>> If you ignore how firmware replenishes the tx-credits for now,
>>>>>> is it safe to assume that if you have 2 tx-credits while in
>>>>>> the flush routine, then everything is indeed flushed and
>>>>>> we can skip the sleep?
>>>>>
>>>>> You want to always skip the sleep between mgmt tx and flush commands?
>>>>> I'm afraid this won't work because tx flush command can end up with
>>>>> queued frame being dropped or transmitted regardless of destination
>>>>> station powersave state if submitted too soon.
>>>>
>>>> I just want to know if I can skip the sleep if we currently have 2 tx-credits.
>>>
>>> No, not really. At least not in any sane way I can think of.
>>
>> I managed to hack the firmware and ath10k today so I can get tx
>> rate reported (perhaps at least mostly correctly, even).  Since this
>> can only work with my firmware, patch was not sent to the list.
>>
>>
>> So, I'm back to working on this tx-flush issue again.
>>
>> I may not have been clear in my question above, as your answer makes no
>> sense to me :)
>>
>> My question is:  If the driver/firmware supports max of 2 tx-credits, and we currently
>> have 2 tx-credits available (ie, there are no pending things in firmware
>> because we have all credits available), then can we skip the sleep when
>> flushing?
>
> If you do mgmt_tx+flush without any wait you'll end up disregarding
> station powersave or drop frame before it is actually transmitted.
> With stock firmware there's no way to wait for wmi mgmt tx completion
> other than to sleep because tx credits are replenished in pairs. If
> you send a mgmt tx and don't flush you risk getting stuck with next
> mgmt tx at which point you can't even flush because you're out of
> credits.

Ok, I will try to fix that issue of credits being replenished in
pairs.  I have been following the twisty paths of the firmware, but
so far I cannot see why the problem should exist...

Thanks for the patience and details below..I think I'm getting
and understanding of the problem now...

Thanks,
Ben

>
>
>> Second question:  Assuming this is true, if I just make sure the firmware
>> returns all credits as soon as they are freed up, should that be good
>> enough to not waste any time sleeping during flush when we do not need
>> to flush?
>
> Yes, this is sufficient as a tx completion but is the most hacky way to do it.
>
>
>> And even with stock firmware, we should be able to skip the sleep at
>> least when we get lucky with current tx-credits-available count...
>
> I don't think you can do that.
>
> Even if you have 2 tx credits available and submit mgmt tx - what do
> you do from then on? You won't receive tx credit replenishment when
> the tx completes unless you submit flush or another mgmt tx. Flush can
> drop frames/disregard powersave and next mgmt tx can get stuck. You
> could try pushing dummy mgmt tx (spurious probe resp?) assuming it
> never gets stuck but that's way beyond an acceptable workaround..
>
> There really isn't any way other than to have a reliable tx completion
> indication so that wmi tx worker can flush mgmt frames if they take
> too long to complete.
>
> I'd be happy to proven wrong though.
>
>
> Micha?
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From yeohchunyeow at gmail.com  Thu Apr 17 02:03:32 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 17 Apr 2014 17:03:32 +0800
Subject: Firmware 636 crashed with 4addr
In-Reply-To: <CAEFj986P6OmHpue65NVLmaMn7Sdbs21j+B1nOi4awAHYRA4+gw@mail.gmail.com>
References: <CAEFj987O5CJtdO37FZOsYDgja9YrCEt-Uxka2FYHAx86WPbwbQ@mail.gmail.com>
 <CA+BoTQ=ihvm8-bWyyt6vFr2QqfqRONtbSrALGr6WGcLNYGRukg@mail.gmail.com>
 <CAEFj984A6LF0XG593RU+r3VrmnMgk1iONkvJr+=rSAv8w8o6Gg@mail.gmail.com>
 <CA+BoTQ==WHLUkY622_PJKXmGDU5cbiHa4shNhDycfP5DkJCLeg@mail.gmail.com>
 <CAEFj9876W=i4rfO2rJ+f5+_0ffojmS9KX5XtzuZ+PyumVAPYZA@mail.gmail.com>
 <CA+BoTQn_cvXXRp52SF3=AFC1Hmx_+yoX=m4sv8XMrJreL9n=sA@mail.gmail.com>
 <CAEFj986pdpL4pCv9sjMU1reRzd_dCkVjc5=ceH_ywSwziwXb2A@mail.gmail.com>
 <CA+BoTQ=U7NDb-J6P-_9o0x46eyk+-mYbsGB5UhDgHizp2fnM1A@mail.gmail.com>
 <CAEFj986P6OmHpue65NVLmaMn7Sdbs21j+B1nOi4awAHYRA4+gw@mail.gmail.com>
Message-ID: <CAEFj987ROX3TjV-va4uZQK=okNp6M7kpy4gjW=VATrfytQXXMw@mail.gmail.com>

Hi, Michal

If you are not able to receive my previous email with attachment, do
let me know.

----
Chun-Yeow

On Thu, Apr 17, 2014 at 4:34 PM, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
> I have captured more on the log. It's about 6M.
>
> ----
> Chun-Yeow
>
> On Thu, Apr 17, 2014 at 2:15 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
>> On 17 April 2014 06:45, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
>>> Hi, Michal
>>>
>>> Hopefully this is sufficient. Please see the attached file.
>>
>> Unfortunately it's too short. I can't tell anything from it. I need it
>> to include it all the way from the moment the device is booted and
>> used.
>>
>>
>>> I up the wlan, connect to AP, set 4addr on, then bridge the wlan0 to
>>> bridge interface.
>>
>> I need these steps to be visible in logs. I should've mentioned that
>> earlier.. sorry for the trouble.
>>
>>
>> Micha?


From michal.kazior at tieto.com  Thu Apr 17 02:04:51 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 17 Apr 2014 11:04:51 +0200
Subject: Firmware 636 crashed with 4addr
In-Reply-To: <CAEFj986P6OmHpue65NVLmaMn7Sdbs21j+B1nOi4awAHYRA4+gw@mail.gmail.com>
References: <CAEFj987O5CJtdO37FZOsYDgja9YrCEt-Uxka2FYHAx86WPbwbQ@mail.gmail.com>
 <CA+BoTQ=ihvm8-bWyyt6vFr2QqfqRONtbSrALGr6WGcLNYGRukg@mail.gmail.com>
 <CAEFj984A6LF0XG593RU+r3VrmnMgk1iONkvJr+=rSAv8w8o6Gg@mail.gmail.com>
 <CA+BoTQ==WHLUkY622_PJKXmGDU5cbiHa4shNhDycfP5DkJCLeg@mail.gmail.com>
 <CAEFj9876W=i4rfO2rJ+f5+_0ffojmS9KX5XtzuZ+PyumVAPYZA@mail.gmail.com>
 <CA+BoTQn_cvXXRp52SF3=AFC1Hmx_+yoX=m4sv8XMrJreL9n=sA@mail.gmail.com>
 <CAEFj986pdpL4pCv9sjMU1reRzd_dCkVjc5=ceH_ywSwziwXb2A@mail.gmail.com>
 <CA+BoTQ=U7NDb-J6P-_9o0x46eyk+-mYbsGB5UhDgHizp2fnM1A@mail.gmail.com>
 <CAEFj986P6OmHpue65NVLmaMn7Sdbs21j+B1nOi4awAHYRA4+gw@mail.gmail.com>
Message-ID: <CA+BoTQk3=pD7By588+8sZo+GQqejQNvQ6Ky9+rgTpj-FVvd0Pw@mail.gmail.com>

On 17 April 2014 10:34, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
> I have captured more on the log. It's about 6M.

Thanks! This gives me a better picture of what's going on.

What caught my eye is your vif macaddr (60:02:b4:9d:99:91). It doesn't
seem like an original for the hw (00:03:7f:xx:xx:xx). I wouldn't be
surprised if that's the problem.

The 4addr patch alone shouldn't be a problem since it only deals with
rx frame processing and is beyond what fw is doing.

I'll check sta vif on 636 later today and see if I can reproduce this.


Micha?


From yeohchunyeow at gmail.com  Thu Apr 17 02:10:50 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 17 Apr 2014 17:10:50 +0800
Subject: Firmware 636 crashed with 4addr
In-Reply-To: <CA+BoTQk3=pD7By588+8sZo+GQqejQNvQ6Ky9+rgTpj-FVvd0Pw@mail.gmail.com>
References: <CAEFj987O5CJtdO37FZOsYDgja9YrCEt-Uxka2FYHAx86WPbwbQ@mail.gmail.com>
 <CA+BoTQ=ihvm8-bWyyt6vFr2QqfqRONtbSrALGr6WGcLNYGRukg@mail.gmail.com>
 <CAEFj984A6LF0XG593RU+r3VrmnMgk1iONkvJr+=rSAv8w8o6Gg@mail.gmail.com>
 <CA+BoTQ==WHLUkY622_PJKXmGDU5cbiHa4shNhDycfP5DkJCLeg@mail.gmail.com>
 <CAEFj9876W=i4rfO2rJ+f5+_0ffojmS9KX5XtzuZ+PyumVAPYZA@mail.gmail.com>
 <CA+BoTQn_cvXXRp52SF3=AFC1Hmx_+yoX=m4sv8XMrJreL9n=sA@mail.gmail.com>
 <CAEFj986pdpL4pCv9sjMU1reRzd_dCkVjc5=ceH_ywSwziwXb2A@mail.gmail.com>
 <CA+BoTQ=U7NDb-J6P-_9o0x46eyk+-mYbsGB5UhDgHizp2fnM1A@mail.gmail.com>
 <CAEFj986P6OmHpue65NVLmaMn7Sdbs21j+B1nOi4awAHYRA4+gw@mail.gmail.com>
 <CA+BoTQk3=pD7By588+8sZo+GQqejQNvQ6Ky9+rgTpj-FVvd0Pw@mail.gmail.com>
Message-ID: <CAEFj984C2pQS+f6fGNLAhmrhtemDabTDHdQR-0pWck=O9H1SFQ@mail.gmail.com>

Yes, this is from my ubuntu laptop, the previous one is from my
embedded board. Both are using the latest ath10k-next.

----
Chun-Yeow

On Thu, Apr 17, 2014 at 5:04 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 17 April 2014 10:34, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
>> I have captured more on the log. It's about 6M.
>
> Thanks! This gives me a better picture of what's going on.
>
> What caught my eye is your vif macaddr (60:02:b4:9d:99:91). It doesn't
> seem like an original for the hw (00:03:7f:xx:xx:xx). I wouldn't be
> surprised if that's the problem.
>
> The 4addr patch alone shouldn't be a problem since it only deals with
> rx frame processing and is beyond what fw is doing.
>
> I'll check sta vif on 636 later today and see if I can reproduce this.
>
>
> Micha?


From greearb at candelatech.com  Fri Apr 18 13:09:59 2014
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 18 Apr 2014 13:09:59 -0700
Subject: Anyone else see host machine lockups?
Message-ID: <53518697.4090406@candelatech.com>

We can reliably lock up a host system (no splats, no mention of
firmware crashes, system just dies) when we bring up or down a
bunch of vifs in a system with 3 radios in a PC.

Anyone else seeing similar?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From adrian at freebsd.org  Sat Apr 19 07:41:14 2014
From: adrian at freebsd.org (Adrian Chadd)
Date: Sat, 19 Apr 2014 07:41:14 -0700
Subject: Anyone else see host machine lockups?
In-Reply-To: <53518697.4090406@candelatech.com>
References: <53518697.4090406@candelatech.com>
Message-ID: <CAJ-Vmok6D88OHUPKhL0hXqX1RFDv42OkuChDBfEN7nB2JLM_sg@mail.gmail.com>

Heh, no, but back in the day this'd happen if the DMA engine wasn't
shut down in the right order. The NIC would start DMAing crap all over
random memory.

I wonder if that's happening here.



-a


On 18 April 2014 13:09, Ben Greear <greearb at candelatech.com> wrote:
> We can reliably lock up a host system (no splats, no mention of
> firmware crashes, system just dies) when we bring up or down a
> bunch of vifs in a system with 3 radios in a PC.
>
> Anyone else seeing similar?
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From greearb at candelatech.com  Sat Apr 19 08:03:45 2014
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 19 Apr 2014 08:03:45 -0700
Subject: Anyone else see host machine lockups?
In-Reply-To: <CAJ-Vmok6D88OHUPKhL0hXqX1RFDv42OkuChDBfEN7nB2JLM_sg@mail.gmail.com>
References: <53518697.4090406@candelatech.com>
 <CAJ-Vmok6D88OHUPKhL0hXqX1RFDv42OkuChDBfEN7nB2JLM_sg@mail.gmail.com>
Message-ID: <53529051.2040702@candelatech.com>

On 04/19/2014 07:41 AM, Adrian Chadd wrote:
> Heh, no, but back in the day this'd happen if the DMA engine wasn't
> shut down in the right order. The NIC would start DMAing crap all over
> random memory.
>
> I wonder if that's happening here.

Maybe, but I would hope that such a problem would at least often crash
the OS with some strange crashes as opposed to just silent host lockup?

Thanks,
Ben

>
>
>
> -a
>
>
> On 18 April 2014 13:09, Ben Greear <greearb at candelatech.com> wrote:
>> We can reliably lock up a host system (no splats, no mention of
>> firmware crashes, system just dies) when we bring up or down a
>> bunch of vifs in a system with 3 radios in a PC.
>>
>> Anyone else seeing similar?
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From bart.jooris at gmail.com  Sat Apr 19 12:48:55 2014
From: bart.jooris at gmail.com (Bart Jooris)
Date: Sat, 19 Apr 2014 21:48:55 +0200
Subject: Running throughput tests
In-Reply-To: <871tx8m1qs.fsf@kamboji.qca.qualcomm.com>
References: <00ea01cee403$5331f1e0$f995d5a0$@sparklan.com>	<012e01cef7e0$99017e70$cb047b50$@sparklan.com>	<52AACFB9.8080901@intec.ugent.be>	<006301cefa3c$44c07b50$ce4171f0$@sparklan.com>	<52AEC26B.2060400@intec.ugent.be>	<007f01cefa41$8a940de0$9fbc29a0$@sparklan.com>	<52AEE61F.5030505@intec.ugent.be>	<006b01cefacb$6c0b2d60$44218820$@sparklan.com>	<52B00B10.3050300@intec.ugent.be>	<004b01cefb9d$04a543e0$0defcba0$@sparklan.com>	<52B2AE75.9050206@intec.ugent.be>	<00df01cf0090$05944f10$10bced30$@sparklan.com>	<52B9672E.9000701@intec.ugent.be>	<008c01cf012e$e59563d0$b0c02b70$@sparklan.com>	<530A64E5.2040401@intec.ugent.be>
 <530B0670.1010009@stackframe.org>	<530E5EF2.8070800@intec.ugent.be>	<87y50weecb.fsf_-_@kamboji.qca.qualcomm.com>	<5335910B.3000702@intec.ugent.be>	<87y4zutk4i.fsf@kamboji.qca.qualcomm.com>	<53372210.7060903@intec.ugent.be>
 <871tx8m1qs.fsf@kamboji.qca.qualcomm.com>
Message-ID: <5352D327.7060106@intec.ugent.be>

Hi Kalle,

I also have a stable 500Mbps ++ link now :-) with peaks up to 520Mbps 
(measured with iperf UDP).
I've  made a second AP and STA with the WLE900VX cards I've exchanged 
with Ben (Thanks again!). Both have Ubuntu 12.04, ath10k from backports 
release and modified  regulatory.bin.
The AP has now 10.1.467.2-1 like you suggested and STA has still 
999.999.0.636.
In combination with, the lowest txPower and  the dipole antennas 
configured like this
"\    | /"  (same plane)
we measured 500Mbps++ in a anechoic chamber (ranged AP<->STA 20cm .. 270cm).
We observed the same speeds  at our offices now and even when we replace 
the  antennas with 1:1 coax + 20db attenuation we 've got 500Mbps++.

Sometime It can take up to 20 seconds before the link maximises, but 
once it gets there it is extremely stable :-).
I will take a look at the ath10k_core.ko debug_mask and HTT statistics 
first to see what happens.
Should I still be able to build a sniffer with the interface in monitor 
mode in combination Wireshark?

Thanks a lot,

Bart


p.s. The configuration with the sparkLAN WPEA-351AC cards still doesn't 
give the same results. Probably my bad, I will double check it again.



On 04/08/2014 02:42 PM, Kalle Valo wrote:
> Hi Bart,
>
> Bart Jooris <bart.jooris at gmail.com> writes:
>
>> On 03/28/2014 04:31 PM, Kalle Valo wrote:
>>
>>> You are providing very little information which makes it difficult to
>>> help. For starters:
>>>
>>> * What firmware version?
>> I've cloned 'recently' https://github.com/kvalo/ath10k-firmware/
>>
>> tree -D /lib/firmware/ath10k/QCA988X
>> ??? [Mar 29 10:46] hw2.0
>> ??? [Feb 26 19:39] board.bin
>> ??? [Feb 26 19:39] firmware-2.bin
>> ??? [Feb 26 19:39] otp.bin
> That doesn't tell anything about the firmware version. Please read this:
>
> http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Firmware_version
>
> You should use 10.1.467.2-1 and see this in dmesg:
>
> [ 2651.506691] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.1.467.2-1 api 2 htt 2.1
>
> (Please note that the info print was changed few weeks back, so it won't
> look exactly same on 3.13.)
>
>>> * What version of ath10k are you using?
>> I compiled kernel 3.13.5.
> Ok, that's a relatively old as the version of ath10k in that release is
> from last October. We have had quite a few optimisations and fixes since
> then but you should still easily get 400 Mbps, especially on your fast
> x86 cpus.
>
>>> * Are you sure that the host is not limiting the throughput in any way?
>>>     Try to disable _all_ kernel debug options.
>> /var/log/syslog and dmesg doesn't to be packed with messages related
>> to the throughput test. I don't think to have seen the CPU being
>> overloaded during the test.
>> I'm planning to go back to the office tomorrow to verify this.
>>
>> Further I have these in my kernel config
>> CONFIG_ATH10K=m
>> CONFIG_ATH10K_PCI=m
>> # CONFIG_ATH10K_DEBUG is not set
>> CONFIG_ATH10K_DEBUGFS=y
>> CONFIG_ATH10K_TRACING=y
>>
>> I will disable the last two too.
> Ok, this looks good. But just to confirm, can you send the full kernel
> config file as well?
>
>>> * Also describe your test setup in detail.
>>>
>> Common for AP and STA:
>>
>> -DSS-1300 with i5-2540M CPU @ 2.60GHz - 8GB RAM - SSD 64GB.
>> -1 sparkLAN WPEA-351AC card with QCA9880 chip set and 3 dual band antenna's.
>> -Kernel 3.13.5 containing the ath10k modules
>> -firmwares cloned end of February
>> -iperf in udp mode used for the  throughput test
>>
>> AP only:
>> -ubuntu 12.04 LTS as crda wouldn't build on ubuntu 13.10 (libgcrypt issue).
>> -hostapd v2.2-devel
>> -modified regulatory database and crda build
>> -your Full_hostapd_configuration + channel=36 and vht_oper_centr_freq_seg0_idx=42
>>
>> STA only:
>> -ubuntu 13.10
>> -nmcli is used to connect to the AP
>>
>> Distance between AP and STA: 60 cm. Antenna's are now directed
>> orthogonal per device, antennaX (X=1..3) on both devices are pointing
>> in the same direction. Although I've played a lot with the antenna's
>> directions already and I can't remember one run where it had a lot of
>> impact...
>>
>> The spectrum analyser measured a band of almost 80MHz being used.
> This looks good as well. Is it possible for you take debug logs? First
> enable these ath10k options:
>
> CONFIG_ATH10K_DEBUG=y
> CONFIG_ATH10K_DEBUGFS=y
> CONFIG_ATH10K_TRACING=y
>
> And start ath10k with debug mask 0x432, which prints info related to
> firmware configuration:
>
> modprobe ath10k_core.ko debug_mask=0x432
>
> Also start hostapd with -dddt and connect the ath10k STA to the AP. Then
> send here both the full dmesg output, preferably starting from kernel
> boot, and hostapd debug logs here from the AP. No need to run any
> throughput tests in this case, I just want to see how we configure the
> firmware when the STA associates.
>
> And even better if you could use trace-cmd, we get more logs that way:
>
> http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Tracing
>


-- 
Bart Jooris
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - iMinds
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
E-mail: bart.jooris at intec.UGent.be
M: +32 474 59 53 42
Tel. +32 9 33 14900
Fax +32 9 33 14899



From michal.kazior at tieto.com  Mon Apr 21 23:53:32 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 22 Apr 2014 08:53:32 +0200
Subject: Anyone else see host machine lockups?
In-Reply-To: <53518697.4090406@candelatech.com>
References: <53518697.4090406@candelatech.com>
Message-ID: <CA+BoTQmbdYXJy_VOmoRZrLd+nLpAB6LuHp6QGYmG=-rCJuecmg@mail.gmail.com>

On 18 April 2014 22:09, Ben Greear <greearb at candelatech.com> wrote:
> We can reliably lock up a host system (no splats, no mention of
> firmware crashes, system just dies) when we bring up or down a
> bunch of vifs in a system with 3 radios in a PC.
>
> Anyone else seeing similar?

>From what I understand this seems to be faulty CUS hardware design.
The problem occurs when trying to perform cold reset on target device
which sometimes leads to voltage drops/spikes which in turn breaks
PCI-E link. Some host controllers apparently can't deal with it and
hang the whole machine (e.g. Thinkpad T430), while others just lose
connectivity with the device and need re-plugging (e.g. Dell E6420) or
display a splat and need to be restarted before given PCI-E slot can
be used again (e.g. AP135's "Data bus error").


Michal


From greearb at candelatech.com  Tue Apr 22 07:44:40 2014
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 22 Apr 2014 07:44:40 -0700
Subject: Anyone else see host machine lockups?
In-Reply-To: <CA+BoTQmbdYXJy_VOmoRZrLd+nLpAB6LuHp6QGYmG=-rCJuecmg@mail.gmail.com>
References: <53518697.4090406@candelatech.com>
 <CA+BoTQmbdYXJy_VOmoRZrLd+nLpAB6LuHp6QGYmG=-rCJuecmg@mail.gmail.com>
Message-ID: <53568058.9020009@candelatech.com>

On 04/21/2014 11:53 PM, Michal Kazior wrote:
> On 18 April 2014 22:09, Ben Greear <greearb at candelatech.com> wrote:
>> We can reliably lock up a host system (no splats, no mention of
>> firmware crashes, system just dies) when we bring up or down a
>> bunch of vifs in a system with 3 radios in a PC.
>>
>> Anyone else seeing similar?
>
>>From what I understand this seems to be faulty CUS hardware design.
> The problem occurs when trying to perform cold reset on target device
> which sometimes leads to voltage drops/spikes which in turn breaks
> PCI-E link. Some host controllers apparently can't deal with it and
> hang the whole machine (e.g. Thinkpad T430), while others just lose
> connectivity with the device and need re-plugging (e.g. Dell E6420) or
> display a splat and need to be restarted before given PCI-E slot can
> be used again (e.g. AP135's "Data bus error").

I see this on WLE900VX NICs as well, so it's not just a CUS issue.

And, I don't think it is just cold-reset, because I do not see any
console messages about attempting a cold reset.

Thanks,
Ben

>
>
> Michal
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From linville at tuxdriver.com  Tue Apr 22 13:06:58 2014
From: linville at tuxdriver.com (John W. Linville)
Date: Tue, 22 Apr 2014 16:06:58 -0400
Subject: Pull request: ath 20140415
In-Reply-To: <87mwfndrt4.fsf@kamboji.qca.qualcomm.com>
References: <87mwfndrt4.fsf@kamboji.qca.qualcomm.com>
Message-ID: <20140422200658.GD16193@tuxdriver.com>

On Tue, Apr 15, 2014 at 09:34:31AM +0300, Kalle Valo wrote:
> Hi John,
> 
> here's a pull request for ath6kl and ath10k with changes accumulated
> just before and during the merge window. Please let me know if there any
> problems.
> 
> Here's the list of changes:
> 
> ----------------------------------------------------------------------
> 
> For ath6kl Kalle fixed a bunch of checkpatch warnings.
> 
> In ath10k we had more changes, major ones being:
> 
> * fix memory allocation failures after a firmware crash (Michal)
> 
> * some rework of DFS configuration to enable it correctly in all cases
>   (Michal)
> 
> * add a new firmware crash option to make it possible to crash 10.1
>   firmware for testing purposes (Marek P)
> 
> * fix RTS/CTS protection in certain cases (Marek K)
> 
> * fix wrong RSSI and rate reporting in some cases (Janusz)
> 
> * fix firmware stats reporting (Chun, Ben & Bartosz)
> 
> ----------------------------------------------------------------------
> 
> The following changes since commit 70dd77b4c50da518b57b8b9b125a8c9aabe9bc1a:
> 
>   ath10k: do not overwrite max_antenna_gain (2014-03-07 10:14:10 +0200)
> 
> are available in the git repository at:
> 
>   git://github.com/kvalo/ath.git for-linville
> 
> for you to fetch changes up to 4bfee8e8c13fc9477eb9420efd5a5d12e32ac614:
> 
>   ath10k: improve htc tx credit debugging prints (2014-04-11 08:35:56 +0300)

Pulled today...

-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


From kvalo at qca.qualcomm.com  Wed Apr 23 23:21:32 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 24 Apr 2014 09:21:32 +0300
Subject: [PATCHv2 0/3] ath10k: improve recovery speed
In-Reply-To: <1397460146-19450-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Mon, 14 Apr 2014 09:22:23 +0200")
References: <1397038028-7665-1-git-send-email-michal.kazior@tieto.com>
 <1397460146-19450-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <871twnnt77.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> Hi,
>
> Patch 1/3 is just a cleanup I wanted to keep
> separate from 2/3 which actually improves recovery
> speed.
>
> With this I'm able to recover from a `hard`
> simualtion crash in ~3 seconds instead of ~10.
>
> This should decrease the chance of CQM kicking in
> on connected clients (due to beacon loss) when
> ath10k is acting as AP.
>
> v2:
>  * add a comment in the code
>
>
> Michal Kazior (3):
>   ath10k: differentiate between target init failures
>   ath10k: don't wait for device init if it crashed
>   ath10k: skip suspending when recovering

Thanks, all patches applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr 23 23:23:32 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 24 Apr 2014 09:23:32 +0300
Subject: [PATCHv2 0/4] ath10k: AP-related fixes
In-Reply-To: <1397460010-19153-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Mon, 14 Apr 2014 09:20:06 +0200")
References: <1397037685-7485-1-git-send-email-michal.kazior@tieto.com>
 <1397460010-19153-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87wqefmejf.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> Hi,
>
> This is a bunch of fixes I've found while
> investigating tx credit issues.
>
> I've only experienced problem fixed by 4/4
> firsthand. Other patches are preemptive fixes :-)
>
> v2:
>  * minor tweaks
>
> Michal Kazior (4):
>   ath10k: make sure to not leak beacon dma mapping
>   ath10k: make sure to not use invalid beacon pointer
>   ath10k: prevent beacon memory leak
>   ath10k: fix firmware recovery with ap interface

Thanks, all patches applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr 23 23:35:20 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 24 Apr 2014 09:35:20 +0300
Subject: Report Firmware  firmware-2.bin_10.1.467.2-1 Error
In-Reply-To: <EE97821C81277E459BEA5C6384C6F241012F06CC483A@srvexch01.SODIELEC.local>
 (Vu Hai NGUYEN's message of "Wed, 16 Apr 2014 13:51:04 +0200")
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
 <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>
 <8738hgfi1k.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4838@srvexch01.SODIELEC.local>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4839@srvexch01.SODIELEC.local>
 <87eh0yetyx.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC483A@srvexch01.SODIELEC.local>
Message-ID: <87sip3mdzr.fsf@kamboji.qca.qualcomm.com>

Vu Hai NGUYEN <vh.nguyen at actiasodielec.fr> writes:

> There's another problem: when I used the firmware version 999.999 some
> times when I ran my program and change the parameter of configuration,
> the firmware crash and I got a output dmesg which indicate a strange
> version of firmware (1.0.0.636 ???) :
>
> ath10k: firmware crashed!                                                       
> ath10k: hardware name qca988x hw2.0 version 0x4100016c                          
> ath10k: firmware version: 1.0.0.636 
> ath10k: target register Dump Location: 0x00401930                               
> ath10k: target Register Dump                                                    
> ath10k: [00]: 0x4100016C 0x00000000 0x0098E3A9 0x00000000                       
> ath10k: [04]: 0x00000000 0x00000000 0x00000000 0x00000000                       
> ath10k: [08]: 0x00000000 0x00000000 0x00000000 0x00000000                       
> ath10k: [12]: 0x00000000 0x00000000 0x00000000 0x00000000                       
> ath10k: [16]: 0x00000000 0x00000000 0x00000000 0x0098E3A9                       
> ath10k: [20]: 0x00000000 0x00401930 0x00000000 0x00000000                       
> ath10k: [24]: 0x00000000 0x00000000 0x00000000 0x00000000                       
> ath10k: [28]: 0x00000000 0x00000000 0x00000000 0x00000000                       
> ath10k: [32]: 0x00000000 0x00000000 0x00000000 0x00000000                       
> ath10k: [36]: 0x00000000 0x00000000 0x00000000 0x00000000                       
> ath10k: [40]: 0x00000000 0x00000000 0x00000000 0x00000000                       
> ath10k: [44]: 0x00000000 0x00000000 0x00000000 0x00000000                       
> ath10k: [48]: 0x00000000 0x00000000 0x00000000 0x00000000                       
> ath10k: [52]: 0x00000000 0x00000000 0x00000000 0x00000000                       
> ath10k: [56]: 0x00000000 0x00000000 0x00000000 0x00000000    
>
> and then It reload the firmware 999.999.  :
>
> ath10k: firmware 999.999.0.636 booted
>
> You can see the output of my dmesg 

The patch below should fix it. I suspect you don't have that.

commit 5ba88b395cb447af756d12411456024d65a07814
Author: Chun-Yeow Yeoh <yeohchunyeow at gmail.com>
Date:   Tue Jan 21 17:21:21 2014 +0800

    ath10k: fix the printing of 10.x FW version when FW crashed
    
    10.x FW has no structure member sw_version_1. Thus,
    both fw_version_release and fw_version_build are not
    available. The provided fw_version_major is also wrong.
    Fix this by using the fw_version from struct wiphy.
    
    Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow at gmail.com>
    Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>


-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr 23 23:44:49 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 24 Apr 2014 09:44:49 +0300
Subject: Running throughput tests
In-Reply-To: <5352D327.7060106@intec.ugent.be> (Bart Jooris's message of "Sat, 
 19 Apr 2014 21:48:55 +0200")
References: <00ea01cee403$5331f1e0$f995d5a0$@sparklan.com>
 <006301cefa3c$44c07b50$ce4171f0$@sparklan.com>
 <52AEC26B.2060400@intec.ugent.be>
 <007f01cefa41$8a940de0$9fbc29a0$@sparklan.com>
 <52AEE61F.5030505@intec.ugent.be>
 <006b01cefacb$6c0b2d60$44218820$@sparklan.com>
 <52B00B10.3050300@intec.ugent.be>
 <004b01cefb9d$04a543e0$0defcba0$@sparklan.com>
 <52B2AE75.9050206@intec.ugent.be>
 <00df01cf0090$05944f10$10bced30$@sparklan.com>
 <52B9672E.9000701@intec.ugent.be>
 <008c01cf012e$e59563d0$b0c02b70$@sparklan.com>
 <530A64E5.2040401@intec.ugent.be> <530B0670.1010009@stackframe.org>
 <530E5EF2.8070800@intec.ugent.be>
 <87y50weecb.fsf_-_@kamboji.qca.qualcomm.com>
 <5335910B.3000702@intec.ugent.be>
 <87y4zutk4i.fsf@kamboji.qca.qualcomm.com>
 <53372210.7060903@intec.ugent.be>
 <871tx8m1qs.fsf@kamboji.qca.qualcomm.com>
 <5352D327.7060106@intec.ugent.be>
Message-ID: <87lhuvmdjy.fsf@kamboji.qca.qualcomm.com>

Bart Jooris <bart.jooris at gmail.com> writes:

> I also have a stable 500Mbps ++ link now :-) with peaks up to 520Mbps
> (measured with iperf UDP).
> I've  made a second AP and STA with the WLE900VX cards I've exchanged
> with Ben (Thanks again!).

Good!

> p.s. The configuration with the sparkLAN WPEA-351AC cards still
> doesn't give the same results. Probably my bad, I will double check it
> again.

This is CUS223 based design, right? If you see the problem still try to
get debug logs. For example, debug_mask=0x432 might give some hints.

-- 
Kalle Valo


From yeohchunyeow at gmail.com  Thu Apr 24 01:14:10 2014
From: yeohchunyeow at gmail.com (Chun-Yeow Yeoh)
Date: Thu, 24 Apr 2014 16:14:10 +0800
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
Message-ID: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>

Firmware 999.999.0.636 does not allow stand alone monitor
mode. This means that bridging the STA mode and put it into
promiscuous mode will also cause the firmware to crash. Avoid
this.

Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow at gmail.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e2c01dc..f640328 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -647,10 +647,15 @@ static int ath10k_monitor_vdev_delete(struct ath10k *ar)
 
 static int ath10k_monitor_start(struct ath10k *ar)
 {
-	int ret;
+	int ret = -1;
 
 	lockdep_assert_held(&ar->conf_mutex);
 
+	if (ar->fw_version_build == 636) {
+		ath10k_warn("stand alone monitor mode is not supported\n");
+		return ret;
+	}
+
 	if (!ath10k_monitor_is_enabled(ar)) {
 		ath10k_warn("trying to start monitor with no references\n");
 		return 0;
-- 
1.9.2



From kvalo at qca.qualcomm.com  Thu Apr 24 01:22:39 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 24 Apr 2014 11:22:39 +0300
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
In-Reply-To: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
 (Chun-Yeow Yeoh's message of "Thu, 24 Apr 2014 16:14:10 +0800")
References: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
Message-ID: <87d2g7m90w.fsf@kamboji.qca.qualcomm.com>

Chun-Yeow Yeoh <yeohchunyeow at gmail.com> writes:

> Firmware 999.999.0.636 does not allow stand alone monitor
> mode. This means that bridging the STA mode and put it into
> promiscuous mode will also cause the firmware to crash. Avoid
> this.
>
> Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow at gmail.com>

[...]

> @@ -647,10 +647,15 @@ static int ath10k_monitor_vdev_delete(struct ath10k *ar)
>  
>  static int ath10k_monitor_start(struct ath10k *ar)
>  {
> -	int ret;
> +	int ret = -1;

I prefer to avoid initialising ret variables. And -1 is not a proper
error value.

>  	lockdep_assert_held(&ar->conf_mutex);
>  
> +	if (ar->fw_version_build == 636) {

Checking for firmware version in ath10k is a big no. For a functinality
change like this you should add a new feature flag to enum
ath10k_fw_features (and I need to then recreate the firmware image).

> +		ath10k_warn("stand alone monitor mode is not supported\n");

I would prefer not to print a warning for a situation like this. Can't
we instead return an error value back to the caller?

> +		return ret;

return -EOPNOTSUPP or similar is better approach than initialising ret
to -1.

-- 
Kalle Valo


From yeohchunyeow at gmail.com  Thu Apr 24 01:40:24 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 24 Apr 2014 16:40:24 +0800
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
In-Reply-To: <87d2g7m90w.fsf@kamboji.qca.qualcomm.com>
References: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
 <87d2g7m90w.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CAEFj986h0FtMOpbTbYYQzLxZrEcL_og0+qpQkfj36xMWM9LG5g@mail.gmail.com>

On Thu, Apr 24, 2014 at 4:22 PM, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Chun-Yeow Yeoh <yeohchunyeow at gmail.com> writes:
>
>> Firmware 999.999.0.636 does not allow stand alone monitor
>> mode. This means that bridging the STA mode and put it into
>> promiscuous mode will also cause the firmware to crash. Avoid
>> this.
>>
>> Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow at gmail.com>
>
> [...]
>
>> @@ -647,10 +647,15 @@ static int ath10k_monitor_vdev_delete(struct ath10k *ar)
>>
>>  static int ath10k_monitor_start(struct ath10k *ar)
>>  {
>> -     int ret;
>> +     int ret = -1;
>
> I prefer to avoid initialising ret variables. And -1 is not a proper
> error value.
>
Ok.

>>       lockdep_assert_held(&ar->conf_mutex);
>>
>> +     if (ar->fw_version_build == 636) {
>
> Checking for firmware version in ath10k is a big no. For a functinality
> change like this you should add a new feature flag to enum
> ath10k_fw_features (and I need to then recreate the firmware image).
>
Should we just use the ATH10K_FW_FEATURE_WMI_10X?

>> +             ath10k_warn("stand alone monitor mode is not supported\n");
>
> I would prefer not to print a warning for a situation like this. Can't
> we instead return an error value back to the caller?
>
Yes.

>> +             return ret;
>
> return -EOPNOTSUPP or similar is better approach than initialising ret
> to -1.
Sure.

----
Chun-Yeow


From michal.kazior at tieto.com  Thu Apr 24 01:44:22 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 24 Apr 2014 10:44:22 +0200
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
In-Reply-To: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
References: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
Message-ID: <CA+BoTQkBCGyKYDaOMgdCi4Yw+SXeuRS+t0rGE8o=8+x2q5N74w@mail.gmail.com>

On 24 April 2014 10:14, Chun-Yeow Yeoh <yeohchunyeow at gmail.com> wrote:
> Firmware 999.999.0.636 does not allow stand alone monitor
> mode. This means that bridging the STA mode and put it into
> promiscuous mode will also cause the firmware to crash. Avoid
> this.
>
> Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow at gmail.com>
> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index e2c01dc..f640328 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -647,10 +647,15 @@ static int ath10k_monitor_vdev_delete(struct ath10k *ar)
>
>  static int ath10k_monitor_start(struct ath10k *ar)
>  {
> -       int ret;
> +       int ret = -1;
>
>         lockdep_assert_held(&ar->conf_mutex);
>
> +       if (ar->fw_version_build == 636) {
> +               ath10k_warn("stand alone monitor mode is not supported\n");
> +               return ret;
> +       }

I think Monitor operation should be performed on a best effort basis.
This means monitor_start/stop should be attempted once number of
non-monitor vdevs changes.

We should probably introduce a ath10k_recalc_monitor() for that purpose.


Micha?


From kvalo at qca.qualcomm.com  Thu Apr 24 01:45:24 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 24 Apr 2014 11:45:24 +0300
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
In-Reply-To: <CAEFj986h0FtMOpbTbYYQzLxZrEcL_og0+qpQkfj36xMWM9LG5g@mail.gmail.com>
 (Yeoh Chun-Yeow's message of "Thu, 24 Apr 2014 16:40:24 +0800")
References: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
 <87d2g7m90w.fsf@kamboji.qca.qualcomm.com>
 <CAEFj986h0FtMOpbTbYYQzLxZrEcL_og0+qpQkfj36xMWM9LG5g@mail.gmail.com>
Message-ID: <878uqvm7yz.fsf@kamboji.qca.qualcomm.com>

Yeoh Chun-Yeow <yeohchunyeow at gmail.com> writes:

>>> +     if (ar->fw_version_build == 636) {
>>
>> Checking for firmware version in ath10k is a big no. For a functinality
>> change like this you should add a new feature flag to enum
>> ath10k_fw_features (and I need to then recreate the firmware image).
>>
> Should we just use the ATH10K_FW_FEATURE_WMI_10X?

That's a bit dangerous if in the future there's a new firmware which
doesn't have ATH10K_FW_FEATURE_WMI_10X but still doesn't support stand
alone monitor mode.

-- 
Kalle Valo


From yeohchunyeow at gmail.com  Thu Apr 24 01:50:15 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 24 Apr 2014 16:50:15 +0800
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
In-Reply-To: <CA+BoTQkBCGyKYDaOMgdCi4Yw+SXeuRS+t0rGE8o=8+x2q5N74w@mail.gmail.com>
References: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
 <CA+BoTQkBCGyKYDaOMgdCi4Yw+SXeuRS+t0rGE8o=8+x2q5N74w@mail.gmail.com>
Message-ID: <CAEFj986fsmUD2kvEN=vjHK32cunyFO+8bH-y7ZoWZAMkcunJ2w@mail.gmail.com>

> I think Monitor operation should be performed on a best effort basis.
> This means monitor_start/stop should be attempted once number of
> non-monitor vdevs changes.

I am too clear about this. Do you mean that actually we can have
monitor mode on non-monitor vdevs in firmware 636?

----
Chun-Yeow


From johannes at sipsolutions.net  Thu Apr 24 01:50:15 2014
From: johannes at sipsolutions.net (Johannes Berg)
Date: Thu, 24 Apr 2014 10:50:15 +0200
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
In-Reply-To: <CA+BoTQkBCGyKYDaOMgdCi4Yw+SXeuRS+t0rGE8o=8+x2q5N74w@mail.gmail.com>
 (sfid-20140424_104431_792919_3603D338)
References: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
 <CA+BoTQkBCGyKYDaOMgdCi4Yw+SXeuRS+t0rGE8o=8+x2q5N74w@mail.gmail.com>
 (sfid-20140424_104431_792919_3603D338)
Message-ID: <1398329415.4154.1.camel@jlt4.sipsolutions.net>

On Thu, 2014-04-24 at 10:44 +0200, Michal Kazior wrote:

> I think Monitor operation should be performed on a best effort basis.
> This means monitor_start/stop should be attempted once number of
> non-monitor vdevs changes.
> 
> We should probably introduce a ath10k_recalc_monitor() for that purpose.

Doesn't mac80211 do that for you?

See IEEE80211_HW_WANT_MONITOR_VIF.

johannes



From michal.kazior at tieto.com  Thu Apr 24 01:53:24 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 24 Apr 2014 10:53:24 +0200
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
In-Reply-To: <CAEFj986fsmUD2kvEN=vjHK32cunyFO+8bH-y7ZoWZAMkcunJ2w@mail.gmail.com>
References: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
 <CA+BoTQkBCGyKYDaOMgdCi4Yw+SXeuRS+t0rGE8o=8+x2q5N74w@mail.gmail.com>
 <CAEFj986fsmUD2kvEN=vjHK32cunyFO+8bH-y7ZoWZAMkcunJ2w@mail.gmail.com>
Message-ID: <CA+BoTQ=uvkjK-BYJL3gympEiraZupLdh67XzMjuGviQ4iaVuiw@mail.gmail.com>

On 24 April 2014 10:50, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
>> I think Monitor operation should be performed on a best effort basis.
>> This means monitor_start/stop should be attempted once number of
>> non-monitor vdevs changes.
>
> I am too clear about this. Do you mean that actually we can have
> monitor mode on non-monitor vdevs in firmware 636?

No. What I mean is we should attempt to start monitor vdev once at
least 1 non-monitor vdev is present and stop monitor vdev is last
non-monitor vdev is about to be stopped on 636.


Micha?


From michal.kazior at tieto.com  Thu Apr 24 02:04:22 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 24 Apr 2014 11:04:22 +0200
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
In-Reply-To: <1398329415.4154.1.camel@jlt4.sipsolutions.net>
References: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
 <CA+BoTQkBCGyKYDaOMgdCi4Yw+SXeuRS+t0rGE8o=8+x2q5N74w@mail.gmail.com>
 <1398329415.4154.1.camel@jlt4.sipsolutions.net>
Message-ID: <CA+BoTQkutgixefexBRcTcDBrWpXCy0YFzdDuoY1PdHc3J1Hejw@mail.gmail.com>

On 24 April 2014 10:50, Johannes Berg <johannes at sipsolutions.net> wrote:
> On Thu, 2014-04-24 at 10:44 +0200, Michal Kazior wrote:
>
>> I think Monitor operation should be performed on a best effort basis.
>> This means monitor_start/stop should be attempted once number of
>> non-monitor vdevs changes.
>>
>> We should probably introduce a ath10k_recalc_monitor() for that purpose.
>
> Doesn't mac80211 do that for you?
>
> See IEEE80211_HW_WANT_MONITOR_VIF.

This is not sufficient in this case.

E.g. If you add a disconnected 4addr sta interface to bridge the
interface enters promisc mode. This attempts to start monitor vdev in
ath10k before sta vdev is started internally. We could probably make
it start earlier (in add_interface) but there still remains a problem
when you stop last non-monitor interface (monitor vif will be created
_after_ last non-monitor is removed which is too late).


Micha?


From vh.nguyen at actiasodielec.fr  Thu Apr 24 02:03:02 2014
From: vh.nguyen at actiasodielec.fr (Vu Hai NGUYEN)
Date: Thu, 24 Apr 2014 11:03:02 +0200
Subject: Report Firmware  firmware-2.bin_10.1.467.2-1 Error
In-Reply-To: <87sip3mdzr.fsf@kamboji.qca.qualcomm.com>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
 <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>
 <8738hgfi1k.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4838@srvexch01.SODIELEC.local>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4839@srvexch01.SODIELEC.local>
 <87eh0yetyx.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC483A@srvexch01.SODIELEC.local>,
 <87sip3mdzr.fsf@kamboji.qca.qualcomm.com>
Message-ID: <EE97821C81277E459BEA5C6384C6F241012F0EFBBCB0@srvexch01.SODIELEC.local>

Thank you for your response, the problem is solved when I download the latest version of backport (3.15) and compile ath10k with it (last time my version is 3.13 and as you said, It might not include the patch).
Now I can load the firmware 10.1.467.2-1 but I get new problem too.
Does ath10k support all the command of "iw"?
For example I set up mode access point and tried to change the txpower by the command: "iw wlan0 set txpower fixed 1200" (same thing as "iwconfig wlan0 txpower 12dBm" , right?)
The output of "iwconfig" is:
wlan0     IEEE 802.11abgn  Mode:Master  Tx-Power=12 dBm                         
          Retry short limit:7   RTS thr:off   Fragment thr:off                  
          Power Management:on  

And output of "dmesg":
ath10k: mac config power 12                                                     
ath10k: wmi pdev set param 3 value 24                                           
ath10k: wmi pdev set param 4 value 24 

It seems that the command arrives until the level of driver ath10k and works but when I verified by connecting a station to my access point and look at the out put of "iw wlan0 station dump", the value of txpower received at the station didn't change even when I changed the txpower of my access point from 1dBm to 20dBm (my station is near the access point).

Same thing when I do with the command set bit rates: "iw wlan0 set bitrates legacy-2.4 54 ht-mcs-2.4"

Out put of dmesg:
ath10k: mac fixed rate pream 0x00 nss 0x00 rate 0x04                            
ath10k: wmi vdev id 0x0 set param 27 value 4                                    
ath10k: wmi vdev id 0x0 set param 34 value 1                                    
ath10k: wmi vdev id 0x0 set param 28 value 0                                    
ath10k: wmi event debug mesg len 16  

But the out put of " iw wlan0 station dump" did not show any change when I varied the bit rate of my access point too. 

Do you guys have any suggestion about it?
Thanks in advance :)

NGUYEN Vu Hai
Acita-Sodielec
Route de Mayres - B.P. 9
12100 St GEORGES DE LUZENCON
FRANCE

________________________________________
De : Kalle Valo [kvalo at qca.qualcomm.com]
Date d'envoi : jeudi 24 avril 2014 08:35
? : Vu Hai NGUYEN
Cc : ath10k at lists.infradead.org; Patrick CARNEIRO RODRIGUEZ
Objet : Re: RE : Report Firmware  firmware-2.bin_10.1.467.2-1 Error

Vu Hai NGUYEN <vh.nguyen at actiasodielec.fr> writes:

> There's another problem: when I used the firmware version 999.999 some
> times when I ran my program and change the parameter of configuration,
> the firmware crash and I got a output dmesg which indicate a strange
> version of firmware (1.0.0.636 ???) :
>
> ath10k: firmware crashed!
> ath10k: hardware name qca988x hw2.0 version 0x4100016c
> ath10k: firmware version: 1.0.0.636
> ath10k: target register Dump Location: 0x00401930
> ath10k: target Register Dump
> ath10k: [00]: 0x4100016C 0x00000000 0x0098E3A9 0x00000000
> ath10k: [04]: 0x00000000 0x00000000 0x00000000 0x00000000
> ath10k: [08]: 0x00000000 0x00000000 0x00000000 0x00000000
> ath10k: [12]: 0x00000000 0x00000000 0x00000000 0x00000000
> ath10k: [16]: 0x00000000 0x00000000 0x00000000 0x0098E3A9
> ath10k: [20]: 0x00000000 0x00401930 0x00000000 0x00000000
> ath10k: [24]: 0x00000000 0x00000000 0x00000000 0x00000000
> ath10k: [28]: 0x00000000 0x00000000 0x00000000 0x00000000
> ath10k: [32]: 0x00000000 0x00000000 0x00000000 0x00000000
> ath10k: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
> ath10k: [40]: 0x00000000 0x00000000 0x00000000 0x00000000
> ath10k: [44]: 0x00000000 0x00000000 0x00000000 0x00000000
> ath10k: [48]: 0x00000000 0x00000000 0x00000000 0x00000000
> ath10k: [52]: 0x00000000 0x00000000 0x00000000 0x00000000
> ath10k: [56]: 0x00000000 0x00000000 0x00000000 0x00000000
>
> and then It reload the firmware 999.999.  :
>
> ath10k: firmware 999.999.0.636 booted
>
> You can see the output of my dmesg

The patch below should fix it. I suspect you don't have that.

commit 5ba88b395cb447af756d12411456024d65a07814
Author: Chun-Yeow Yeoh <yeohchunyeow at gmail.com>
Date:   Tue Jan 21 17:21:21 2014 +0800

    ath10k: fix the printing of 10.x FW version when FW crashed

    10.x FW has no structure member sw_version_1. Thus,
    both fw_version_release and fw_version_build are not
    available. The provided fw_version_major is also wrong.
    Fix this by using the fw_version from struct wiphy.

    Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow at gmail.com>
    Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>


--
Kalle Valo


From yeohchunyeow at gmail.com  Thu Apr 24 02:09:25 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 24 Apr 2014 17:09:25 +0800
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
In-Reply-To: <CA+BoTQ=uvkjK-BYJL3gympEiraZupLdh67XzMjuGviQ4iaVuiw@mail.gmail.com>
References: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
 <CA+BoTQkBCGyKYDaOMgdCi4Yw+SXeuRS+t0rGE8o=8+x2q5N74w@mail.gmail.com>
 <CAEFj986fsmUD2kvEN=vjHK32cunyFO+8bH-y7ZoWZAMkcunJ2w@mail.gmail.com>
 <CA+BoTQ=uvkjK-BYJL3gympEiraZupLdh67XzMjuGviQ4iaVuiw@mail.gmail.com>
Message-ID: <CAEFj987CE+RLxLXFhKyvKEWB6PK-Dd7Rnq98th+w1hBJoy48Pg@mail.gmail.com>

On Thu, Apr 24, 2014 at 4:53 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 24 April 2014 10:50, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
>>> I think Monitor operation should be performed on a best effort basis.
>>> This means monitor_start/stop should be attempted once number of
>>> non-monitor vdevs changes.
>>
>> I am too clear about this. Do you mean that actually we can have
>> monitor mode on non-monitor vdevs in firmware 636?
>
> No. What I mean is we should attempt to start monitor vdev once at
> least 1 non-monitor vdev is present and stop monitor vdev is last
> non-monitor vdev is about to be stopped on 636.
>

Got it. But my investigation on firmware 636 shows that the firmware
crashes even though 1 non-monitor vdev is present. So can we conclude
actually monitor mode is not allowed in firmware 636.

---
Chun-Yeow


From yeohchunyeow at gmail.com  Thu Apr 24 02:19:10 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 24 Apr 2014 17:19:10 +0800
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
In-Reply-To: <878uqvm7yz.fsf@kamboji.qca.qualcomm.com>
References: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
 <87d2g7m90w.fsf@kamboji.qca.qualcomm.com>
 <CAEFj986h0FtMOpbTbYYQzLxZrEcL_og0+qpQkfj36xMWM9LG5g@mail.gmail.com>
 <878uqvm7yz.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CAEFj986VVHkgSnv=xGo_WAYg+n4Sp0_qJGkpmzjNk9thoizZCA@mail.gmail.com>

On Thu, Apr 24, 2014 at 4:45 PM, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Yeoh Chun-Yeow <yeohchunyeow at gmail.com> writes:
>
>>>> +     if (ar->fw_version_build == 636) {
>>>
>>> Checking for firmware version in ath10k is a big no. For a functinality
>>> change like this you should add a new feature flag to enum
>>> ath10k_fw_features (and I need to then recreate the firmware image).
>>>
>> Should we just use the ATH10K_FW_FEATURE_WMI_10X?
>
> That's a bit dangerous if in the future there's a new firmware which
> doesn't have ATH10K_FW_FEATURE_WMI_10X but still doesn't support stand
> alone monitor mode.
>

Then, we may need to introduce the new feature flag.

But then I just wondering if the firmware 636 claimed to support STA
mode "well" but then not allowed to be bridged. This may cause
confusion to end user which is the best firmware for STA mode. FYI, AP
firmware has no such issue if using as STA mode and put into
promiscuous mode.

----
Chun-Yeow


From michal.kazior at tieto.com  Thu Apr 24 02:41:34 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 24 Apr 2014 11:41:34 +0200
Subject: Report Firmware firmware-2.bin_10.1.467.2-1 Error
In-Reply-To: <EE97821C81277E459BEA5C6384C6F241012F0EFBBCB0@srvexch01.SODIELEC.local>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
 <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>
 <8738hgfi1k.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4838@srvexch01.SODIELEC.local>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4839@srvexch01.SODIELEC.local>
 <87eh0yetyx.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC483A@srvexch01.SODIELEC.local>
 <87sip3mdzr.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F0EFBBCB0@srvexch01.SODIELEC.local>
Message-ID: <CA+BoTQkChYC+sTy4MSFCbGDvNoGHRko=Oxbkj=hVy+EQ4LP1Gg@mail.gmail.com>

On 24 April 2014 11:03, Vu Hai NGUYEN <vh.nguyen at actiasodielec.fr> wrote:
> Thank you for your response, the problem is solved when I download the latest version of backport (3.15) and compile ath10k with it (last time my version is 3.13 and as you said, It might not include the patch).
> Now I can load the firmware 10.1.467.2-1 but I get new problem too.
> Does ath10k support all the command of "iw"?
> For example I set up mode access point and tried to change the txpower by the command: "iw wlan0 set txpower fixed 1200" (same thing as "iwconfig wlan0 txpower 12dBm" , right?)
> The output of "iwconfig" is:
> wlan0     IEEE 802.11abgn  Mode:Master  Tx-Power=12 dBm
>           Retry short limit:7   RTS thr:off   Fragment thr:off
>           Power Management:on
>
> And output of "dmesg":
> ath10k: mac config power 12
> ath10k: wmi pdev set param 3 value 24
> ath10k: wmi pdev set param 4 value 24
>
> It seems that the command arrives until the level of driver ath10k and works but when I verified by connecting a station to my access point and look at the out put of "iw wlan0 station dump", the value of txpower received at the station didn't change even when I changed the txpower of my access point from 1dBm to 20dBm (my station is near the access point).

This works for me (latest github.com/kvalo/ath/master with 467.2).

I can see "signal" values change in iw station dump on the connected
client when I set different txpower values on ath10k AP.


> Same thing when I do with the command set bit rates: "iw wlan0 set bitrates legacy-2.4 54 ht-mcs-2.4"
>
> Out put of dmesg:
> ath10k: mac fixed rate pream 0x00 nss 0x00 rate 0x04
> ath10k: wmi vdev id 0x0 set param 27 value 4
> ath10k: wmi vdev id 0x0 set param 34 value 1
> ath10k: wmi vdev id 0x0 set param 28 value 0
> ath10k: wmi event debug mesg len 16
>
> But the out put of " iw wlan0 station dump" did not show any change when I varied the bit rate of my access point too.

Again, this works for me.

To be clear - ath10k is incapable of reporting "tx bitrate" (it always
reports 6mbps). If you want to verify if the bitrate mask works you
must check "rx bitrate" on the other side, i.e. on the connected
client.

Or just use a separate sniffer and see if AP is sends frames with
different txpower/bitrate values.


Micha?


From kvalo at qca.qualcomm.com  Thu Apr 24 02:46:36 2014
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 24 Apr 2014 12:46:36 +0300
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
In-Reply-To: <CAEFj986VVHkgSnv=xGo_WAYg+n4Sp0_qJGkpmzjNk9thoizZCA@mail.gmail.com>
 (Yeoh Chun-Yeow's message of "Thu, 24 Apr 2014 17:19:10 +0800")
References: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
 <87d2g7m90w.fsf@kamboji.qca.qualcomm.com>
 <CAEFj986h0FtMOpbTbYYQzLxZrEcL_og0+qpQkfj36xMWM9LG5g@mail.gmail.com>
 <878uqvm7yz.fsf@kamboji.qca.qualcomm.com>
 <CAEFj986VVHkgSnv=xGo_WAYg+n4Sp0_qJGkpmzjNk9thoizZCA@mail.gmail.com>
Message-ID: <874n1jm54z.fsf@kamboji.qca.qualcomm.com>

Yeoh Chun-Yeow <yeohchunyeow at gmail.com> writes:

> On Thu, Apr 24, 2014 at 4:45 PM, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>> Yeoh Chun-Yeow <yeohchunyeow at gmail.com> writes:
>>
>>>>> +     if (ar->fw_version_build == 636) {
>>>>
>>>> Checking for firmware version in ath10k is a big no. For a functinality
>>>> change like this you should add a new feature flag to enum
>>>> ath10k_fw_features (and I need to then recreate the firmware image).
>>>>
>>> Should we just use the ATH10K_FW_FEATURE_WMI_10X?
>>
>> That's a bit dangerous if in the future there's a new firmware which
>> doesn't have ATH10K_FW_FEATURE_WMI_10X but still doesn't support stand
>> alone monitor mode.
>
> Then, we may need to introduce the new feature flag.

And that will create other problems. It's better to bite the bullet now
than trying to postpone it. Besides, adding the feature flag is trivial.

> But then I just wondering if the firmware 636 claimed to support STA
> mode "well" but then not allowed to be bridged. This may cause
> confusion to end user which is the best firmware for STA mode. FYI, AP
> firmware has no such issue if using as STA mode and put into
> promiscuous mode.

Yeah, maybe should change the documentation to recommend using 10.1
branch for AP, STA and monitor modes? And recommended main branch only
for Ad-Hoc and P2P?

-- 
Kalle Valo


From yeohchunyeow at gmail.com  Thu Apr 24 03:14:19 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 24 Apr 2014 18:14:19 +0800
Subject: [PATCH] ath10k: don't allow stand alone monitor mode for non-AP
 firmware
In-Reply-To: <874n1jm54z.fsf@kamboji.qca.qualcomm.com>
References: <1398327250-12923-1-git-send-email-yeohchunyeow@gmail.com>
 <87d2g7m90w.fsf@kamboji.qca.qualcomm.com>
 <CAEFj986h0FtMOpbTbYYQzLxZrEcL_og0+qpQkfj36xMWM9LG5g@mail.gmail.com>
 <878uqvm7yz.fsf@kamboji.qca.qualcomm.com>
 <CAEFj986VVHkgSnv=xGo_WAYg+n4Sp0_qJGkpmzjNk9thoizZCA@mail.gmail.com>
 <874n1jm54z.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CAEFj986mx-9UsV=PapWYmJf_vgkxAZowq9CbtguVHpKw-Er8cg@mail.gmail.com>

>
> Yeah, maybe should change the documentation to recommend using 10.1
> branch for AP, STA and monitor modes? And recommended main branch only
> for Ad-Hoc and P2P?
>
Eventually, we need a single firmware that can support all the modes,
including mesh.

For the 10.1, it cited " STA specific features might not work". Can
someone comment what working and what not working?

----
Chun-Yeow


From yeohchunyeow at gmail.com  Thu Apr 24 03:18:21 2014
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 24 Apr 2014 18:18:21 +0800
Subject: Report Firmware firmware-2.bin_10.1.467.2-1 Error
In-Reply-To: <CA+BoTQkChYC+sTy4MSFCbGDvNoGHRko=Oxbkj=hVy+EQ4LP1Gg@mail.gmail.com>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
 <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>
 <8738hgfi1k.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4838@srvexch01.SODIELEC.local>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4839@srvexch01.SODIELEC.local>
 <87eh0yetyx.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC483A@srvexch01.SODIELEC.local>
 <87sip3mdzr.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F0EFBBCB0@srvexch01.SODIELEC.local>
 <CA+BoTQkChYC+sTy4MSFCbGDvNoGHRko=Oxbkj=hVy+EQ4LP1Gg@mail.gmail.com>
Message-ID: <CAEFj985VFPTqn5p64iv4pWFTwQUSDMA0LgsB_P2Ef2q3UeSAVg@mail.gmail.com>

> To be clear - ath10k is incapable of reporting "tx bitrate" (it always
> reports 6mbps). If you want to verify if the bitrate mask works you
> must check "rx bitrate" on the other side, i.e. on the connected
> client.
>
> Or just use a separate sniffer and see if AP is sends frames with
> different txpower/bitrate values.
>

For TxRate, another option would be looking at
"/sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats".

----
Chun-Yeow


From johannes at sipsolutions.net  Fri Apr 25 08:27:12 2014
From: johannes at sipsolutions.net (Johannes Berg)
Date: Fri, 25 Apr 2014 17:27:12 +0200
Subject: [PATCH 1/2 V3] mac80211: add option to generate CCMP IVs only
 for mgmt frames
In-Reply-To: <1397467642-23544-1-git-send-email-marek.kwaczynski@tieto.com>
 (sfid-20140414_112812_088705_2F071D07)
References: <1397467642-23544-1-git-send-email-marek.kwaczynski@tieto.com>
 (sfid-20140414_112812_088705_2F071D07)
Message-ID: <1398439632.4152.14.camel@jlt4.sipsolutions.net>

On Mon, 2014-04-14 at 11:27 +0200, Marek Kwaczynski wrote:
> Some chips can encrypt managment frames in HW, but
> require generated IV in the frame. Add a key flag
> that allows us to achieve this.

Applied.

johannes



From greearb at candelatech.com  Mon Apr 28 20:55:44 2014
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 28 Apr 2014 20:55:44 -0700
Subject: Running throughput tests
In-Reply-To: <87lhuvmdjy.fsf@kamboji.qca.qualcomm.com>
References: <00ea01cee403$5331f1e0$f995d5a0$@sparklan.com>	<006301cefa3c$44c07b50$ce4171f0$@sparklan.com>	<52AEC26B.2060400@intec.ugent.be>	<007f01cefa41$8a940de0$9fbc29a0$@sparklan.com>	<52AEE61F.5030505@intec.ugent.be>	<006b01cefacb$6c0b2d60$44218820$@sparklan.com>	<52B00B10.3050300@intec.ugent.be>	<004b01cefb9d$04a543e0$0defcba0$@sparklan.com>	<52B2AE75.9050206@intec.ugent.be>	<00df01cf0090$05944f10$10bced30$@sparklan.com>	<52B9672E.9000701@intec.ugent.be>	<008c01cf012e$e59563d0$b0c02b70$@sparklan.com>	<530A64E5.2040401@intec.ugent.be>
 <530B0670.1010009@stackframe.org>	<530E5EF2.8070800@intec.ugent.be>	<87y50weecb.fsf_-_@kamboji.qca.qualcomm.com>	<5335910B.3000702@intec.ugent.be>	<87y4zutk4i.fsf@kamboji.qca.qualcomm.com>	<53372210.7060903@intec.ugent.be>	<871tx8m1qs.fsf@kamboji.qca.qualcomm.com>	<5352D327.7060106@intec.ugent.be>
 <87lhuvmdjy.fsf@kamboji.qca.qualcomm.com>
Message-ID: <535F22C0.9000403@candelatech.com>

On 04/23/2014 11:44 PM, Kalle Valo wrote:
> Bart Jooris <bart.jooris at gmail.com> writes:
>
>> I also have a stable 500Mbps ++ link now :-) with peaks up to 520Mbps
>> (measured with iperf UDP).
>> I've  made a second AP and STA with the WLE900VX cards I've exchanged
>> with Ben (Thanks again!).
>
> Good!
>
>> p.s. The configuration with the sparkLAN WPEA-351AC cards still
>> doesn't give the same results. Probably my bad, I will double check it
>> again.
>
> This is CUS223 based design, right? If you see the problem still try to
> get debug logs. For example, debug_mask=0x432 might give some hints.
>

We tried with the Sparklan today, and it locks up the system soon after we
start hostapd, so we just removed it from the system.  The WLE900VX in same
machine and same config works fine.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Tue Apr 29 17:13:40 2014
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 29 Apr 2014 17:13:40 -0700
Subject: Vdev map issues.
Message-ID: <53604034.1030000@candelatech.com>

Possibly I've made too many local changes and gotten confused, but this code
appears like it should be doing an |= instead of &= in ath10k_add_interface?

err_vdev_delete:
	ath10k_wmi_vdev_delete(ar, arvif->vdev_id);
	ar->free_vdev_map &= ~(1LL << arvif->vdev_id);
	list_del(&arvif->list);

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From apenwarr at gmail.com  Tue Apr 29 20:03:26 2014
From: apenwarr at gmail.com (Avery Pennarun)
Date: Tue, 29 Apr 2014 23:03:26 -0400
Subject: ath10k fails to recover from simulated firmware crash in AP mode
Message-ID: <CAHqTa-31TAb=9+xyPzBVcEiipnN0_uV8mzSpEBD_sJVS1RDXZg@mail.gmail.com>

This is on a 3.2.26 kernel, mindspeed c2000 processor (ARMv7l), using
backports-v3.15-rc1 with today's kvalo/ath-next merged in (ie. commit
d9bc4b9b69 from Apr 23).

Steps:
- modprobe ath10k_pci reset_mode=1  (this hardware crashes if you cold reset it)
- start hostapd (40 MHz channel in this case)
- do not connect any clients
- echo hard >/sys/kernel/debug/ieee80211/*/ath10k/simulate_fw_crash

Expected:
- Device recovers from firmware crash

Actual:
- Suspicious messages suggesting the driver did not shut down properly
and/or the firmware did not recover using warm reset.


<6>[  117.335666] ath10k: simulating hard firmware crash
<3>[  117.335866] ath10k: firmware crashed!
<3>[  117.339767] ath10k: hardware name qca988x hw2.0 version 0x4100016c
<3>[  117.346162] ath10k: firmware version: 10.1.467.2-1
<3>[  117.352022] ath10k: target register Dump Location: 0x00401930
<3>[  117.358820] ath10k: target Register Dump
<3>[  117.362759] ath10k: [00]: 0x4100016C 0x00000000 0x0097F8D2 0x00000000
<3>[  117.369240] ath10k: [04]: 0x00000000 0x00000000 0x00000000 0x00000000
<3>[  117.375722] ath10k: [08]: 0x00000000 0x00000000 0x00000000 0x00000000
<3>[  117.382186] ath10k: [12]: 0x00000000 0x00000000 0x00000000 0x00000000
<3>[  117.388656] ath10k: [16]: 0x00000000 0x00000000 0x00000000 0x0097F8D2
<3>[  117.395126] ath10k: [20]: 0x00000000 0x00401930 0x00000000 0x00000000
<3>[  117.401589] ath10k: [24]: 0x00000000 0x00000000 0x00000000 0x00000000
<3>[  117.408055] ath10k: [28]: 0x00000000 0x00000000 0x00000000 0x00000000
<3>[  117.414523] ath10k: [32]: 0x00000000 0x00000000 0x00000000 0x00000000
<3>[  117.420987] ath10k: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
<3>[  117.427456] ath10k: [40]: 0x00000000 0x00000000 0x00000000 0x00000000
<3>[  117.433924] ath10k: [44]: 0x00000000 0x00000000 0x00000000 0x00000000
<3>[  117.440387] ath10k: [48]: 0x00000000 0x00000000 0x00000000 0x00000000
<3>[  117.446854] ath10k: [52]: 0x00000000 0x00000000 0x00000000 0x00000000
<3>[  117.453316] ath10k: [56]: 0x00000000 0x00000000 0x00000000 0x00000000
<4>[  120.453939] ath10k: failed to put down monitor vdev 1: -11
<4>[  123.453987] ath10k: failed to to request monitor vdev 1 stop: -11
<4>[  128.454241] ath10k: failed to synchronise monitor vdev 1: -110
<4>[  128.460126] ath10k: failed to stop monitor vdev: -110
<4>[  131.463251] ath10k: failed to request wmi monitor vdev 1 removal: -11
<4>[  131.469722] ath10k: failed to delete monitor vdev: -11
<6>[  132.003203] ieee80211 phy2: Hardware restart was requested
<4>[  132.263439] ath10k: device has crashed during init
<3>[  132.268259] ath10k: failed to wait for target to init: -70
<4>[  132.533086] ath10k: failed to power up target using warm reset: -70
<3>[  132.539385] ath10k: Could not init hif: -70
<3>[  136.970998] hostapd-wlan1:
<7>[  137.283716] hostapd-wlan1: nl80211: Ignore event for foreign ifindex 10
<7>[  137.393819] hostapd-wlan1: nl80211: Ignore dellink event for
foreign ifindex 10
<7>[  137.487964] hostapd-wlan1: nl80211: Ignore event for foreign ifindex 14
<7>[  137.488524] hostapd-wlan1: nl80211: Ignore event for foreign ifindex 14
<7>[  137.575623] hostapd-wlan1: nl80211: Ignore event for foreign ifindex 14
<7>[  137.613597] hostapd-wlan1: nl80211: Ignore dellink event for
foreign ifindex 14
<6>[  137.717616] br0: port 3(wlan0) entering forwarding state
<7>[  137.718248] hostapd-wlan1: nl80211: Ignore event for foreign ifindex 5
<7>[  137.718272] hostapd-wlan1: nl80211: Ignore event for foreign ifindex 5
<7>[  137.718286] hostapd-wlan1: nl80211: Ignore event for foreign ifindex 5
<7>[  144.206467] *LOG_UPLOAD_START*
<4>[  184.804735] ath10k: failed to set beacon mode for vdev 0: -108
<4>[  184.810727] ath10k: failed to recalculate rts/cts prot for vdev 0: -108
<4>[  184.817426] ath10k: failed to set preamble for vdev 0: -108
<7>[  184.823188] hostapd-wlan1: OLBC HT not detected anymore
<7>[  184.823209] hostapd-wlan1: hostapd_ht_operation_update current
operation mode=0x15
<7>[  184.823226] hostapd-wlan1: hostapd_ht_operation_update new
operation mode=0x4 changes=2
<7>[  184.823240] hostapd-wlan1: nl80211: Set beacon (beacon_set=1)
<7>[  184.823258] hostapd-wlan1: nl80211: Beacon head -
hexdump(len=69): 80 00 00 00 ff ff ff ff ff ff 00 03 07 12 22 01 00 03
07 12 22 01 00 00 00 00 00 00 00 00 00 00 64 00 01 00 00 12 41 56 45
52 59 5f 42 75 31 5f 54 65 73 74 57 69 66 69 01 08 8c 12 98 24 b0 48
60 6c 03 01 95
<7>[  184.823298] hostapd-wlan1: nl80211: Beacon tail -
hexdump(len=123): 07 0c 55 53 20 24 04 11 34 04 17 95 05 1e 2d 1a 0e
00 1b ff ff ff 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00
00 00 3d 16 95 05 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 7f 08 00 00 00 00 00 00 00 40 bf 0c b2 01 80 33 ea ff 00 00
ea ff 00 00 c0 05 01 9b 00 fc ff dd 18 00 50 f2 02 01 01 00 00 03 a4
00 00 27 a4 00 00 42 43 5d 00 62 32 2e 00
<7>[  184.823333] hostapd-wlan1: nl80211: ifindex=12
<7>[  184.823344] hostapd-wlan1: nl80211: beacon_int=100
<7>[  184.823355] hostapd-wlan1: nl80211: dtim_period=2
<7>[  184.823366] hostapd-wlan1: nl80211: ssid - hexdump_ascii(len=18):
<7>[  184.823379] hostapd-wlan1:      41 56 45 52 59 5f 42 75 31 5f 54
65 73 74 57 69   AVERY_Bu1_TestWi
<7>[  184.823393] hostapd-wlan1:      66 69
                 fi
<7>[  184.823407] hostapd-wlan1: nl80211: hidden SSID not in use
<7>[  184.823418] hostapd-wlan1: nl80211: privacy=0
<7>[  184.823429] hostapd-wlan1: nl80211: auth_algs=0x1
<7>[  184.823439] hostapd-wlan1: nl80211: wpa_version=0x0
<7>[  184.823456] hostapd-wlan1: nl80211: key_mgmt_suites=0x2
<7>[  184.823468] hostapd-wlan1: nl80211: pairwise_ciphers=0x1
<7>[  184.823480] hostapd-wlan1: nl80211: group_cipher=0x1
<7>[  184.823492] hostapd-wlan1: nl80211: beacon_ies -
hexdump(len=10): 7f 08 00 00 00 00 00 00 00 40
<7>[  184.823506] hostapd-wlan1: nl80211: proberesp_ies -
hexdump(len=10): 7f 08 00 00 00 00 00 00 00 40
<7>[  184.823521] hostapd-wlan1: nl80211: assocresp_ies -
hexdump(len=10): 7f 08 00 00 00 00 00 00 00 40


From michal.kazior at tieto.com  Tue Apr 29 23:01:33 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 30 Apr 2014 08:01:33 +0200
Subject: ath10k fails to recover from simulated firmware crash in AP mode
In-Reply-To: <CAHqTa-31TAb=9+xyPzBVcEiipnN0_uV8mzSpEBD_sJVS1RDXZg@mail.gmail.com>
References: <CAHqTa-31TAb=9+xyPzBVcEiipnN0_uV8mzSpEBD_sJVS1RDXZg@mail.gmail.com>
Message-ID: <CA+BoTQmsXMo2eJCm5A7H+xBxHhQ8t1yoNfRFF8d+7PeTOJnSJw@mail.gmail.com>

On 30 April 2014 05:03, Avery Pennarun <apenwarr at gmail.com> wrote:
> This is on a 3.2.26 kernel, mindspeed c2000 processor (ARMv7l), using
> backports-v3.15-rc1 with today's kvalo/ath-next merged in (ie. commit
> d9bc4b9b69 from Apr 23).
>
> Steps:
> - modprobe ath10k_pci reset_mode=1  (this hardware crashes if you cold reset it)

There is a reason why ath10k falls back to cold reset (unless you
forbid it to): warm reset can't recover target in all cases.


Micha?


From michal.kazior at tieto.com  Tue Apr 29 23:06:23 2014
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 30 Apr 2014 08:06:23 +0200
Subject: Vdev map issues.
In-Reply-To: <53604034.1030000@candelatech.com>
References: <53604034.1030000@candelatech.com>
Message-ID: <CA+BoTQ=hFkj7BUgzK=16-yfgLrkki3ZrpC5P0A3gaWmji07y6Q@mail.gmail.com>

On 30 April 2014 02:13, Ben Greear <greearb at candelatech.com> wrote:
> Possibly I've made too many local changes and gotten confused, but this code
> appears like it should be doing an |= instead of &= in ath10k_add_interface?
>
> err_vdev_delete:
>         ath10k_wmi_vdev_delete(ar, arvif->vdev_id);
>         ar->free_vdev_map &= ~(1LL << arvif->vdev_id);
>         list_del(&arvif->list);

Correct. Will you submit a patch?


Micha?


From vh.nguyen at actiasodielec.fr  Wed Apr 30 05:39:44 2014
From: vh.nguyen at actiasodielec.fr (Vu Hai NGUYEN)
Date: Wed, 30 Apr 2014 14:39:44 +0200
Subject: Report Firmware firmware-2.bin_10.1.467.2-1 Error
In-Reply-To: <CA+BoTQkChYC+sTy4MSFCbGDvNoGHRko=Oxbkj=hVy+EQ4LP1Gg@mail.gmail.com>
References: <53461A8A.4030209@candelatech.com>
 <1397124355-6321-1-git-send-email-michal.kazior@tieto.com>
 <8738hkh193.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQ=gUBsw43M2at0y7iZU3VhwdjH9EBqzdOmKpxLjjqusPw@mail.gmail.com>
 <CA+BoTQ=L7Cj5V04RGEFcdGm1rxEO8NOYMEhSRiQNdoBoMTm5Pg@mail.gmail.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4837@srvexch01.SODIELEC.local>
 <CA+BoTQkAv_OrJ5cM-wp_fhdb01KV62gLqkXaSikYv9pS9t25eQ@mail.gmail.com>
 <8738hgfi1k.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4838@srvexch01.SODIELEC.local>
 <EE97821C81277E459BEA5C6384C6F241012F06CC4839@srvexch01.SODIELEC.local>
 <87eh0yetyx.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F06CC483A@srvexch01.SODIELEC.local>
 <87sip3mdzr.fsf@kamboji.qca.qualcomm.com>
 <EE97821C81277E459BEA5C6384C6F241012F0EFBBCB0@srvexch01.SODIELEC.local>,
 <CA+BoTQkChYC+sTy4MSFCbGDvNoGHRko=Oxbkj=hVy+EQ4LP1Gg@mail.gmail.com>
Message-ID: <EE97821C81277E459BEA5C6384C6F241012F0EFBBCB2@srvexch01.SODIELEC.local>

>> It seems that the command arrives until the level of driver ath10k and works but when I verified by connecting a station to my access point and look at the out put of "iw wlan0 station dump", the value of txpower received at the >>station didn't change even when I changed the txpower of my access point from 1dBm to 20dBm (my station is near the access point).

>This works for me (latest github.com/kvalo/ath/master with 467.2).
>I can see "signal" values change in iw station dump on the connected
>client when I set different txpower values on ath10k AP.
 
I replace the ath from  backports with the one from master tree of ath, but it is worse. 
When I set a channel from 52 (or higher) for AP mode using the version of backports, I get a backtrace message output and then my wlan0 become ready:

br0: port 2(wlan0) entering disabled state                                      
ADDRCONF(NETDEV_UP): wlan0: link is not ready                                   
wlan0: interface------------[ cut here ]------------                            
 state UNINITIALWARNING: at /home/alberix2/Desktop/Wilinks_ath10k/ACCESS_POINT_A
PPLI/Source/Driver_ath10k/backports-3.15-rc1-1/net/wireless/nl80211.c:5824 nl802
11_start_radar_detection+0xf8/0x16c [cfg80211]()                                
IZED->COUNTRY_UPModules linked in:DATE                                          
wlan0: int ath10k_pci(O)erface state COU ath10k_core(O)NTRY_UPDATE->DFS ath(O)  
wlan0: DFS-CAC mac80211(O)-START freq=5260 cfg80211(O) chan=52 sec_cha compat(O)
n=0                                                                             
 arc4 ubifs ubi [last unloaded: compat]                                         
Backtrace:                                                                      
[<c0011938>] (dump_backtrace+0x0/0x118) from [<c050205c>] (dump_stack+0x18/0x20)
 r6:bf49a62b r5:000016c0 r4:00000000 r3:c10b27ac                                
[<c0502044>] (dump_stack+0x0/0x20) from [<c0066c38>] (warn_slowpath_common+0x54/
0x70)                                                                           
[<c0066be4>] (warn_slowpath_common+0x0/0x70) from [<c0066c78>] (warn_slowpath_nu
ll+0x24/0x2c)                                                                   
 r8:00000000 r7:00000000 r6:d2f9f000 r5:d2aa0000 r4:d2f9f3c8                    
r3:00000009                                                                     
[<c0066c54>] (warn_slowpath_null+0x0/0x2c) from [<bf45eae8>] (nl80211_start_rada
r_detection+0xf8/0x16c [cfg80211])                                              
[<bf45e9f0>] (nl80211_start_radar_detection+0x0/0x16c [cfg80211]) from [<c045348
8>] (genl_rcv_msg+0x1b4/0x1f4)                                                  
[<c04532d4>] (genl_rcv_msg+0x0/0x1f4) from [<c0452904>] (netlink_rcv_skb+0x58/0x
b8)                                                                             
[<c04528ac>] (netlink_rcv_skb+0x0/0xb8) from [<c04532c4>] (genl_rcv+0x20/0x30)  
 r6:c082f600 r5:d2a7d0e0 r4:d2a7d0e0 r3:c04532a4                                
[<c04532a4>] (genl_rcv+0x0/0x30) from [<c04522d0>] (netlink_unicast+0x224/0x2c4)
 r4:d0074400 r3:c04532a4                                                        
[<c04520ac>] (netlink_unicast+0x0/0x2c4) from [<c04526a4>] (netlink_sendmsg+0x29
0/0x320)                                                                        
[<c0452414>] (netlink_sendmsg+0x0/0x320) from [<c0428eac>] (sock_sendmsg+0x98/0x
b4)                                                                             
[<c0428e14>] (sock_sendmsg+0x0/0xb4) from [<c0429150>] (__sys_sendmsg+0x1d0/0x26
c)                                                                              
 r4:d281bf64                                                                    
[<c0428f80>] (__sys_sendmsg+0x0/0x26c) from [<c042ab30>] (sys_sendmsg+0x44/0x68)
[<c042aaec>] (sys_sendmsg+0x0/0x68) from [<c000ddc0>] (ret_fast_syscall+0x0/0x30
)                                                                               
 r6:0012d850 r5:0012d888 r4:400c8900                                            
---[ end trace c03fd18534c1267a ]---   
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready                            
br0: port 2(wlan0) entering forwarding state                                    
br0: port 2(wlan0) entering forwarding state     

But with the version from ath master tree, I always get wlan0: link is not ready (and there is no backtrace msg). 
And in both versions, the firmware usually crashed when I set a channel lower than 52 (I don't get backtrace msg in these cases):

wlan0: AP-ENABLED                                                               
ath10k: firmware crashed!                                                       
ath10k: hardware name qca988x hw2.0 version 0x4100016c                          
ath10k: firmware version: 10.1.467.2-1                                          
ath10k: target register Dump Location: 0x0040AAA4                               
ath10k: target Register Dump                                                    
ath10k: [00]: 0x4100016C 0x000015B3 0x0099F306 0x00955B31                       
ath10k: [04]: 0x0099F306 0x00060530 0x00000005 0x00000000                       
ath10k: [08]: 0x009B8164 0x004118C4 0x0043DD84 0x00400000                       
ath10k: [12]: 0x00000009 0xFFFFFFFF 0x0095808C 0x009580A2                       
ath10k: [16]: 0x00958080 0x0094085D 0x00000000 0x00000000                       
ath10k: [20]: 0x4099F306 0x0040ABB4 0x00955A00 0x00000003                       
ath10k: [24]: 0x809995A1 0x0040AC14 0x0040ACB4 0xC099F306                       
ath10k: [28]: 0x80999400 0x0040AC44 0x004343F0 0x0040ACCC                       
ath10k: [32]: 0x8098CE0E 0x0040AC64 0x004343F0 0x0040ACCC                       
ath10k: [36]: 0x809912AC 0x0040AC84 0x004343F0 0x0040ACCC                       
ath10k: [40]: 0x8099147A 0x0040ACA4 0x0041ED48 0x00434488                       
ath10k: [44]: 0x80991661 0x0040AD24 0x00000000 0x0042F2A0                       
ath10k: [48]: 0x8099081C 0x0040AD84 0x00434488 0x0042F1CC                       
ath10k: [52]: 0x809909D0 0x0040ADA4 0x00000000 0x0042D704                       
ath10k: [56]: 0x809968F1 0x0040AEC4 0x0041ED48 0x00000000                       
ath10k: suspend timed out - target pause event never came                       
ieee80211 phy0: Hardware restart was requested                                  
ath10k: device successfully recovered       

There is an ouput of my dmesg in the attached file if someone is interested in :D
One more question: The default country for regulatory domain of ath is US? 
I found that it was defined in file "regd.c" and that's why even I set my country to FR ("iw reg set FR") I was not able to set up the channel 12 and 13. (Marked as disabled in output of "iw list" so I replace CTRY_UNITED_STATES with CTRY_FRANCE and then I can get the channel 12 and 13 worked. Is this legal?

@ Chun-Yeow: 

>For TxRate, another option would be looking at
>"/sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats".

When I "cat" that file there is nothing appear (it looks like empty) (But I can view other information from others files, such as: simulate_fw_crash, fw_dbglog, htt_stats_mask, wmi_services). Do you have any idea? :D 

Thank you all of you for your support 

NGUYEN Vu Hai
Acita-Sodielec
Route de Mayres - B.P. 9
12100 St GEORGES DE LUZENCON
FRANCE

________________________________________
De : Michal Kazior [michal.kazior at tieto.com]
Date d'envoi : jeudi 24 avril 2014 11:41
? : Vu Hai NGUYEN
Cc : Kalle Valo; Patrick CARNEIRO RODRIGUEZ; ath10k at lists.infradead.org
Objet : Re: RE : RE : Report Firmware firmware-2.bin_10.1.467.2-1 Error

On 24 April 2014 11:03, Vu Hai NGUYEN <vh.nguyen at actiasodielec.fr> wrote:
> Thank you for your response, the problem is solved when I download the latest version of backport (3.15) and compile ath10k with it (last time my version is 3.13 and as you said, It might not include the patch).
> Now I can load the firmware 10.1.467.2-1 but I get new problem too.
> Does ath10k support all the command of "iw"?
> For example I set up mode access point and tried to change the txpower by the command: "iw wlan0 set txpower fixed 1200" (same thing as "iwconfig wlan0 txpower 12dBm" , right?)
> The output of "iwconfig" is:
> wlan0     IEEE 802.11abgn  Mode:Master  Tx-Power=12 dBm
>           Retry short limit:7   RTS thr:off   Fragment thr:off
>           Power Management:on
>
> And output of "dmesg":
> ath10k: mac config power 12
> ath10k: wmi pdev set param 3 value 24
> ath10k: wmi pdev set param 4 value 24
>
> It seems that the command arrives until the level of driver ath10k and works but when I verified by connecting a station to my access point and look at the out put of "iw wlan0 station dump", the value of txpower received at the station didn't change even when I changed the txpower of my access point from 1dBm to 20dBm (my station is near the access point).

This works for me (latest github.com/kvalo/ath/master with 467.2).

I can see "signal" values change in iw station dump on the connected
client when I set different txpower values on ath10k AP.


> Same thing when I do with the command set bit rates: "iw wlan0 set bitrates legacy-2.4 54 ht-mcs-2.4"
>
> Out put of dmesg:
> ath10k: mac fixed rate pream 0x00 nss 0x00 rate 0x04
> ath10k: wmi vdev id 0x0 set param 27 value 4
> ath10k: wmi vdev id 0x0 set param 34 value 1
> ath10k: wmi vdev id 0x0 set param 28 value 0
> ath10k: wmi event debug mesg len 16
>
> But the out put of " iw wlan0 station dump" did not show any change when I varied the bit rate of my access point too.

Again, this works for me.

To be clear - ath10k is incapable of reporting "tx bitrate" (it always
reports 6mbps). If you want to verify if the bitrate mask works you
must check "rx bitrate" on the other side, i.e. on the connected
client.

Or just use a separate sniffer and see if AP is sends frames with
different txpower/bitrate values.


Micha?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmesg.txt
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20140430/32c30fc9/attachment-0001.txt>

From greearb at candelatech.com  Wed Apr 30 10:06:55 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 30 Apr 2014 10:06:55 -0700
Subject: Vdev map issues.
In-Reply-To: <CA+BoTQ=hFkj7BUgzK=16-yfgLrkki3ZrpC5P0A3gaWmji07y6Q@mail.gmail.com>
References: <53604034.1030000@candelatech.com>
 <CA+BoTQ=hFkj7BUgzK=16-yfgLrkki3ZrpC5P0A3gaWmji07y6Q@mail.gmail.com>
Message-ID: <53612DAF.8070602@candelatech.com>

On 04/29/2014 11:06 PM, Michal Kazior wrote:
> On 30 April 2014 02:13, Ben Greear <greearb at candelatech.com> wrote:
>> Possibly I've made too many local changes and gotten confused, but this code
>> appears like it should be doing an |= instead of &= in ath10k_add_interface?
>>
>> err_vdev_delete:
>>         ath10k_wmi_vdev_delete(ar, arvif->vdev_id);
>>         ar->free_vdev_map &= ~(1LL << arvif->vdev_id);
>>         list_del(&arvif->list);
> 
> Correct. Will you submit a patch?

This is tangled in another patch that enables 64-bit vdev-maps,
but I will rebase and post it shortly.

Another question in the related code:  For monitor devices, we
are using bit - 1 for the monitor device ID, but we do not subtract
one when creating normal stations.  Is this on purpose?

And, instead of checking for bit == 0, why not check for
zero map before we even try the ffs call?  That should work
for __ffs64 as well, which is what I need for lots of vdevs...

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Wed Apr 30 10:21:09 2014
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 30 Apr 2014 10:21:09 -0700
Subject: Vdev map issues.
In-Reply-To: <53612DAF.8070602@candelatech.com>
References: <53604034.1030000@candelatech.com>
 <CA+BoTQ=hFkj7BUgzK=16-yfgLrkki3ZrpC5P0A3gaWmji07y6Q@mail.gmail.com>
 <53612DAF.8070602@candelatech.com>
Message-ID: <53613105.8080301@candelatech.com>

On 04/30/2014 10:06 AM, Ben Greear wrote:
> On 04/29/2014 11:06 PM, Michal Kazior wrote:
>> On 30 April 2014 02:13, Ben Greear <greearb at candelatech.com> wrote:
>>> Possibly I've made too many local changes and gotten confused, but this code
>>> appears like it should be doing an |= instead of &= in ath10k_add_interface?
>>>
>>> err_vdev_delete:
>>>         ath10k_wmi_vdev_delete(ar, arvif->vdev_id);
>>>         ar->free_vdev_map &= ~(1LL << arvif->vdev_id);
>>>         list_del(&arvif->list);
>>
>> Correct. Will you submit a patch?
> 
> This is tangled in another patch that enables 64-bit vdev-maps,
> but I will rebase and post it shortly.
> 
> Another question in the related code:  For monitor devices, we
> are using bit - 1 for the monitor device ID, but we do not subtract
> one when creating normal stations.  Is this on purpose?

Ahh, nevermind that bit - 1 question, that is a local bug I introduced I think...

Thanks,
Ben

> 
> And, instead of checking for bit == 0, why not check for
> zero map before we even try the ffs call?  That should work
> for __ffs64 as well, which is what I need for lots of vdevs...
> 
> Thanks,
> Ben
> 
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From apenwarr at gmail.com  Wed Apr 30 11:13:59 2014
From: apenwarr at gmail.com (Avery Pennarun)
Date: Wed, 30 Apr 2014 14:13:59 -0400
Subject: ath10k fails to recover from simulated firmware crash in AP mode
In-Reply-To: <CA+BoTQmsXMo2eJCm5A7H+xBxHhQ8t1yoNfRFF8d+7PeTOJnSJw@mail.gmail.com>
References: <CAHqTa-31TAb=9+xyPzBVcEiipnN0_uV8mzSpEBD_sJVS1RDXZg@mail.gmail.com>
 <CA+BoTQmsXMo2eJCm5A7H+xBxHhQ8t1yoNfRFF8d+7PeTOJnSJw@mail.gmail.com>
Message-ID: <CAHqTa-3NVDL7GjgOYc-rSGwU5qGBqtuyMt9YepgLZcJqjk_YgA@mail.gmail.com>

On Wed, Apr 30, 2014 at 2:01 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 30 April 2014 05:03, Avery Pennarun <apenwarr at gmail.com> wrote:
>> This is on a 3.2.26 kernel, mindspeed c2000 processor (ARMv7l), using
>> backports-v3.15-rc1 with today's kvalo/ath-next merged in (ie. commit
>> d9bc4b9b69 from Apr 23).
>>
>> Steps:
>> - modprobe ath10k_pci reset_mode=1  (this hardware crashes if you cold reset it)
>
> There is a reason why ath10k falls back to cold reset (unless you
> forbid it to): warm reset can't recover target in all cases.

That makes sense of course.  It's a little disappointing that even the
simulated firmware crash requires a cold reset to recover, though.
Wouldn't that be the first one the firmware developers would test?

Avery


From greearb at candelatech.com  Wed Apr 30 11:22:59 2014
From: greearb at candelatech.com (greearb at candelatech.com)
Date: Wed, 30 Apr 2014 11:22:59 -0700
Subject: [PATCH] ath10k:  improve vdev map handling.
Message-ID: <1398882179-17100-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb at candelatech.com>

Check vdev map has space before calling ffs,
fix invalid cleanup in failure to create vdev
case.

Signed-off-by: Ben Greear <greearb at candelatech.com>
---

This is compile-tested only.

 drivers/net/wireless/ath/ath10k/mac.c | 29 ++++++++++++-----------------
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e2c01dc..d461f05 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -594,14 +594,14 @@ static int ath10k_monitor_vdev_create(struct ath10k *ar)
 
 	lockdep_assert_held(&ar->conf_mutex);
 
-	bit = ffs(ar->free_vdev_map);
-	if (bit == 0) {
+	if (!ar->free_vdev_map) {
 		ath10k_warn("failed to find free vdev id for monitor vdev\n");
 		return -ENOMEM;
 	}
 
+	bit = ffs(ar->free_vdev_map);
+
 	ar->monitor_vdev_id = bit - 1;
-	ar->free_vdev_map &= ~(1 << ar->monitor_vdev_id);
 
 	ret = ath10k_wmi_vdev_create(ar, ar->monitor_vdev_id,
 				     WMI_VDEV_TYPE_MONITOR,
@@ -609,20 +609,14 @@ static int ath10k_monitor_vdev_create(struct ath10k *ar)
 	if (ret) {
 		ath10k_warn("failed to request monitor vdev %i creation: %d\n",
 			    ar->monitor_vdev_id, ret);
-		goto vdev_fail;
+		return ret;
 	}
 
+	ar->free_vdev_map &= ~(1 << ar->monitor_vdev_id);
 	ath10k_dbg(ATH10K_DBG_MAC, "mac monitor vdev %d created\n",
 		   ar->monitor_vdev_id);
 
 	return 0;
-
-vdev_fail:
-	/*
-	 * Restore the ID to the global map.
-	 */
-	ar->free_vdev_map |= 1 << (ar->monitor_vdev_id);
-	return ret;
 }
 
 static int ath10k_monitor_vdev_delete(struct ath10k *ar)
@@ -638,7 +632,7 @@ static int ath10k_monitor_vdev_delete(struct ath10k *ar)
 		return ret;
 	}
 
-	ar->free_vdev_map |= 1 << (ar->monitor_vdev_id);
+	ar->free_vdev_map |= (1 << ar->monitor_vdev_id);
 
 	ath10k_dbg(ATH10K_DBG_MAC, "mac monitor vdev %d deleted\n",
 		   ar->monitor_vdev_id);
@@ -2622,11 +2616,12 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
 	INIT_WORK(&arvif->wep_key_work, ath10k_tx_wep_key_work);
 	INIT_LIST_HEAD(&arvif->list);
 
-	bit = ffs(ar->free_vdev_map);
-	if (bit == 0) {
+	if (!ar->free_vdev_map) {
+		ath10k_warn("Free vdev map is empty, no more interfaces allowed.\n");
 		ret = -EBUSY;
 		goto err;
 	}
+	bit = ffs(ar->free_vdev_map);
 
 	arvif->vdev_id = bit - 1;
 	arvif->vdev_subtype = WMI_VDEV_SUBTYPE_NONE;
@@ -2669,7 +2664,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
 		goto err;
 	}
 
-	ar->free_vdev_map &= ~BIT(arvif->vdev_id);
+	ar->free_vdev_map &= ~(1 << arvif->vdev_id);
 	list_add(&arvif->list, &ar->arvifs);
 
 	vdev_param = ar->wmi.vdev_param->def_keyid;
@@ -2762,7 +2757,7 @@ err_peer_delete:
 
 err_vdev_delete:
 	ath10k_wmi_vdev_delete(ar, arvif->vdev_id);
-	ar->free_vdev_map &= ~BIT(arvif->vdev_id);
+	ar->free_vdev_map |= (1 << arvif->vdev_id);
 	list_del(&arvif->list);
 
 err:
@@ -2792,7 +2787,7 @@ static void ath10k_remove_interface(struct ieee80211_hw *hw,
 	}
 	spin_unlock_bh(&ar->data_lock);
 
-	ar->free_vdev_map |= 1 << (arvif->vdev_id);
+	ar->free_vdev_map |= (1 << arvif->vdev_id);
 	list_del(&arvif->list);
 
 	if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
-- 
1.7.11.7



From apenwarr at gmail.com  Wed Apr 30 12:36:06 2014
From: apenwarr at gmail.com (Avery Pennarun)
Date: Wed, 30 Apr 2014 15:36:06 -0400
Subject: ath10k firmware crash after 4 hours of heavy TCP traffic
Message-ID: <CAHqTa-1D+xrg9=BMzP-offjArA=9-XQ8LcSyun1cqPyePrBrKA@mail.gmail.com>

Can someone help me decode this firmware crash so I know where to
look?  It's possible I have more memory barrier type problems, as I
did before, but it's very hard to figure these out without the
firmware printing more helpful error messages.

Unfortunately there were no interesting messages in the kernel logs
leading up to this.  hostapd said TX_STATUS received, as usual, about
2 seconds earlier.

In this test, we had three stations connected to the ath10k AP for
about 4 hours, with heavy TCP traffic in both directions.  This is
with ath10k-stable-3.11.8.

<3>[4305.499544] : ath10k: firmware crashed!
<3>[4305.499561] : ath10k: hardware name qca988x hw2.0 version 0x4100016c
<3>[4305.499571] : ath10k: firmware version: 10.1.467.2-1
<3>[4305.500641] : ath10k: target register Dump Location: 0x0040AC94
<3>[4305.501691] : ath10k: target Register Dump
<3>[4305.501703] : ath10k: [00]: 0x4100016C 0x000015B3 0x009A7340 0x00955B31
<3>[4305.501714] : ath10k: [04]: 0x009A7340 0x00060130 0x00000020 0x00000000
<3>[4305.501725] : ath10k: [08]: 0x00411124 0x00000000 0x00415B0C 0x00000001
<3>[4305.501735] : ath10k: [12]: 0x00000009 0x00000000 0x00958360 0x0095836B
<3>[4305.501746] : ath10k: [16]: 0x00958080 0x0094085D 0x00000000 0x00000000
<3>[4305.501756] : ath10k: [20]: 0x409A7340 0x0040ADA4 0x00411388 0x0040D144
<3>[4305.501766] : ath10k: [24]: 0x809A80DE 0x0040AE04 0x0040ADEC 0xC09A7340
<3>[4305.501777] : ath10k: [28]: 0x809A7885 0x0040AE24 0x0040AE48 0x00411124
<3>[4305.501787] : ath10k: [32]: 0x809486FA 0x0040AE44 0x00000001 0x00000000
<3>[4305.501797] : ath10k: [36]: 0x80948E2C 0x0040AEA4 0x0041D728 0x00411778
<3>[4305.501807] : ath10k: [40]: 0x80942EB3 0x0040AEC4 0x0041D728 0x00000001
<3>[4305.501817] : ath10k: [44]: 0x80940F18 0x0040AF14 0x00000010 0x00403AC0
<3>[4305.501827] : ath10k: [48]: 0x80940EEA 0x0040AF44 0x00400000 0x00000000
<3>[4305.501837] : ath10k: [52]: 0x80940F31 0x0040AF64 0x00401C10 0x00400600
<3>[4305.501848] : ath10k: [56]: 0x40940024 0x0040AF84 0x004068E8 0x004068E8

Thanks!

Avery


