* [PATCH] ath10k: make monitor vdev down before stoping it
From: Marek Puzyniak @ 2013-09-24 12:06 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Marek Puzyniak
Following sequence causes FW crash:
-monitor vdev up,
-monitor vdev stop,
-monitor vdev delete.
Making monitor vdev down before stoping it works ok:
-monitor vdev up,
-monitor vdev down,
-monitor vdev stop,
-monitor vdev delete.
Signed-off-by: Marek Puzyniak <marek.puzyniak@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 51988d9..24b94c8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -567,12 +567,9 @@ static int ath10k_monitor_stop(struct ath10k *ar)
lockdep_assert_held(&ar->conf_mutex);
- /* For some reasons, ath10k_wmi_vdev_down() here couse
- * often ath10k_wmi_vdev_stop() to fail. Next we could
- * not run monitor vdev and driver reload
- * required. Don't see such problems we skip
- * ath10k_wmi_vdev_down() here.
- */
+ ret = ath10k_wmi_vdev_down(ar, ar->monitor_vdev_id);
+ if (ret)
+ ath10k_warn("Monitor vdev down failed: %d\n", ret);
ret = ath10k_wmi_vdev_stop(ar, ar->monitor_vdev_id);
if (ret)
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 12/19] wireless: Change variable type to bool
From: Kalle Valo @ 2013-09-24 10:54 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: Larry.Finger, chaoming_li, linville, linux-wireless, netdev,
linux-kernel, kernel-janitors
In-Reply-To: <1379802471-30252-12-git-send-email-peter.senna@gmail.com>
Peter Senna Tschudin <peter.senna@gmail.com> writes:
> The variable continual is only assigned the values true and false.
> Change its type to bool.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @exists@
> type T;
> identifier b;
> @@
> - T
> + bool
> b = ...;
> ... when any
> b = \(true\|false\)
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
> ---
> drivers/net/wireless/rtlwifi/efuse.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Please prefix the patch title with "rtlwifi:". We use "wireless:" for
changes to net/wireless.
--
Kalle Valo
^ permalink raw reply
* [PATCH] ath10k: replenish HTT RX buffers in a tasklet
From: Michal Kazior @ 2013-09-24 8:18 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
This starves FW RX ring buffer in case of
excessive RX. This prevents from CPU being
overwhelmed by RX indications/completions by
naturally forbiddin FW to submit more RX.
This fixes RX starvation on slow machines when
under heavy RX traffic.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
PATCHv1 (since RFC) changes:
* fix comment
* remove empty line addition
* re-order tasklet_kill() / del_timer_sync()
drivers/net/wireless/ath/ath10k/htt.h | 7 ++++++
drivers/net/wireless/ath/ath10k/htt_rx.c | 35 +++++++++++++++++++++++++++---
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index e090902..3d71041 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -19,6 +19,7 @@
#define _HTT_H_
#include <linux/bug.h>
+#include <linux/interrupt.h>
#include "htc.h"
#include "rx_desc.h"
@@ -1268,6 +1269,7 @@ struct ath10k_htt {
/* set if host-fw communication goes haywire
* used to avoid further failures */
bool rx_confused;
+ struct tasklet_struct rx_replenish_task;
};
#define RX_HTT_HDR_STATUS_LEN 64
@@ -1308,6 +1310,11 @@ struct htt_rx_desc {
#define HTT_RX_BUF_SIZE 1920
#define HTT_RX_MSDU_SIZE (HTT_RX_BUF_SIZE - (int)sizeof(struct htt_rx_desc))
+/* Refill a bunch of RX buffers for each refill round so that FW/HW can handle
+ * aggregated traffic more nicely. */
+#define ATH10K_HTT_MAX_NUM_REFILL 16
+
+
/*
* DMA_MAP expects the buffer to be an integral number of cache lines.
* Rather than checking the actual cache line size, this code makes a
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 62ea9c8..02028c6 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -178,10 +178,27 @@ static int ath10k_htt_rx_ring_fill_n(struct ath10k_htt *htt, int num)
static void ath10k_htt_rx_msdu_buff_replenish(struct ath10k_htt *htt)
{
- int ret, num_to_fill;
+ int ret, num_deficit, num_to_fill;
+ /* Refilling the whole RX ring buffer proves to be a bad idea. The
+ * reason is RX may take up significant amount of CPU cycles and starve
+ * other tasks, e.g. TX on an ethernet device while acting as a bridge
+ * with ath10k wlan interface. This ended up with very poor performance
+ * once CPU the host system was overwhelmed with RX on ath10k.
+ *
+ * By limiting the number of refills the replenishing occurs
+ * progressively. This in turns makes use of the fact tasklets are
+ * processed in FIFO order. This means actual RX processing can starve
+ * out refilling. If there's not enough buffers on RX ring FW will not
+ * report RX until it is refilled with enough buffers. This
+ * automatically balances load wrt to CPU power.
+ *
+ * This probably comes at a cost of lower maximum throughput but
+ * improves the avarage and stability. */
spin_lock_bh(&htt->rx_ring.lock);
- num_to_fill = htt->rx_ring.fill_level - htt->rx_ring.fill_cnt;
+ num_deficit = htt->rx_ring.fill_level - htt->rx_ring.fill_cnt;
+ num_to_fill = min(ATH10K_HTT_MAX_NUM_REFILL, num_deficit);
+ num_deficit -= num_to_fill;
ret = ath10k_htt_rx_ring_fill_n(htt, num_to_fill);
if (ret == -ENOMEM) {
/*
@@ -192,6 +209,8 @@ static void ath10k_htt_rx_msdu_buff_replenish(struct ath10k_htt *htt)
*/
mod_timer(&htt->rx_ring.refill_retry_timer, jiffies +
msecs_to_jiffies(HTT_RX_RING_REFILL_RETRY_MS));
+ } else if (num_deficit > 0) {
+ tasklet_schedule(&htt->rx_replenish_task);
}
spin_unlock_bh(&htt->rx_ring.lock);
}
@@ -213,6 +232,7 @@ void ath10k_htt_rx_detach(struct ath10k_htt *htt)
int sw_rd_idx = htt->rx_ring.sw_rd_idx.msdu_payld;
del_timer_sync(&htt->rx_ring.refill_retry_timer);
+ tasklet_kill(&htt->rx_replenish_task);
while (sw_rd_idx != __le32_to_cpu(*(htt->rx_ring.alloc_idx.vaddr))) {
struct sk_buff *skb =
@@ -442,6 +462,12 @@ static int ath10k_htt_rx_amsdu_pop(struct ath10k_htt *htt,
return msdu_chaining;
}
+static void ath10k_htt_rx_replenish_task(unsigned long ptr)
+{
+ struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
+ ath10k_htt_rx_msdu_buff_replenish(htt);
+}
+
int ath10k_htt_rx_attach(struct ath10k_htt *htt)
{
dma_addr_t paddr;
@@ -502,6 +528,9 @@ int ath10k_htt_rx_attach(struct ath10k_htt *htt)
if (__ath10k_htt_rx_ring_fill_n(htt, htt->rx_ring.fill_level))
goto err_fill_ring;
+ tasklet_init(&htt->rx_replenish_task, ath10k_htt_rx_replenish_task,
+ (unsigned long)htt);
+
ath10k_dbg(ATH10K_DBG_BOOT, "htt rx ring size %d fill_level %d\n",
htt->rx_ring.size, htt->rx_ring.fill_level);
return 0;
@@ -968,7 +997,7 @@ static void ath10k_htt_rx_handler(struct ath10k_htt *htt,
}
}
- ath10k_htt_rx_msdu_buff_replenish(htt);
+ tasklet_schedule(&htt->rx_replenish_task);
}
static void ath10k_htt_rx_frag_handler(struct ath10k_htt *htt,
--
1.7.9.5
^ permalink raw reply related
* Re: brcmsmac causes soft lockup in 3.12-rc1
From: Arend van Spriel @ 2013-09-24 7:53 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20130924005224.GA27400@mail.catnarok.net>
On 09/24/2013 02:52 AM, Michael Stolovitzsky wrote:
> On Mon, Sep 23, 2013 at 10:13:49AM +0200, Arend van Spriel wrote:
>> On 09/22/2013 12:34 AM, Michael Stolovitzsky wrote:
>>> Hi,
>>>
>>> On 3.12-rc1, modprobe brcmsmac causes a soft lockup (trace #1), effectively killing the box. This is a Lenovo S206
>>> with BCM4313 (14e4:4727), which I believe is a bluetooth combo board. After a while,
>>> RCU scheduler code detects a lockup (trace #2).
>>>
>>> This did not happen in 3.11.1, although brcmsmac hasn't worked on this machine
>>> as far as I remember. In the previous kernels (~3.2.0+), it loads, but the
>>> reception is extremely weak - you must be within few meters to the AP, and the card would
>>> die after several minutes. The proprietary wl.ko driver works fine.
>>>
>>> I've attached the dmesg output, the kernel configuration and the output of lspci -vnn.
>>> I'm comfortable with experimenting; please let me know how I can help here.
>>
>> A fix for this problem has been submitted to John. I think it is in
>> transit to mainline so probably will be in 3.12-rc2.
>>
>> Here the URL of the patch:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/patch/?id=aaa2ced15ad8dca8048666c9f70736424d696a6b
>>
>
> Arend, much thanks and an apology for not checking the patches. I will try this out ASAP.
>
> Is the (presumedly) low RX gain also a known problem with brcmsmac on BCM4313?
The patch is in 3.12-rc2. There have been more reports on that, but it
still needs to be investigated. Can you provide content of
/sys/kernel/debug/brcmsmac/bcma*/hardware? You need to have
CONFIG_BRCMDBG selected.
Regards,
Arend
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Pull request: ath 20130930
From: Kalle Valo @ 2013-09-24 7:33 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, ath10k, ath6kl-devel
In-Reply-To: <87wqmyz5i9.fsf@kamboji.qca.qualcomm.com>
Hi John,
when you start merging again please consider taking this pull request
which I sent too late last time. It should be still valid.
I have more patches queued up during the merge window, but I'm planning
to send them after you have pulled this. But if you prefer to have
everything in one go, I can do that as well.
Kalle
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> Hi John,
>
> here are latest ath10k changes, I hope it's still time to get these to
> 3.12. The changelog for the pull request:
>
> Bartosz dropped support for qca98xx hw1.0 hardware from ath10k, it's
> just too much to support it. Michal added support for the new firmware
> interface. Marek fixed WEP in AP and IBSS mode. Rest of the changes are
> minor fixes or cleanups.
>
> The following changes since commit 9d0e2f0772d394060bf3b17cd1f3a35574365103:
>
> ath6kl: Fix invalid pointer access on fuzz testing with AP mode (2013-08-07 10:58:59 +0300)
>
> are available in the git repository at:
>
> git://github.com/kvalo/ath.git for-linville
>
> for you to fetch changes up to 763b8cd31493f452094fd0eaeedb8cad37c756a2:
>
> ath10k: add chip_id file to debugfs (2013-09-03 09:59:53 +0300)
>
> ----------------------------------------------------------------
> Bartosz Markowski (2):
> ath10k: Remove qca98xx hw1.0 support
> ath10k: update supported FW build version
>
> Janusz Dziedzic (2):
> ath10k: setup peer UAPSD flag correctly
> ath10k: check allocation errors in CE
>
> Kalle Valo (10):
> ath10k: remove un ar_pci->cacheline_sz field
> ath10k: pci: make host_ce_config_wlan[] more readable
> ath10k: make target_ce_config_wlan more readable
> ath10k: remove void pointer from struct ath10k_pci_compl
> ath10k: convert ath10k_pci_reg_read/write32() to take struct ath10k
> ath10k: clean up ath10k_ce_completed_send_next_nolock()
> ath10k: convert ath10k_pci_wake() to return
> ath10k: simplify ath10k_ce_init() wake up handling
> ath10k: check chip id from the soc register during probe
> ath10k: add chip_id file to debugfs
>
> Marek Puzyniak (1):
> ath10k: fix WEP in AP and IBSS mode
>
> Michal Kazior (15):
> ath10k: clean up monitor start code
> ath10k: use sizeof(*var) in kmalloc
> ath10k: clean up PCI completion states
> ath10k: print errcode when CE ring setup fails
> ath10k: fix HTT service setup
> ath10k: implement 802.3 SNAP rx decap type A-MSDU handling
> ath10k: plug possible memory leak in WMI
> ath10k: add support for firmware newer than 636
> ath10k: add support for HTT 3.0
> ath10k: use inline ce_state structure
> ath10k: remove ce_op_state
> ath10k: remove unused ce_attr parameters
> ath10k: rename hif_ce_pipe_info to ath10k_pci_pipe
> ath10k: rename ce_state to ath10k_ce_pipe
> ath10k: rename ce_ring_state to ath10k_ce_ring
>
> Mohammed Shafi Shajakhan (1):
> ath10k: Fix mutex unlock balance
>
> drivers/net/wireless/ath/ath10k/ce.c | 291 +++++++++++++-------------
> drivers/net/wireless/ath/ath10k/ce.h | 74 +++----
> drivers/net/wireless/ath/ath10k/core.c | 46 +++--
> drivers/net/wireless/ath/ath10k/core.h | 13 +-
> drivers/net/wireless/ath/ath10k/debug.c | 23 ++-
> drivers/net/wireless/ath/ath10k/htc.c | 8 +-
> drivers/net/wireless/ath/ath10k/htt.c | 19 +-
> drivers/net/wireless/ath/ath10k/htt.h | 6 +-
> drivers/net/wireless/ath/ath10k/htt_rx.c | 12 +-
> drivers/net/wireless/ath/ath10k/htt_tx.c | 74 +++++--
> drivers/net/wireless/ath/ath10k/hw.h | 19 +-
> drivers/net/wireless/ath/ath10k/mac.c | 22 +-
> drivers/net/wireless/ath/ath10k/pci.c | 325 ++++++++++++++++++++----------
> drivers/net/wireless/ath/ath10k/pci.h | 73 +++----
> drivers/net/wireless/ath/ath10k/wmi.c | 33 ++-
> drivers/net/wireless/ath/ath10k/wmi.h | 16 +-
> 16 files changed, 626 insertions(+), 428 deletions(-)
--
Kalle Valo
^ permalink raw reply
* Re: [RFC 0/4] ath10k: improve RX performance
From: Kalle Valo @ 2013-09-24 7:29 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQnxqgz_90+Q8_FhM6PZh8CEW12dOA+ZGqHeYjK=Bbu9wA@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 24 September 2013 08:42, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> This patchset gives clear RX performance
>>> improvement on AP135. Throughput is at least
>>> doubled (300mbps -> 600mbps, UDP RX, 2x2).
>>>
>>> Patches depend on my RFC patch "mac80211: support
>>> reporting A-MSDU subframes individually".
>>
>> Preferably I can apply these changes only after the mac80211 patch goes
>> to net-next (to avoid unnecessary rebasing). Is there a way to
>> workaround the need for the mac80211 patch in ath10k so that we could
>> apply these patches ASAP? And once the mac80211 patch is commited we
>> could just remove the workaround in ath10k.
>
> The workaround could be to clear the retransmission flag when
> reporting A-MSDU frames individually.
That sounds very good. Can you do that and resend the patchset, please?
--
Kalle Valo
^ permalink raw reply
* Re: [RFC 0/4] ath10k: improve RX performance
From: Michal Kazior @ 2013-09-24 7:19 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87mwn2bu0i.fsf@kamboji.qca.qualcomm.com>
On 24 September 2013 08:42, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> This patchset gives clear RX performance
>> improvement on AP135. Throughput is at least
>> doubled (300mbps -> 600mbps, UDP RX, 2x2).
>>
>> Patches depend on my RFC patch "mac80211: support
>> reporting A-MSDU subframes individually".
>
> Preferably I can apply these changes only after the mac80211 patch goes
> to net-next (to avoid unnecessary rebasing). Is there a way to
> workaround the need for the mac80211 patch in ath10k so that we could
> apply these patches ASAP? And once the mac80211 patch is commited we
> could just remove the workaround in ath10k.
The workaround could be to clear the retransmission flag when
reporting A-MSDU frames individually.
Michał.
^ permalink raw reply
* Re: [RFC] ath10k: replenish HTT RX buffers in a tasklet
From: Kalle Valo @ 2013-09-24 6:59 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQ=Tg1Qv8qXqw8++hXiDsBXyeQKDjYesWdNg25ORMQJGRg@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 24 September 2013 08:22, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> This fixes system starvation when under heavy RX
>>> traffic. This problem could be observed on AP135
>>> and led to watchdog resetting the platform.
>>>
>>> Patch starves FW RX ring buffer by progressively
>>> replenishing buffers to auto-balance the RX
>>> handled to the host system.
>>>
>>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>>
>> Looks good to me. I suspect there is a better way to do this in long
>> term, but this looks like a viable short term solution.
>>
>> Does it decrease throughput in a noticeable way?
>
> I have yet to observe any regressions.
Good. If you think the patch should be applied please resend it as
"[PATCH]" so that I can apply it.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC] ath10k: replenish HTT RX buffers in a tasklet
From: Michal Kazior @ 2013-09-24 6:51 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87r4cebuxm.fsf@kamboji.qca.qualcomm.com>
On 24 September 2013 08:22, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> This fixes system starvation when under heavy RX
>> traffic. This problem could be observed on AP135
>> and led to watchdog resetting the platform.
>>
>> Patch starves FW RX ring buffer by progressively
>> replenishing buffers to auto-balance the RX
>> handled to the host system.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> Looks good to me. I suspect there is a better way to do this in long
> term, but this looks like a viable short term solution.
>
> Does it decrease throughput in a noticeable way?
I have yet to observe any regressions.
Michał.
^ permalink raw reply
* Re: [RFC 3/4] ath10k: cleanup RX decap handling
From: Kalle Valo @ 2013-09-24 6:47 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQ=q9ojX4bp61rExY7b9Pk+=Zpg_qNxfXYvt8eXscdC=bA@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 16 September 2013 23:30, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> Native Wifi frames are always decapped as non-QoS
>>> data frames meaning mac80211 couldn't set sk_buff
>>> priority properly. The patch fixes this by using
>>> the original 802.11 header.
>>>
>>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>>
>> The patch title doesn't seem to match with the content. Unless I'm
>> mistaken it looks like you are adding native wifi frame format support
>> and doing some cleanup at the same time. They should be in separate
>> patches.
>
> You're right. I'll split it up.
>
> Nwifi was supported, however QoS Data frames were reported as Data
> frames though.
Oh, ok. It would be good to document that in the commit log as well.
>>> case RX_MSDU_DECAP_RAW:
>>> - /* remove trailing FCS */
>>> - skb_trim(skb, skb->len - 4);
>>> + skb_trim(skb, skb->len - FCS_LEN);
>>> break;
>>
>> Please keep the comment still
>
> Why? The point of the comment was to explain the literal "4". Using
> define makes the comment redundant.
I know it's redundant, but this is just to improve readability.
>>> case RX_MSDU_DECAP_ETHERNET2_DIX:
>>> - /* macaddr[6] + macaddr[6] + ethertype[2] */
>>> - skb_pull(skb, 6 + 6 + 2);
>>> + rfc1042 = hdr;
>>> + rfc1042 += roundup(hdr_len, 4);
>>> + rfc1042 += roundup(ath10k_htt_rx_crypto_param_len(enctype), 4);
>>> +
>>> + skb_pull(skb, sizeof(struct ethhdr));
>>> + memcpy(skb_push(skb, sizeof(struct rfc1042_hdr)),
>>> + rfc1042, sizeof(struct rfc1042_hdr));
>>> + memcpy(skb_push(skb, hdr_len), hdr, hdr_len);
>>> break;
>>
>> Ditto.
>
> Comment was supposed to explain where those numbers come from. Using
> structures explains it now.
Sure, the structures are very good here. But like above, having small
comments improve readability. Think of it as a "title" or something like
that.
>>> case RX_MSDU_DECAP_8023_SNAP_LLC:
>>> - /* macaddr[6] + macaddr[6] + len[2] */
>>> - /* we don't need this for non-A-MSDU */
>>> - skb_pull(skb, 6 + 6 + 2);
>>> + skb_pull(skb, sizeof(struct amsdu_subframe_hdr));
>>> + memcpy(skb_push(skb, hdr_len), hdr, hdr_len);
>>> break;
>>
>> And here.
>
> Ditto.
Same here :)
--
Kalle Valo
^ permalink raw reply
* Re: [RFC 0/4] ath10k: improve RX performance
From: Kalle Valo @ 2013-09-24 6:42 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1379335757-15180-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> This patchset gives clear RX performance
> improvement on AP135. Throughput is at least
> doubled (300mbps -> 600mbps, UDP RX, 2x2).
>
> Patches depend on my RFC patch "mac80211: support
> reporting A-MSDU subframes individually".
Preferably I can apply these changes only after the mac80211 patch goes
to net-next (to avoid unnecessary rebasing). Is there a way to
workaround the need for the mac80211 patch in ath10k so that we could
apply these patches ASAP? And once the mac80211 patch is commited we
could just remove the workaround in ath10k.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC] ath10k: replenish HTT RX buffers in a tasklet
From: Kalle Valo @ 2013-09-24 6:22 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1379509691-19904-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> This fixes system starvation when under heavy RX
> traffic. This problem could be observed on AP135
> and led to watchdog resetting the platform.
>
> Patch starves FW RX ring buffer by progressively
> replenishing buffers to auto-balance the RX
> handled to the host system.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Looks good to me. I suspect there is a better way to do this in long
term, but this looks like a viable short term solution.
Does it decrease throughput in a noticeable way?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v5 1/2] Bluetooth: btmrvl: add setup handler
From: Marcel Holtmann @ 2013-09-24 4:23 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-bluetooth@vger.kernel.org, Gustavo Padovan, Johan Hedberg,
linux-wireless@vger.kernel.org, Mike Frysinger, Hyuckjoo Lee,
Amitkumar Karwar
In-Reply-To: <477F20668A386D41ADCC57781B1F70430F44C59418@SC-VEXCH1.marvell.com>
Hi Bing,
>>> - btmrvl_send_module_cfg_cmd(priv, MODULE_BRINGUP_REQ);
>>> + hdev->setup = btmrvl_setup;
>>
>> just to make sure you guys understand how ->setup() works. It is only called once. Bringing the
>> adapter down and up again does not call ->setup() a second time. So do you guys need this setup_done
>> variable and if so, then you need to be a bit more verbose and help me understand why.
>
> It's observed that sometimes the setup handler is called twice when Bluetooth daemon is running in background. We will rebase to latest commit on bluetooth-next tree and test again. If the issue is gone with the latest code in -next tree we will remove the setup_done flag.
that is a bug. It should only be ever called once. Could this be due to RFKILL issue we had? Please re-test with Johan's patches applied and check if it makes a difference. Otherwise please send some logs since we want to get this fixed.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v5 2/2] Bluetooth: btmrvl: add calibration data download support
From: Marcel Holtmann @ 2013-09-24 4:21 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-bluetooth@vger.kernel.org, Gustavo Padovan, Johan Hedberg,
linux-wireless@vger.kernel.org, Mike Frysinger, Hyuckjoo Lee,
Amitkumar Karwar
In-Reply-To: <477F20668A386D41ADCC57781B1F70430F44C59423@SC-VEXCH1.marvell.com>
Hi Bing,
>>> + cmd = (struct btmrvl_cmd *)skb->data;
>>> + cmd->ocf_ogf =
>>> + cpu_to_le16(hci_opcode_pack(OGF, BT_CMD_LOAD_CONFIG_DATA));
>>> + cmd->length = BT_CMD_DATA_SIZE;
>>> + cmd->data[0] = 0x00;
>>> + cmd->data[1] = 0x00;
>>> + cmd->data[2] = 0x00;
>>> + cmd->data[3] = BT_CMD_DATA_SIZE - 4;
>>
>> why not use __hci_cmd_sync() here. It is designed to be used from ->setup() where it is guaranteed
>> that the HCI request lock is held. And it is guaranteed that ->setup() is executed in a workqueue.
>
> The reason of not using __hci_cmd_sync() is that we are sending vendor specific command here (MRVL_VENDOR_PKT). The __hci_cmd_sync seems handle HCI_COMMAND_PKT only.
> Please let us know if you have any suggestion to solve this problem.
what is a MRVL_VENDOR_PKT actually?
If you guys are not using standard HCI command/event for vendor operation, then this obviously does not fit. However a similar model might make sense instead of manually building packets all the time.
Regards
Marcel
^ permalink raw reply
* [PATCH] mac80211: use exact-size allocation for authentication frame
From: Fred Zhou @ 2013-09-24 2:33 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Fred Zhou
The authentication frame has a fixied size of 30 bytes
(including header, algo num, trans seq num, and status)
followed by a variable challenge text.
Allocate using exact size, instead of over-allocation
by sizeof(ieee80211_mgmt).
Signed-off-by: Fred Zhou <fred.zy@gmail.com>
---
net/mac80211/util.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index e1b34a1..674ab12 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1083,9 +1083,10 @@ void ieee80211_send_auth(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb;
struct ieee80211_mgmt *mgmt;
int err;
-
+
+ /* 30 = header + auth_algo + auth_transaction + status_code */
skb = dev_alloc_skb(local->hw.extra_tx_headroom +
- sizeof(*mgmt) + 6 + extra_len);
+ 30 + extra_len);
if (!skb)
return;
--
1.7.9.5
^ permalink raw reply related
* Re: brcmsmac causes soft lockup in 3.12-rc1
From: Michael Stolovitzsky @ 2013-09-24 0:52 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <523FF83D.8030103@broadcom.com>
On Mon, Sep 23, 2013 at 10:13:49AM +0200, Arend van Spriel wrote:
> On 09/22/2013 12:34 AM, Michael Stolovitzsky wrote:
> >Hi,
> >
> >On 3.12-rc1, modprobe brcmsmac causes a soft lockup (trace #1), effectively killing the box. This is a Lenovo S206
> >with BCM4313 (14e4:4727), which I believe is a bluetooth combo board. After a while,
> >RCU scheduler code detects a lockup (trace #2).
> >
> >This did not happen in 3.11.1, although brcmsmac hasn't worked on this machine
> >as far as I remember. In the previous kernels (~3.2.0+), it loads, but the
> >reception is extremely weak - you must be within few meters to the AP, and the card would
> >die after several minutes. The proprietary wl.ko driver works fine.
> >
> >I've attached the dmesg output, the kernel configuration and the output of lspci -vnn.
> >I'm comfortable with experimenting; please let me know how I can help here.
>
> A fix for this problem has been submitted to John. I think it is in
> transit to mainline so probably will be in 3.12-rc2.
>
> Here the URL of the patch:
>
> https://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/patch/?id=aaa2ced15ad8dca8048666c9f70736424d696a6b
>
Arend, much thanks and an apology for not checking the patches. I will try this out ASAP.
Is the (presumedly) low RX gain also a known problem with brcmsmac on BCM4313?
^ permalink raw reply
* pull request: bluetooth 2013-09-23
From: Gustavo Padovan @ 2013-09-23 21:00 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]
Hi John,
First Bluetooth fixes to 3.12, it includes:
* 3 patches to add device id for 3 new hardwares.
* 2 patches from Johan to fix the rfkill behaviour during setup stage
* a small clean up in the rfcomm TTY code that fixes a potential racy
condition (by Gianluca Anzolin)
* 2 fixes to proper set encryption key size and security level in the
peripheral role of Bluetooth LE devices. (by Andre Guedes)
* a fix for dealing devices where pairing is not necessary, we were keeping
the Bluetooth ACL connection alive for too much time. (by Syam Sidhardhan)
Please pull or let me know of any problems! Thanks!
Gustavo
---
The following changes since commit f4e1a4d3ecbb9e42bdf8e7869ee8a4ebfa27fb20:
rt2800: change initialization sequence to fix system freeze (2013-09-09 14:44:34 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master
for you to fetch changes up to 5bcecf325378218a8e248bb6bcae96ec7362f8ef:
Bluetooth: btusb: Add support for Belkin F8065bf (2013-09-23 17:44:25 -0300)
----------------------------------------------------------------
Andre Guedes (2):
Bluetooth: Fix security level for peripheral role
Bluetooth: Fix encryption key size for peripheral role
Gianluca Anzolin (1):
Bluetooth: don't release the port in rfcomm_dev_state_change()
Johan Hedberg (2):
Bluetooth: Introduce a new HCI_RFKILLED flag
Bluetooth: Fix rfkill functionality during the HCI setup stage
Ken O'Brien (1):
Bluetooth: btusb: Add support for Belkin F8065bf
Peng Chen (1):
Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.
Raphael Kubo da Costa (1):
Bluetooth: Add support for BCM20702A0 [0b05, 17cb]
Syam Sidhardhan (1):
Bluetooth: Fix ACL alive for long in case of non pariable devices
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 5 +++++
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_core.c | 26 ++++++++++++++++++++------
net/bluetooth/hci_event.c | 6 +++++-
net/bluetooth/l2cap_core.c | 7 +++++++
net/bluetooth/rfcomm/tty.c | 35 ++---------------------------------
7 files changed, 42 insertions(+), 40 deletions(-)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [brcmfmac] BUG: unable to handle kernel paging request at ffffffff82196446
From: Arend van Spriel @ 2013-09-23 20:07 UTC (permalink / raw)
To: Fengguang Wu
Cc: Hante Meuleman, John W. Linville, linux-kernel, linux-wireless,
brcm80211-dev-list
In-Reply-To: <20130923121402.GA12626@localhost>
On 09/23/2013 02:14 PM, Fengguang Wu wrote:
> On Mon, Sep 16, 2013 at 11:15:53AM +0200, Arend van Spriel wrote:
>> On 09/02/2013 12:23 PM, Fengguang Wu wrote:
>>> Greetings,
>>>
>>> I got the below dmesg and the first bad commit is
>>
>> Hi Fengguang,
>>
>> I could not reproduce this issue. Could you retest with the attached
>> patch file applied and let me know if that fixes the problem?
>
> Yeah it fixed the problem: no more oops in 1000 kernel boot tests. Thank you!
Whoa, 1000 boots. Thank you for being so thorough :-)
Regards,
Arend
^ permalink raw reply
* [PATCH 3.12 2/2] cw1200: Use a threaded oneshot irq handler for cw1200_spi
From: Solomon Peachy @ 2013-09-23 20:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
In-Reply-To: <1379966404-7047-1-git-send-email-pizza@shaftnet.org>
This supercedes the older patch ("cw1200: Don't perform SPI transfers in
interrupt context") that badly attempted to fix this problem.
This is a far simpler solution, which has the added benefit of
actually working.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
drivers/net/wireless/cw1200/cw1200_spi.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/cw1200/cw1200_spi.c b/drivers/net/wireless/cw1200/cw1200_spi.c
index 5a64ac9..899cad3 100644
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -250,9 +250,10 @@ static int cw1200_spi_irq_subscribe(struct hwbus_priv *self)
pr_debug("SW IRQ subscribe\n");
- ret = request_any_context_irq(self->func->irq, cw1200_spi_irq_handler,
- IRQF_TRIGGER_HIGH,
- "cw1200_wlan_irq", self);
+ ret = request_threaded_irq(self->func->irq, NULL,
+ cw1200_spi_irq_handler,
+ IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
+ "cw1200_wlan_irq", self);
if (WARN_ON(ret < 0))
goto exit;
--
1.8.3.1
^ permalink raw reply related
* [PATCH 3.12 1/2] Revert "cw1200: Don't perform SPI transfers in interrupt context"
From: Solomon Peachy @ 2013-09-23 20:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
In-Reply-To: <1379966404-7047-1-git-send-email-pizza@shaftnet.org>
This reverts commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35.
This solution turned out to cause interrupt delivery problems, and
rather than trying to fix this approach, it has been scrapped in favor
of an alternative (and far simpler) implementation.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
drivers/net/wireless/cw1200/cw1200_spi.c | 19 +++----------------
drivers/net/wireless/cw1200/fwio.c | 2 +-
drivers/net/wireless/cw1200/hwbus.h | 1 -
drivers/net/wireless/cw1200/hwio.c | 15 ---------------
4 files changed, 4 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/cw1200/cw1200_spi.c b/drivers/net/wireless/cw1200/cw1200_spi.c
index f5e6b48..5a64ac9 100644
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -42,7 +42,6 @@ struct hwbus_priv {
spinlock_t lock; /* Serialize all bus operations */
wait_queue_head_t wq;
int claimed;
- int irq_disabled;
};
#define SDIO_TO_SPI_ADDR(addr) ((addr & 0x1f)>>2)
@@ -238,8 +237,6 @@ static irqreturn_t cw1200_spi_irq_handler(int irq, void *dev_id)
struct hwbus_priv *self = dev_id;
if (self->core) {
- disable_irq_nosync(self->func->irq);
- self->irq_disabled = 1;
cw1200_irq_handler(self->core);
return IRQ_HANDLED;
} else {
@@ -273,22 +270,13 @@ exit:
static int cw1200_spi_irq_unsubscribe(struct hwbus_priv *self)
{
+ int ret = 0;
+
pr_debug("SW IRQ unsubscribe\n");
disable_irq_wake(self->func->irq);
free_irq(self->func->irq, self);
- return 0;
-}
-
-static int cw1200_spi_irq_enable(struct hwbus_priv *self, int enable)
-{
- /* Disables are handled by the interrupt handler */
- if (enable && self->irq_disabled) {
- enable_irq(self->func->irq);
- self->irq_disabled = 0;
- }
-
- return 0;
+ return ret;
}
static int cw1200_spi_off(const struct cw1200_platform_data_spi *pdata)
@@ -368,7 +356,6 @@ static struct hwbus_ops cw1200_spi_hwbus_ops = {
.unlock = cw1200_spi_unlock,
.align_size = cw1200_spi_align_size,
.power_mgmt = cw1200_spi_pm,
- .irq_enable = cw1200_spi_irq_enable,
};
/* Probe Function to be called by SPI stack when device is discovered */
diff --git a/drivers/net/wireless/cw1200/fwio.c b/drivers/net/wireless/cw1200/fwio.c
index 0b2061b..acdff0f 100644
--- a/drivers/net/wireless/cw1200/fwio.c
+++ b/drivers/net/wireless/cw1200/fwio.c
@@ -485,7 +485,7 @@ int cw1200_load_firmware(struct cw1200_common *priv)
/* Enable interrupt signalling */
priv->hwbus_ops->lock(priv->hwbus_priv);
- ret = __cw1200_irq_enable(priv, 2);
+ ret = __cw1200_irq_enable(priv, 1);
priv->hwbus_ops->unlock(priv->hwbus_priv);
if (ret < 0)
goto unsubscribe;
diff --git a/drivers/net/wireless/cw1200/hwbus.h b/drivers/net/wireless/cw1200/hwbus.h
index 51dfb3a..8b2fc83 100644
--- a/drivers/net/wireless/cw1200/hwbus.h
+++ b/drivers/net/wireless/cw1200/hwbus.h
@@ -28,7 +28,6 @@ struct hwbus_ops {
void (*unlock)(struct hwbus_priv *self);
size_t (*align_size)(struct hwbus_priv *self, size_t size);
int (*power_mgmt)(struct hwbus_priv *self, bool suspend);
- int (*irq_enable)(struct hwbus_priv *self, int enable);
};
#endif /* CW1200_HWBUS_H */
diff --git a/drivers/net/wireless/cw1200/hwio.c b/drivers/net/wireless/cw1200/hwio.c
index 41bd761..ff230b7 100644
--- a/drivers/net/wireless/cw1200/hwio.c
+++ b/drivers/net/wireless/cw1200/hwio.c
@@ -273,21 +273,6 @@ int __cw1200_irq_enable(struct cw1200_common *priv, int enable)
u16 val16;
int ret;
- /* We need to do this hack because the SPI layer can sleep on I/O
- and the general path involves I/O to the device in interrupt
- context.
-
- However, the initial enable call needs to go to the hardware.
-
- We don't worry about shutdown because we do a full reset which
- clears the interrupt enabled bits.
- */
- if (priv->hwbus_ops->irq_enable) {
- ret = priv->hwbus_ops->irq_enable(priv->hwbus_priv, enable);
- if (ret || enable < 2)
- return ret;
- }
-
if (HIF_8601_SILICON == priv->hw_type) {
ret = __cw1200_reg_read_32(priv, ST90TDS_CONFIG_REG_ID, &val32);
if (ret < 0) {
--
1.8.3.1
^ permalink raw reply related
* [PATCH 3.12 0/2] Fix cw1200_spi interrupt delivery
From: Solomon Peachy @ 2013-09-23 20:00 UTC (permalink / raw)
To: linux-wireless
The earlier fix for cw1200_spi driver's interrupt handling woes solved
the oops, but it had the side effect of making interrupt delivery
unreliable nearly to the point of uselessness.
Rather than try to fix the fix, just revert entirely and convert it to
using Linux's threaded oneshot irq handling. Far simpler, and it
actually seems to work.
^ permalink raw reply
* Re: [Ilw] Intel 6300 crashes hard (3.11 regression?)
From: Emmanuel Grumbach @ 2013-09-23 19:47 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: Grumbach, Emmanuel, ilw@linux.intel.com,
linux-wireless@vger.kernel.org
In-Reply-To: <CAObL_7GA-SD5bK7Hnwyp_vnoLxSbcGGtnzgyD-GBHAwaxF1JxQ@mail.gmail.com>
>>> I've had a failure twice on 3.11.1-200.fc19.x86_64. I've never seen it on
>>> earlier Fedora kernels or on 3.11-rc3. The computer hangs for a minute or so.
>>> When it comes back, wireless doesn't work. rmmoding and modprobing
>>> iwldvm doesn't help (it's at the bottom of the attachment).
>>>
>>> Even rebooting doesn't fix it unless I pull the battery. Otherwise iwlwifi loads
>>> but wlan0 doesn't appear and the only log line is the one saying that iwlwifi
>>> loaded.
>>>
>>> The messages on startup are:
>>>
>>> [ 11.440725] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't
>>> have ASPM control
>>> [ 11.440788] iwlwifi 0000:03:00.0: irq 51 for MSI/MSI-X
>>> [ 11.455653] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1
>>> build 25532 op_mode iwldvm
>>> [ 11.517924] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
>>> [ 11.517930] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
>>> [ 11.517932] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING
>>> disabled
>>> [ 11.517934] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P disabled
>>> [ 11.517936] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R)
>>> Ultimate-N 6300 AGN, REV=0x74
>>> [ 11.519626] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
>>>
>>> (Both failures happened with pcie_aspm=force, but this is without it.
>>> I want to see if disabling that option fixes it.)
>>
>> Please do and report back - what I can see here is that we kinda can't access the NIC - so I would be curious if pcie_aspm=force changes the game here.
>>
>
> It happened again. This time I got some stuff in the middle of the
> dump that I didn't notice last time:
>
> [ 1125.076283] iwlwifi 0000:03:00.0: Q 19 is active and mapped to fifo
> 2 ra_tid 0xa5a5 [90,1515870810]
> [ 1127.073531] iwlwifi 0000:03:00.0: Error sending REPLY_TXFIFO_FLUSH:
> time out after 2000ms.
> [ 1127.073544] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 143
> [ 1127.073550] iwlwifi 0000:03:00.0: Couldn't flush the AGG queue
> [ 1129.110029] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time
> out after 2000ms.
> [ 1129.110037] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 146
> [ 1129.110044] wlan0: HW problem - can not stop rx aggregation for
> 50:a7:33:27:30:78 tid 0
> [ 1131.107391] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time
> out after 2000ms.
> [ 1131.107399] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 149
> [ 1131.107405] wlan0: HW problem - can not stop rx aggregation for
> 50:a7:33:27:30:78 tid 1
> [ 1133.104739] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time
> out after 2000ms.
> [ 1133.104745] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 152
> [ 1133.104750] wlan0: HW problem - can not stop rx aggregation for
> 50:a7:33:27:30:78 tid 5
> [ 1135.102155] iwlwifi 0000:03:00.0: Error sending REPLY_ADD_STA: time
> out after 2000ms.
> [ 1135.102160] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 155
> [ 1135.102163] wlan0: HW problem - can not stop rx aggregation for
> 50:a7:33:27:30:78 tid 6
> [ 1137.099675] iwlwifi 0000:03:00.0: Error sending REPLY_QOS_PARAM:
> time out after 2000ms.
> [ 1137.099682] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 158
> [ 1137.099686] iwlwifi 0000:03:00.0: Failed to update QoS
> [ 1139.097113] iwlwifi 0000:03:00.0: Error sending REPLY_RXON: time
> out after 2000ms.
> [ 1139.097120] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 161
> [ 1139.097124] iwlwifi 0000:03:00.0: Error clearing ASSOC_MSK on BSS (-110)
> [ 1141.094533] iwlwifi 0000:03:00.0: Error sending REPLY_RXON: time
> out after 2000ms.
> [ 1141.094589] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 164
> [ 1141.094633] iwlwifi 0000:03:00.0: Error clearing ASSOC_MSK on BSS (-110)
> [ 1141.314184] iwlwifi 0000:03:00.0: No space in command queue
> [ 1141.314259] iwlwifi 0000:03:00.0: Restarting adapter queue is full
> [ 1141.314305] iwlwifi 0000:03:00.0: Error sending REPLY_LEDS_CMD:
> enqueue_hcmd failed: -28
> [ 1143.091961] iwlwifi 0000:03:00.0: Error sending REPLY_RXON: time
> out after 2000ms.
> [ 1143.092016] iwlwifi 0000:03:00.0: Current CMD queue read_ptr 135
> write_ptr 165
> [ 1143.092060] iwlwifi 0000:03:00.0: Error clearing ASSOC_MSK on BSS (-110)
> [ 1145.090373] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 0
> [ 1145.090450] iwlwifi 0000:03:00.0: Current SW read_ptr 142 write_ptr 143
> [ 1145.110262] iwl data: 00000000: 90 3b 0d a2 00 88 ff ff 50 3b 0d a2
> 00 88 ff ff .;......P;......
> [ 1145.130280] iwlwifi 0000:03:00.0: FH TRBs(0) = 0x5a5a5a5a
> [ 1145.149994] iwlwifi 0000:03:00.0: FH TRBs(1) = 0x5a5a5a5a
> [ 1145.169813] iwlwifi 0000:03:00.0: FH TRBs(2) = 0x5a5a5a5a
> [ 1145.189419] iwlwifi 0000:03:00.0: FH TRBs(3) = 0x5a5a5a5a
> [ 1145.208993] iwlwifi 0000:03:00.0: FH TRBs(4) = 0x5a5a5a5a
> [ 1145.228552] iwlwifi 0000:03:00.0: FH TRBs(5) = 0x5a5a5a5a
> [ 1145.248097] iwlwifi 0000:03:00.0: FH TRBs(6) = 0x5a5a5a5a
> [ 1145.267558] iwlwifi 0000:03:00.0: FH TRBs(7) = 0x5a5a5a5a
>
Just saw this:
[ 3030.922014] pci_pm_runtime_suspend():
hcd_pci_runtime_suspend+0x0/0x50 returns -16
[ 3116.219553] pci_pm_runtime_suspend():
hcd_pci_runtime_suspend+0x0/0x50 returns -16
[ 3208.606354] iwlwifi 0000:03:00.0: Error sending POWER_TABLE_CMD:
time out after 2000ms.
can it be that the PCI subsystem gets confused after suspend resume?
^ permalink raw reply
* RE: [PATCH 11/19] wireless: Change variable type to bool
From: Bing Zhao @ 2013-09-23 19:40 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <1379802471-30252-11-git-send-email-peter.senna@gmail.com>
Hi Peter,
Thanks for your patch.
> The variables cancel_scan_cmd, enable_data, hs_activate and valid are
> only assigned the values true and false. Change its type to bool.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @exists@
> type T;
> identifier b;
> @@
> - T
> + bool
> b = ...;
> ... when any
> b = \(true\|false\)
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
Thanks,
Bing
> ---
> drivers/net/wireless/mwifiex/cmdevt.c | 2 +-
> drivers/net/wireless/mwifiex/join.c | 2 +-
> drivers/net/wireless/mwifiex/sta_cmd.c | 2 +-
> drivers/net/wireless/mwifiex/wmm.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply
* RE: [PATCH v5 2/2] Bluetooth: btmrvl: add calibration data download support
From: Bing Zhao @ 2013-09-23 19:35 UTC (permalink / raw)
To: Marcel Holtmann
Cc: linux-bluetooth@vger.kernel.org, Gustavo Padovan, Johan Hedberg,
linux-wireless@vger.kernel.org, Mike Frysinger, Hyuckjoo Lee,
Amitkumar Karwar
In-Reply-To: <05172D80-CE30-4B7D-A64E-11B8E320EF7F@holtmann.org>
Hi Marcel,
> > + cmd = (struct btmrvl_cmd *)skb->data;
> > + cmd->ocf_ogf =
> > + cpu_to_le16(hci_opcode_pack(OGF, BT_CMD_LOAD_CONFIG_DATA));
> > + cmd->length = BT_CMD_DATA_SIZE;
> > + cmd->data[0] = 0x00;
> > + cmd->data[1] = 0x00;
> > + cmd->data[2] = 0x00;
> > + cmd->data[3] = BT_CMD_DATA_SIZE - 4;
>
> why not use __hci_cmd_sync() here. It is designed to be used from ->setup() where it is guaranteed
> that the HCI request lock is held. And it is guaranteed that ->setup() is executed in a workqueue.
The reason of not using __hci_cmd_sync() is that we are sending vendor specific command here (MRVL_VENDOR_PKT). The __hci_cmd_sync seems handle HCI_COMMAND_PKT only.
Please let us know if you have any suggestion to solve this problem.
Thanks,
Bing
^ permalink raw reply
* [PATCH] staging: vt6656: [BUG] iwctl_siwencodeext return if device not open
From: Malcolm Priestley @ 2013-09-23 19:30 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Don't allow entry to iwctl_siwencodeext if device not open.
This fixes a race condition where wpa supplicant/network manager
enters the function when the device is already closed.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Cc: stable@vger.kernel.org # 3.8+
---
drivers/staging/vt6656/iwctl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/vt6656/iwctl.c b/drivers/staging/vt6656/iwctl.c
index 033cb50..5968888 100644
--- a/drivers/staging/vt6656/iwctl.c
+++ b/drivers/staging/vt6656/iwctl.c
@@ -1634,6 +1634,9 @@ int iwctl_siwencodeext(struct net_device *dev, struct iw_request_info *info,
if (pMgmt == NULL)
return -EFAULT;
+ if (!(pDevice->flags & DEVICE_FLAGS_OPENED))
+ return -ENODEV;
+
buf = kzalloc(sizeof(struct viawget_wpa_param), GFP_KERNEL);
if (buf == NULL)
return -ENOMEM;
--
1.8.3.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox