* [PATCH] ath9k: Prevent radar detection and spectral scan to be used concurrently
From: Benjamin Berg @ 2016-11-21 14:04 UTC (permalink / raw)
To: Kalle Valo
Cc: ath9k-devel, linux-wireless, Benjamin Berg, Mathias Kretschmer,
Simon Wunderlich
In the case that a spectral scan is enabled the PHY errors sent by the
hardware as part of the scanning might trigger the radar detection and
channels might be marked as 'unusable' incorrectly. This patch fixes
the issue by preventing the spectral scan to be enabled if DFS is used
and only analysing the PHY errors for DFS if radar detection is enabled.
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
---
drivers/net/wireless/ath/ath9k/common-spectral.c | 23 +++++++++++++++++++----
drivers/net/wireless/ath/ath9k/main.c | 6 ++++++
drivers/net/wireless/ath/ath9k/recv.c | 7 +++++--
3 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c b/drivers/net/wireless/ath/ath9k/common-spectral.c
index e2512d5..8444d6d 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -802,16 +802,27 @@ static ssize_t write_file_spec_scan_ctl(struct file *file,
size_t count, loff_t *ppos)
{
struct ath_spec_scan_priv *spec_priv = file->private_data;
+ struct ath_hw *ah = spec_priv->ah;
+ struct ath_softc *sc = ah->hw->priv;
struct ath_common *common = ath9k_hw_common(spec_priv->ah);
char buf[32];
ssize_t len;
+ ssize_t result = count;
if (IS_ENABLED(CONFIG_ATH9K_TX99))
return -EOPNOTSUPP;
+ mutex_lock(&sc->mutex);
+ if (ah->hw->conf.radar_enabled) {
+ result = -EINVAL;
+ goto unlock;
+ }
+
len = min(count, sizeof(buf) - 1);
- if (copy_from_user(buf, user_buf, len))
- return -EFAULT;
+ if (copy_from_user(buf, user_buf, len)) {
+ result = -EFAULT;
+ goto unlock;
+ }
buf[len] = '\0';
@@ -830,10 +841,14 @@ static ssize_t write_file_spec_scan_ctl(struct file *file,
ath9k_cmn_spectral_scan_config(common, spec_priv, SPECTRAL_DISABLED);
ath_dbg(common, CONFIG, "spectral scan: disabled\n");
} else {
- return -EINVAL;
+ result = -EINVAL;
+ goto unlock;
}
- return count;
+unlock:
+ mutex_unlock(&sc->mutex);
+
+ return result;
}
static const struct file_operations fops_spec_scan_ctl = {
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index e9f32b5..62b86fb 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1459,6 +1459,12 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
if (!ath9k_is_chanctx_enabled() && (changed & IEEE80211_CONF_CHANGE_CHANNEL)) {
ctx->offchannel = !!(conf->flags & IEEE80211_CONF_OFFCHANNEL);
ath_chanctx_set_channel(sc, ctx, &hw->conf.chandef);
+
+ /* We need to ensure that spectral scan is disabled. */
+ if (conf->radar_enabled &&
+ sc->spec_priv.spectral_mode != SPECTRAL_DISABLED)
+ ath9k_cmn_spectral_scan_config(common, &sc->spec_priv,
+ SPECTRAL_DISABLED);
}
mutex_unlock(&sc->mutex);
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 6697342..ce34add 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -867,8 +867,11 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
* can be dropped.
*/
if (rx_stats->rs_status & ATH9K_RXERR_PHY) {
- ath9k_dfs_process_phyerr(sc, hdr, rx_stats, rx_status->mactime);
- if (ath_cmn_process_fft(&sc->spec_priv, hdr, rx_stats, rx_status->mactime))
+ if (hw->conf.radar_enabled)
+ ath9k_dfs_process_phyerr(sc, hdr, rx_stats,
+ rx_status->mactime);
+ else if (ath_cmn_process_fft(&sc->spec_priv, hdr, rx_stats,
+ rx_status->mactime))
RX_STAT_INC(rx_spectral);
return -EINVAL;
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 4.9.0-rc5] AR9300 calibration problems with antenna selected
From: Krzysztof Hałasa @ 2016-11-21 13:54 UTC (permalink / raw)
To: miaoqing
Cc: ath9k-devel, Kalle Valo, linux-wireless, ath9k-devel, netdev,
linux-kernel
In-Reply-To: <2ea016e563f5db553f201a7d4205c2c0@codeaurora.org>
miaoqing@codeaurora.org writes:
>> rmmod ath9k
>> modprobe ath9k
>> iw dev wlan0 set type ibss
>> iw phy phyX set antenna 2
>
> 2 is a bad mask. We use bitmap, the valid masks are 1, 3, 7.
Thanks for your response.
I have two antenna connections (and a single antenna). Is it possible to
select the secondary antenna connector only? How?
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
^ permalink raw reply
* [PATCH] brcmsmac: fix array out-of-bounds access in qm_log10
From: Tobias Regnery @ 2016-11-21 13:29 UTC (permalink / raw)
To: linux-wireless, kvalo, arend.vanspriel, franky.lin,
hante.meuleman, brcm80211-dev-list.pdl
Cc: Tobias Regnery
I get the following UBSAN warning during boot on my laptop:
================================================================================
UBSAN: Undefined behaviour in drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c:280:21
index 32 is out of range for type 's16 [32]'
CPU: 0 PID: 879 Comm: NetworkManager Not tainted 4.9.0-rc4 #28
Hardware name: LENOVO Lenovo IdeaPad N581/INVALID, BIOS 5ECN96WW(V9.01) 03/14/2013
ffff8800b74a6478 ffffffff828e59d2 0000000041b58ab3 ffffffff8398330c
ffffffff828e5920 ffff8800b74a64a0 ffff8800b74a6450 0000000000000020
1ffffffff845848c ffffed0016e94bf1 ffffffffc22c2460 000000006b9c0514
Call Trace:
[<ffffffff828e59d2>] dump_stack+0xb2/0x110
[<ffffffff828e5920>] ? _atomic_dec_and_lock+0x150/0x150
[<ffffffff82968c9d>] ubsan_epilogue+0xd/0x4e
[<ffffffff82969875>] __ubsan_handle_out_of_bounds+0xfa/0x13e
[<ffffffff8296977b>] ? __ubsan_handle_shift_out_of_bounds+0x241/0x241
[<ffffffffc0d48379>] ? bcma_host_pci_read16+0x59/0xa0 [bcma]
[<ffffffffc0d48388>] ? bcma_host_pci_read16+0x68/0xa0 [bcma]
[<ffffffffc212ad78>] ? read_phy_reg+0xe8/0x180 [brcmsmac]
[<ffffffffc2184714>] qm_log10+0x2e4/0x350 [brcmsmac]
[<ffffffffc2142eb8>] wlc_phy_init_lcnphy+0x538/0x1f20 [brcmsmac]
[<ffffffffc2142980>] ? wlc_lcnphy_periodic_cal+0x5c0/0x5c0 [brcmsmac]
[<ffffffffc1ba0c93>] ? ieee80211_open+0xb3/0x110 [mac80211]
[<ffffffff82f73a02>] ? sk_busy_loop+0x1e2/0x840
[<ffffffff82f7a6ce>] ? __dev_change_flags+0xae/0x220
...
The report is valid: doing the math in this function, with an input value
N=63 the variable s16tableIndex gets a value of 31. This value is used as
an index in the array log_table with 32 entries. But the next line is:
s16errorApproximation = (s16) qm_mulu16(u16offset,
(u16) (log_table[s16tableIndex + 1] -
log_table[s16tableIndex]));
With s16tableIndex + 1 we are trying an out-of-bounds access to the array.
The log_table array provides log2 values in q.15 format and the above
statement tries an error approximation with the next value. To fix this
issue add the next value to the array and update the comment accordingly.
Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com>
---
I am not that familiar with wireless drivers and thus don't know if this
is the right way to fix the issue. But the UBSAN warning goes away with
this patch and I don't see a regression with my wireless adapter afterwards.
As far as I can tell, this bug is present since the introduction of the
driver in mainline.
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c
index faf1ebe76068..b9672da24a9d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c
@@ -179,7 +179,7 @@ s16 qm_norm32(s32 op)
return u16extraSignBits;
}
-/* This table is log2(1+(i/32)) where i=[0:1:31], in q.15 format */
+/* This table is log2(1+(i/32)) where i=[0:1:32], in q.15 format */
static const s16 log_table[] = {
0,
1455,
@@ -212,7 +212,8 @@ static const s16 log_table[] = {
29717,
30498,
31267,
- 32024
+ 32024,
+ 32768
};
#define LOG_TABLE_SIZE 32 /* log_table size */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v7 2/2] mac80211: multicast to unicast conversion
From: Johannes Berg @ 2016-11-21 13:24 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, netdev, projekt-wlan
In-Reply-To: <1477921260-24556-2-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-31 at 14:41 +0100, Michael Braun wrote:
> +static int ieee80211_set_multicast_to_unicast(struct wiphy *wiphy,
> + struct net_device
> *dev,
> + const bool enabled)
> +{
> + struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> +
> + /* not supported with P2P_GO for now */
> + if (sdata->vif.type != NL80211_IFTYPE_AP)
> + return -EOPNOTSUPP;
This check is completely inefficient, since vif.type is == AP for GO.
Also, I see no reason to restrict it that way, why not remove the
check? There's no difference.
> +static inline int
> +ieee80211_multicast_to_unicast(struct sk_buff *skb, struct
> net_device *dev)
use bool return?
johannes
^ permalink raw reply
* Re: [PATCH] nl80211: fix logic inversion in start_nan()
From: Arend Van Spriel @ 2016-11-21 12:58 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Johannes Berg
In-Reply-To: <576a08f1-3246-4e59-57a1-704e429674bd@broadcom.com>
On 21-11-2016 13:57, Arend Van Spriel wrote:
> On 21-11-2016 13:55, Johannes Berg wrote:
>> From: Johannes Berg <johannes.berg@intel.com>
>>
>> Arend inadvertedly inverted the logic while converting to
>> wdev_running(), fix that.
>
> It was indeed inadvertedly.
Actually spelling checker complains. Should be 'inadvertently'.
Regards,
Arend
> Thanks,
> Arend
>
>> Fixes: 73c7da3dae1e ("cfg80211: add generic helper to check interface is running")
>> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>> ---
>> net/wireless/nl80211.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
>> index 4e9bda49e957..e4f718e956d7 100644
>> --- a/net/wireless/nl80211.c
>> +++ b/net/wireless/nl80211.c
>> @@ -10625,7 +10625,7 @@ static int nl80211_start_nan(struct sk_buff *skb, struct genl_info *info)
>> if (wdev->iftype != NL80211_IFTYPE_NAN)
>> return -EOPNOTSUPP;
>>
>> - if (!wdev_running(wdev))
>> + if (wdev_running(wdev))
>> return -EEXIST;
>>
>> if (rfkill_blocked(rdev->rfkill))
>>
^ permalink raw reply
* Re: [PATCH] nl80211: fix logic inversion in start_nan()
From: Arend Van Spriel @ 2016-11-21 12:57 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Johannes Berg
In-Reply-To: <20161121125548.4730-1-johannes@sipsolutions.net>
On 21-11-2016 13:55, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Arend inadvertedly inverted the logic while converting to
> wdev_running(), fix that.
It was indeed inadvertedly.
Thanks,
Arend
> Fixes: 73c7da3dae1e ("cfg80211: add generic helper to check interface is running")
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> net/wireless/nl80211.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 4e9bda49e957..e4f718e956d7 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -10625,7 +10625,7 @@ static int nl80211_start_nan(struct sk_buff *skb, struct genl_info *info)
> if (wdev->iftype != NL80211_IFTYPE_NAN)
> return -EOPNOTSUPP;
>
> - if (!wdev_running(wdev))
> + if (wdev_running(wdev))
> return -EEXIST;
>
> if (rfkill_blocked(rdev->rfkill))
>
^ permalink raw reply
* [PATCH] nl80211: fix logic inversion in start_nan()
From: Johannes Berg @ 2016-11-21 12:55 UTC (permalink / raw)
To: linux-wireless; +Cc: Arend Van Spriel, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Arend inadvertedly inverted the logic while converting to
wdev_running(), fix that.
Fixes: 73c7da3dae1e ("cfg80211: add generic helper to check interface is running")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 4e9bda49e957..e4f718e956d7 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10625,7 +10625,7 @@ static int nl80211_start_nan(struct sk_buff *skb, struct genl_info *info)
if (wdev->iftype != NL80211_IFTYPE_NAN)
return -EOPNOTSUPP;
- if (!wdev_running(wdev))
+ if (wdev_running(wdev))
return -EEXIST;
if (rfkill_blocked(rdev->rfkill))
--
2.9.3
^ permalink raw reply related
* Re: ath10k stuck in mesh mode
From: Matteo Grandi @ 2016-11-21 12:53 UTC (permalink / raw)
To: Michal Kazior; +Cc: Bob Copeland, LinuxWireless Mailing List
In-Reply-To: <CA+BoTQ=xCmYtqrMZpoqtNUTN8e_WE=AFpqU3LQdopiSik5eODA@mail.gmail.com>
Yes, I noticed it, in fact it seems to be the reg. domain of the ath9k
(there is also an ath9k card plugged on the same board).
But it is in contrast with what I found in the syslog:
Nov 21 07:53:23 MrProper kernel: [ 9.591563] ath: Regpair used: 0x3a
Nov 21 07:53:23 MrProper kernel: [ 9.591573] cfg80211: Updating
information on frequency 5180 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591581] cfg80211: (5140000 KHz
- 5360000 KHz @ 80000 KHz), (N/A, 3000 mBm)
[...]
- 5360000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591654] cfg80211: Updating
information on frequency 5300 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591661] cfg80211: (5140000 KHz
- 5360000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591668] cfg80211: Updating
information on frequency 5320 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591675] cfg80211: (5140000 KHz
- 5360000 KHz @ 80000 KHz), (N/A, 3000 mBm
where there are @80MHz frequency slots.
Is it possible that the system, showing all these different reg.
domains from different cards, chose the most constrained one?
2016-11-21 11:53 GMT+01:00 Michal Kazior <michal.kazior@tieto.com>:
> On 21 November 2016 at 10:46, Matteo Grandi <iu5bdp@gmail.com> wrote:
>> Dear Bob, Michal, all,
>>
>> I've just tried your advices (actually I already tried it following
>> the wireless.wiki.kernel web pages) and I had a look at the syslog
>> while I was typing the commands
>> At the beginning I have this
> [...]
>> Other (hopefully) useful info:
>> root@MrProper:~# iw reg get
>> global
>> country US: DFS-UNSET
>> (2402 - 2472 @ 40), (3, 27), (N/A)
>> (5170 - 5250 @ 40), (3, 17), (N/A)
>> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
>> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
>> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
>> (5735 - 5835 @ 40), (3, 30), (N/A)
>> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>>
>> phy#2
>> country US: DFS-UNSET
>> (2402 - 2472 @ 40), (3, 27), (N/A)
>> (5170 - 5250 @ 40), (3, 17), (N/A)
>> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
>> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
>> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
>> (5735 - 5835 @ 40), (3, 30), (N/A)
>> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>>
>> phy#0
>> country US: DFS-UNSET
>> (2402 - 2472 @ 40), (3, 27), (N/A)
>> (5170 - 5250 @ 40), (3, 17), (N/A)
>> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
>> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
>> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
>> (5735 - 5835 @ 40), (3, 30), (N/A)
>> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>>
>> phy#1
>> country US: DFS-UNSET
>> (2402 - 2472 @ 40), (3, 27), (N/A)
>> (5170 - 5250 @ 40), (3, 17), (N/A)
>> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
>> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
>> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
>> (5735 - 5835 @ 40), (3, 30), (N/A)
>> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>>[...]
>>
>> Checking on Internet I didn't find a working solution, and the data
>> rate stucks to 120Mbps MCS7.
>> For me it still a mistery, I hope in your help.
>
> Note the "@ 40" for all frequency ranges (except 60GHz band). Your
> regulatory database seems to be limiting you to 40 MHz (it's probably
> very old/ out of date). You'll need to update it to be able to use 80
> MHz.
>
>
> Michal
^ permalink raw reply
* Re: [PATCH v7 1/2] nl80211: multicast_to_unicast can be changed while IFF_UP
From: Johannes Berg @ 2016-11-21 12:50 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, netdev, projekt-wlan
In-Reply-To: <1477921260-24556-1-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-31 at 14:40 +0100, Michael Braun wrote:
> There is no need to prevent toggling multicast_to_unicast while
> interface is already up. This change simplifies reconfiguration
> from hostapd.
Applied. This check never should've been there anyway, if desired,
NEED_NETDEV_UP should've been used.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] nl80211: check NL80211_ATTR_SCHED_SCAN_INTERVAL only once
From: Johannes Berg @ 2016-11-21 12:48 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <1479373360-1398-2-git-send-email-arend.vanspriel@broadcom.com>
On Thu, 2016-11-17 at 09:02 +0000, Arend van Spriel wrote:
> The presence of the NL80211_ATTR_SCHED_SCAN_INTERVAL attribute was
> checked in nl80211_parse_sched_scan() and
> nl80211_parse_sched_scan_plans() which might be a bit redundant
> so removing one.
>
makes sense, applied.
johannes
^ permalink raw reply
* Re: [PATCH V2] cfg80211: get rid of name indirection trick for ieee80211_get_channel()
From: Johannes Berg @ 2016-11-21 12:45 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <1479386933-17834-1-git-send-email-arend.vanspriel@broadcom.com>
On Thu, 2016-11-17 at 12:48 +0000, Arend van Spriel wrote:
> The comment on the name indirection suggested an issue but turned out
> to be untrue. Digging in older kernel version showed issue with
> ipw2x00
> but that is no longer true so get rid on the name indirection.
>
Applied, thanks.
johannes
^ permalink raw reply
* Re: Problems with mwifiex_pcie firmware activation
From: Stanislaw Gruszka @ 2016-11-21 12:20 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Nishant Sarmukadam, linux-wireless@vger.kernel.org, Charles Rose
In-Reply-To: <2165db278e1c486d8fffbd2db4150481@SC-EXCH04.marvell.com>
Hi
On Wed, Nov 16, 2016 at 06:03:49AM +0000, Amitkumar Karwar wrote:
> > From: Stanislaw Gruszka [mailto:sgruszka@redhat.com]
> > Sent: Monday, November 14, 2016 3:46 PM
> > To: Amitkumar Karwar
> > Cc: Nishant Sarmukadam; linux-wireless@vger.kernel.org
> > Subject: Re: Problems with mwifiex_pcie firmware activation
> >
> > On Thu, Aug 25, 2016 at 05:06:26PM +0200, Stanislaw Gruszka wrote:
> > > On Fri, Aug 12, 2016 at 10:13:43AM +0200, Stanislaw Gruszka wrote:
> > > > On Fri, Aug 12, 2016 at 07:17:38AM +0000, Amitkumar Karwar wrote:
> > > > > The problem looks strange. The patch just splits
> > mwifiex_check_fw_status() and increases poll count. It should not have
> > any side-effects.
> > > > > Our code used to check winner status before this patch also.
> > > >
> > > > Ok, I misread the patch. Anyway checking "winner status" seems does
> > > > not work well on some condition and prevent loading firmware into
> > > > device.
> > >
> > > I debug this a bit more on latest wireless-testing-next tree + 3
> > > patches I just posted and debug_mask=0x700000ff.
> > >
> > > On broken system, we do not download FW to device when system is
> > > rebooted, due to PCI-E is not the winner. However if system is
> > powered
> > > OFF and then powered ON, we do FW downloading. Hence download the new
> > > FW into device does not make it work as was my theory.
> > >
> > > In attachments are full dmesgs of good/bad and reboot/power-off-on
> > > cases.
> > >
> > > The difference is that on broken system FW (or HW) do not create new
> > > USB Bluetooth device (1286:2046) and do not report
> > > FIRMWARE_READY_PCIE. Additionally on reboot case there are errors
> > from
> > > USB xhci.
> >
> > It was discovered that not working device require pcie8897_uapsta.bin
> > firmware from ubuntu package to work:
>
> What's the difference between working and non-working device?
I can not find anything reasonable. Lspci gives almost the same print.
There is some difference, but I think it comes from from fact that
working device is enabled and non-working is disabled.
Working:
03:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88W8897 [AVASTAR] 802.11ac Wireless [11ab:2b38]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 266
Region 0: Memory at 90700000 (64-bit, prefetchable) [size=1M]
Region 2: Memory at 90600000 (64-bit, prefetchable) [size=1M]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/32 Maskable+ 64bit+
Address: 00000000fee0200c Data: 4172
Masking: fffffffe Pending: 00000000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <1us, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR+, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [150 v1] Power Budgeting <?>
Capabilities: [160 v1] Latency Tolerance Reporting
Max snoop latency: 71680ns
Max no snoop latency: 71680ns
Capabilities: [168 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=70us PortTPowerOnTime=10us
Kernel driver in use: mwifiex_pcie
Kernel modules: mwifiex_pcie
Non-working:
02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88W8897 [AVASTAR] 802.11ac Wireless [11ab:2b38]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 18
Region 0: Memory at 90700000 (64-bit, prefetchable) [size=1M]
Region 2: Memory at 90600000 (64-bit, prefetchable) [size=1M]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <1us, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR+, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [150 v1] Power Budgeting <?>
Capabilities: [160 v1] Latency Tolerance Reporting
Max snoop latency: 71680ns
Max no snoop latency: 71680ns
Capabilities: [168 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=70us PortTPowerOnTime=10us
Kernel driver in use: mwifiex_pcie
Kernel modules: mwifiex_pcie
I also added some extra code to print registers that are used to identify
other PCIE_DEVICE_ID_MARVELL_88W8997 device:
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 3c3c4f1..84434ab 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2921,6 +2921,9 @@ static void mwifiex_pcie_get_fw_name(struct
mwifiex_adapter *adapter)
case PCIE_DEVICE_ID_MARVELL_88W8897:
mwifiex_write_reg(adapter, 0x0c58, 0x80c00000);
mwifiex_read_reg(adapter, 0x0c58, &revision_id);
+ mwifiex_read_reg(adapter, 0x0cd0, &version);
+ mwifiex_read_reg(adapter, 0x0cd4, &magic);
+ printk("%s revision_id 0x%08x version 0x%08x magic 0x%08x\n", __func__, revision_id, version, magic);
revision_id &= 0xff00;
switch (revision_id) {
case PCIE8897_A0:
but prints are the same for non-working and working system:
mwifiex_pcie_get_fw_name revision_id 0x00001430 version 0x00000000 magic 0x00000000
So I'm not sure if device in working and non-working system is different.
Maybe difference is in how device is connected with the rest of the system
or in other hardware parts. Cc Charles, perhaps he can elaborate more about
that.
> > https://launchpad.net/~snappy-dev/+archive/ubuntu/snappy-
> > devices/+sourcepub/5936055/+listing-archive-extra
> >
> > Device initialize like this then:
> >
> > [ 15.374630] mwifiex_pcie 0000:02:00.0: info: FW download over, size
> > 689624 bytes
> > [ 16.101214] mwifiex_pcie 0000:02:00.0: WLAN FW is active
> > [ 16.242825] mwifiex_pcie 0000:02:00.0: info: MWIFIEX VERSION:
> > mwifiex 1.0 (15.150.13.p21)
> > [ 16.251231] mwifiex_pcie 0000:02:00.0: driver_version = mwifiex 1.0
> > (15.150.13.p21)
> >
> > I'm not sure where ubuntu get this 15.150.13.p21 version of firmware as
> > it seems it's not present nor in upstream linux-firmware repo not in
> > http://git.marvell.com/?p=mwifiex-firmware.git;a=summary
> >
> > Anyway could you modify firmware to support this device or modify
> > driver to load 15.150.13.p21 if required and push this F/W image
> > upstream ?
> >
>
> Last released firmware is 15.68.7.p77
> http://git.marvell.com/?p=mwifiex-firmware.git;a=commit;h=05e2f3a4acf4174ec507a3464a374ecb1b4ec011
> Could you try with it?
I does not make device on non-workig system work.
> If it doesn't work, we need to investigate what is missing in this compared to 15.150.13.p21 and create new 15.68.7.pXX.
Thanks
Stanislaw
^ permalink raw reply related
* [PATCH] mwifiex: Disable adhoc feature based on firmware capability
From: Amitkumar Karwar @ 2016-11-21 12:19 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Karthik D A, Amitkumar Karwar
From: Karthik D A <karthida@marvell.com>
We will read fw_cap_info filled by firmware to check whether to
skip ADHOC related commands or not. Also, IBSS_COALESCING_STATUS
command has been moved from init path to adhoc network creation
path.
Signed-off-by: Karthik D A <karthida@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 10 +++++++
drivers/net/wireless/marvell/mwifiex/fw.h | 1 +
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 36 +++++++++++++++++--------
3 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index a231f09..a7d359e 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2143,6 +2143,16 @@ static int mwifiex_cfg80211_inform_ibss_bss(struct mwifiex_private *priv)
ret = mwifiex_set_encode(priv, NULL, NULL, 0, 0, NULL, 1);
if (mode == NL80211_IFTYPE_ADHOC) {
+ u16 enable = true;
+
+ /* set ibss coalescing_status */
+ ret = mwifiex_send_cmd(
+ priv,
+ HostCmd_CMD_802_11_IBSS_COALESCING_STATUS,
+ HostCmd_ACT_GEN_SET, 0, &enable, true);
+ if (ret)
+ return ret;
+
/* "privacy" is set only for ad-hoc mode */
if (privacy) {
/*
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index 9b3ccea..ea45594 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -219,6 +219,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
#define ISSUPP_TDLS_ENABLED(FwCapInfo) (FwCapInfo & BIT(14))
#define ISSUPP_DRCS_ENABLED(FwCapInfo) (FwCapInfo & BIT(15))
#define ISSUPP_SDIO_SPA_ENABLED(FwCapInfo) (FwCapInfo & BIT(16))
+#define ISSUPP_ADHOC_ENABLED(FwCapInfo) (FwCapInfo & BIT(25))
#define MWIFIEX_DEF_HT_CAP (IEEE80211_HT_CAP_DSSSCCK40 | \
(1 << IEEE80211_HT_CAP_RX_STBC_SHIFT) | \
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 768c519..125e448 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -1900,6 +1900,24 @@ static int mwifiex_cmd_get_wakeup_reason(struct mwifiex_private *priv,
return 0;
}
+/* This function check if the command is supported by firmware */
+static int mwifiex_is_cmd_supported(struct mwifiex_private *priv, u16 cmd_no)
+{
+ if (!ISSUPP_ADHOC_ENABLED(priv->adapter->fw_cap_info)) {
+ switch (cmd_no) {
+ case HostCmd_CMD_802_11_IBSS_COALESCING_STATUS:
+ case HostCmd_CMD_802_11_AD_HOC_START:
+ case HostCmd_CMD_802_11_AD_HOC_JOIN:
+ case HostCmd_CMD_802_11_AD_HOC_STOP:
+ return -EOPNOTSUPP;
+ default:
+ break;
+ }
+ }
+
+ return 0;
+}
+
/*
* This function prepares the commands before sending them to the firmware.
*
@@ -1913,6 +1931,13 @@ int mwifiex_sta_prepare_cmd(struct mwifiex_private *priv, uint16_t cmd_no,
struct host_cmd_ds_command *cmd_ptr = cmd_buf;
int ret = 0;
+ if (mwifiex_is_cmd_supported(priv, cmd_no)) {
+ mwifiex_dbg(priv->adapter, ERROR,
+ "0x%x command not supported by firmware\n",
+ cmd_no);
+ return -EOPNOTSUPP;
+ }
+
/* Prepare command */
switch (cmd_no) {
case HostCmd_CMD_GET_HW_SPEC:
@@ -2206,7 +2231,6 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
{
struct mwifiex_adapter *adapter = priv->adapter;
int ret;
- u16 enable = true;
struct mwifiex_ds_11n_amsdu_aggr_ctrl amsdu_aggr_ctrl;
struct mwifiex_ds_auto_ds auto_ds;
enum state_11d_t state_11d;
@@ -2319,16 +2343,6 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
if (ret)
return -1;
- if (priv->bss_type == MWIFIEX_BSS_TYPE_STA) {
- /* set ibss coalescing_status */
- ret = mwifiex_send_cmd(
- priv,
- HostCmd_CMD_802_11_IBSS_COALESCING_STATUS,
- HostCmd_ACT_GEN_SET, 0, &enable, true);
- if (ret)
- return -1;
- }
-
memset(&amsdu_aggr_ctrl, 0, sizeof(amsdu_aggr_ctrl));
amsdu_aggr_ctrl.enable = true;
/* Send request to firmware */
--
1.9.1
^ permalink raw reply related
* Re: scheduled scan interval
From: Arend Van Spriel @ 2016-11-21 12:03 UTC (permalink / raw)
To: Johannes Berg, Coelho, Luciano; +Cc: linux-wireless
In-Reply-To: <dffc5408-3337-32e7-0998-3ae8a5199fa9@broadcom.com>
On 21-11-2016 12:30, Arend Van Spriel wrote:
> On 21-11-2016 12:19, Arend Van Spriel wrote:
>> Hi Johannes, Luca,
>>
>> The gscan work made me look at scheduled scan and the implementation of
>> it in brcmfmac. The driver ignored the interval parameter from
>> user-space. Now I am fixing that. One thing is that our firmware has a
>> minimum interval which can not be indicated in struct wiphy. The other
>> issue is how the maximum interval is used in the nl80211.c.
>>
>> In nl80211_parse_sched_scan_plans() it is used against value passed in
>> NL80211_ATTR_SCHED_SCAN_INTERVAL and NL80211_SCHED_SCAN_PLAN_INTERVAL.
>> For the first one it caps the value to the maximum, but for the second
>> one it returns -EINVAL. I suspect this is done because maximum interval
>> was introduced with schedule scan plans, but it feels inconsistent.
>
> It also maybe simply wrong to cap. At least brcmfmac does not set the
> maximum so it will always get interval being zero. Maybe better to do:
>
> if (wiphy->max_sched_scan_plan_interval &&
> request->scan_plans[0].interval >
> wiphy->max_sched_scan_plan_interval)
> return -EINVAL;
>
>> Thoughts?
Digging deeper. Looking at v4.3 before introduction of sched_scan_plans.
struct sched_scan_request::interval was specified in milliseconds! Below
the drivers that I see having scheduled scan support:
iwlmvm: cap interval, convert to seconds.
ath6kl: cap to 1sec minimum, no max check, convert to seconds.
wl12xx: no checking in driver, fw need milliseconds.
wl18xx: no checking in driver, fw need milliseconds.
The milliseconds conversion seems to be taken care of by multiplying
with MSEC_PER_SEC in wl{12,18}xx drivers.
It seems in 4.8 only iwlmvm set wiphy->max_sched_scan_plan_interval so
other drivers will get interval of zero which only ath6kl handles.
Regards,
Arend
^ permalink raw reply
* Re: scheduled scan interval
From: Arend Van Spriel @ 2016-11-21 11:30 UTC (permalink / raw)
To: Johannes Berg, Coelho, Luciano; +Cc: linux-wireless
In-Reply-To: <bc071499-a8ef-2b0b-bfb7-42c96f1d369c@broadcom.com>
On 21-11-2016 12:19, Arend Van Spriel wrote:
> Hi Johannes, Luca,
>
> The gscan work made me look at scheduled scan and the implementation of
> it in brcmfmac. The driver ignored the interval parameter from
> user-space. Now I am fixing that. One thing is that our firmware has a
> minimum interval which can not be indicated in struct wiphy. The other
> issue is how the maximum interval is used in the nl80211.c.
>
> In nl80211_parse_sched_scan_plans() it is used against value passed in
> NL80211_ATTR_SCHED_SCAN_INTERVAL and NL80211_SCHED_SCAN_PLAN_INTERVAL.
> For the first one it caps the value to the maximum, but for the second
> one it returns -EINVAL. I suspect this is done because maximum interval
> was introduced with schedule scan plans, but it feels inconsistent.
It also maybe simply wrong to cap. At least brcmfmac does not set the
maximum so it will always get interval being zero. Maybe better to do:
if (wiphy->max_sched_scan_plan_interval &&
request->scan_plans[0].interval >
wiphy->max_sched_scan_plan_interval)
return -EINVAL;
> Thoughts?
>
> Regards,
> Arend
>
^ permalink raw reply
* scheduled scan interval
From: Arend Van Spriel @ 2016-11-21 11:19 UTC (permalink / raw)
To: Johannes Berg, Coelho, Luciano; +Cc: linux-wireless
Hi Johannes, Luca,
The gscan work made me look at scheduled scan and the implementation of
it in brcmfmac. The driver ignored the interval parameter from
user-space. Now I am fixing that. One thing is that our firmware has a
minimum interval which can not be indicated in struct wiphy. The other
issue is how the maximum interval is used in the nl80211.c.
In nl80211_parse_sched_scan_plans() it is used against value passed in
NL80211_ATTR_SCHED_SCAN_INTERVAL and NL80211_SCHED_SCAN_PLAN_INTERVAL.
For the first one it caps the value to the maximum, but for the second
one it returns -EINVAL. I suspect this is done because maximum interval
was introduced with schedule scan plans, but it feels inconsistent.
Thoughts?
Regards,
Arend
^ permalink raw reply
* Re: ath10k stuck in mesh mode
From: Michal Kazior @ 2016-11-21 10:53 UTC (permalink / raw)
To: Matteo Grandi; +Cc: Bob Copeland, LinuxWireless Mailing List
In-Reply-To: <CAHdg3xZMJw47Zyh9ubawysGqo6N2qcNUXX1o19GyFYOHv8GivA@mail.gmail.com>
On 21 November 2016 at 10:46, Matteo Grandi <iu5bdp@gmail.com> wrote:
> Dear Bob, Michal, all,
>
> I've just tried your advices (actually I already tried it following
> the wireless.wiki.kernel web pages) and I had a look at the syslog
> while I was typing the commands
> At the beginning I have this
[...]
> Other (hopefully) useful info:
> root@MrProper:~# iw reg get
> global
> country US: DFS-UNSET
> (2402 - 2472 @ 40), (3, 27), (N/A)
> (5170 - 5250 @ 40), (3, 17), (N/A)
> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
> (5735 - 5835 @ 40), (3, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>
> phy#2
> country US: DFS-UNSET
> (2402 - 2472 @ 40), (3, 27), (N/A)
> (5170 - 5250 @ 40), (3, 17), (N/A)
> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
> (5735 - 5835 @ 40), (3, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>
> phy#0
> country US: DFS-UNSET
> (2402 - 2472 @ 40), (3, 27), (N/A)
> (5170 - 5250 @ 40), (3, 17), (N/A)
> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
> (5735 - 5835 @ 40), (3, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>
> phy#1
> country US: DFS-UNSET
> (2402 - 2472 @ 40), (3, 27), (N/A)
> (5170 - 5250 @ 40), (3, 17), (N/A)
> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
> (5735 - 5835 @ 40), (3, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>[...]
>
> Checking on Internet I didn't find a working solution, and the data
> rate stucks to 120Mbps MCS7.
> For me it still a mistery, I hope in your help.
Note the "@ 40" for all frequency ranges (except 60GHz band). Your
regulatory database seems to be limiting you to 40 MHz (it's probably
very old/ out of date). You'll need to update it to be able to use 80
MHz.
Michal
^ permalink raw reply
* Re: ath10k stuck in mesh mode
From: Matteo Grandi @ 2016-11-21 9:46 UTC (permalink / raw)
To: Michal Kazior; +Cc: Bob Copeland, LinuxWireless Mailing List
In-Reply-To: <CA+BoTQm9DBc_tkQnXwLVuV6dbsEixn73t_TRk1akktTiwRm_0w@mail.gmail.com>
Dear Bob, Michal, all,
I've just tried your advices (actually I already tried it following
the wireless.wiki.kernel web pages) and I had a look at the syslog
while I was typing the commands
At the beginning I have this
root@MrProper:~# tail -f -n 200 /var/log/syslog
Nov 21 07:53:23 MrProper kernel: [ 9.121882] cfg80211: Updating
information on frequency 5260 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.121891] cfg80211: (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.121900] cfg80211: Updating
information on frequency 5280 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.121906] cfg80211: (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.121913] cfg80211: Updating
information on frequency 5300 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.121923] cfg80211: (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.121931] cfg80211: Updating
information on frequency 5320 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.121937] cfg80211: (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.121946] cfg80211: Updating
information on frequency 5500 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.121954] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.121963] cfg80211: Updating
information on frequency 5520 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.121972] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.121982] cfg80211: Updating
information on frequency 5540 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.121990] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.121997] cfg80211: Updating
information on frequency 5560 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.122004] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.122012] cfg80211: Updating
information on frequency 5580 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.122021] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.122029] cfg80211: Disabling
freq 5600 MHz for good
Nov 21 07:53:23 MrProper kernel: [ 9.122038] cfg80211: Disabling
freq 5620 MHz for good
Nov 21 07:53:23 MrProper kernel: [ 9.122044] cfg80211: Disabling
freq 5640 MHz for good
Nov 21 07:53:23 MrProper kernel: [ 9.122051] cfg80211: Updating
information on frequency 5660 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.122058] cfg80211: (5650000 KHz
- 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.122068] cfg80211: Updating
information on frequency 5680 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.122077] cfg80211: (5650000 KHz
- 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.122085] cfg80211: Updating
information on frequency 5700 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.122094] cfg80211: (5650000 KHz
- 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.122099] cfg80211: Disabling
freq 5720 MHz for good
Nov 21 07:53:23 MrProper kernel: [ 9.122110] cfg80211: Updating
information on frequency 5745 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.122118] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.122125] cfg80211: Updating
information on frequency 5765 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.122133] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.122141] cfg80211: Updating
information on frequency 5785 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.122147] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.122156] cfg80211: Updating
information on frequency 5805 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.122166] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.122175] cfg80211: Updating
information on frequency 5825 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.122184] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.487186] ath10k_pci
0000:07:00.0: qca988x hw2.0 (0x4100016c, 0x043222ff sub 0000:0000) fw
10.2.4.70.58 fwapi 5 bdapi 1 htt-ver 2.1 wmi-op 5 htt-op 2 cal otp
max-sta 128 raw 1 hwcrypto 1 features no-p2p,raw-mode
Nov 21 07:53:23 MrProper kernel: [ 9.487202] ath10k_pci
0000:07:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1
Nov 21 07:53:23 MrProper kernel: [ 9.591528] ath: EEPROM regdomain: 0x0
Nov 21 07:53:23 MrProper kernel: [ 9.591537] ath: EEPROM indicates
default country code should be used
Nov 21 07:53:23 MrProper kernel: [ 9.591542] ath: doing EEPROM
country->regdmn map search
Nov 21 07:53:23 MrProper kernel: [ 9.591553] ath: country maps to
regdmn code: 0x3a
Nov 21 07:53:23 MrProper kernel: [ 9.591558] ath: Country alpha2
being used: US
Nov 21 07:53:23 MrProper kernel: [ 9.591563] ath: Regpair used: 0x3a
Nov 21 07:53:23 MrProper kernel: [ 9.591573] cfg80211: Updating
information on frequency 5180 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591581] cfg80211: (5140000 KHz
- 5360000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591589] cfg80211: Updating
information on frequency 5200 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591597] cfg80211: (5140000 KHz
- 5360000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591603] cfg80211: Updating
information on frequency 5220 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591611] cfg80211: (5140000 KHz
- 5360000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591617] cfg80211: Updating
information on frequency 5240 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591624] cfg80211: (5140000 KHz
- 5360000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591630] cfg80211: Updating
information on frequency 5260 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591636] cfg80211: (5140000 KHz
- 5360000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591641] cfg80211: Updating
information on frequency 5280 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591648] cfg80211: (5140000 KHz
- 5360000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591654] cfg80211: Updating
information on frequency 5300 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591661] cfg80211: (5140000 KHz
- 5360000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591668] cfg80211: Updating
information on frequency 5320 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591675] cfg80211: (5140000 KHz
- 5360000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591680] cfg80211: Disabling
freq 5500 MHz as custom regd has no rule that fits it
Nov 21 07:53:23 MrProper kernel: [ 9.591685] cfg80211: Disabling
freq 5520 MHz as custom regd has no rule that fits it
Nov 21 07:53:23 MrProper kernel: [ 9.591691] cfg80211: Disabling
freq 5540 MHz as custom regd has no rule that fits it
Nov 21 07:53:23 MrProper kernel: [ 9.591697] cfg80211: Disabling
freq 5560 MHz as custom regd has no rule that fits it
Nov 21 07:53:23 MrProper kernel: [ 9.591703] cfg80211: Disabling
freq 5580 MHz as custom regd has no rule that fits it
Nov 21 07:53:23 MrProper kernel: [ 9.591708] cfg80211: Disabling
freq 5600 MHz as custom regd has no rule that fits it
Nov 21 07:53:23 MrProper kernel: [ 9.591714] cfg80211: Disabling
freq 5620 MHz as custom regd has no rule that fits it
Nov 21 07:53:23 MrProper kernel: [ 9.591719] cfg80211: Disabling
freq 5640 MHz as custom regd has no rule that fits it
Nov 21 07:53:23 MrProper kernel: [ 9.591725] cfg80211: Disabling
freq 5660 MHz as custom regd has no rule that fits it
Nov 21 07:53:23 MrProper kernel: [ 9.591731] cfg80211: Disabling
freq 5680 MHz as custom regd has no rule that fits it
Nov 21 07:53:23 MrProper kernel: [ 9.591737] cfg80211: Disabling
freq 5700 MHz as custom regd has no rule that fits it
Nov 21 07:53:23 MrProper kernel: [ 9.591743] cfg80211: Updating
information on frequency 5720 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591750] cfg80211: (5715000 KHz
- 5860000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591755] cfg80211: Updating
information on frequency 5745 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591762] cfg80211: (5715000 KHz
- 5860000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591768] cfg80211: Updating
information on frequency 5765 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591775] cfg80211: (5715000 KHz
- 5860000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591782] cfg80211: Updating
information on frequency 5785 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591788] cfg80211: (5715000 KHz
- 5860000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591795] cfg80211: Updating
information on frequency 5805 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591802] cfg80211: (5715000 KHz
- 5860000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591808] cfg80211: Updating
information on frequency 5825 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591815] cfg80211: (5715000 KHz
- 5860000 KHz @ 80000 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591975] cfg80211: Updating
information on frequency 5180 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.591987] cfg80211: (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.591996] cfg80211: Updating
information on frequency 5200 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592003] cfg80211: (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592010] cfg80211: Updating
information on frequency 5220 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592017] cfg80211: (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592024] cfg80211: Updating
information on frequency 5240 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592030] cfg80211: (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592037] cfg80211: Updating
information on frequency 5260 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592043] cfg80211: (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592050] cfg80211: Updating
information on frequency 5280 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592056] cfg80211: (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592062] cfg80211: Updating
information on frequency 5300 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592069] cfg80211: (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592075] cfg80211: Updating
information on frequency 5320 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592081] cfg80211: (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592088] cfg80211: Updating
information on frequency 5500 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592094] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592100] cfg80211: Updating
information on frequency 5520 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592107] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592113] cfg80211: Updating
information on frequency 5540 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592119] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592125] cfg80211: Updating
information on frequency 5560 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592131] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592137] cfg80211: Updating
information on frequency 5580 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592143] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592150] cfg80211: Disabling
freq 5600 MHz
Nov 21 07:53:23 MrProper kernel: [ 9.592154] cfg80211: Disabling
freq 5620 MHz
Nov 21 07:53:23 MrProper kernel: [ 9.592159] cfg80211: Disabling
freq 5640 MHz
Nov 21 07:53:23 MrProper kernel: [ 9.592165] cfg80211: Updating
information on frequency 5660 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592171] cfg80211: (5650000 KHz
- 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592177] cfg80211: Updating
information on frequency 5680 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592184] cfg80211: (5650000 KHz
- 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592190] cfg80211: Updating
information on frequency 5700 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592197] cfg80211: (5650000 KHz
- 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592202] cfg80211: Disabling
freq 5720 MHz
Nov 21 07:53:23 MrProper kernel: [ 9.592208] cfg80211: Updating
information on frequency 5745 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592214] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592220] cfg80211: Updating
information on frequency 5765 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592226] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592233] cfg80211: Updating
information on frequency 5785 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592239] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592245] cfg80211: Updating
information on frequency 5805 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592251] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.592257] cfg80211: Updating
information on frequency 5825 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.592263] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593783] cfg80211: Updating
information on frequency 5180 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593797] cfg80211: (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593805] cfg80211: Updating
information on frequency 5200 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593812] cfg80211: (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593819] cfg80211: Updating
information on frequency 5220 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593825] cfg80211: (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593832] cfg80211: Updating
information on frequency 5240 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593838] cfg80211: (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593845] cfg80211: Updating
information on frequency 5260 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593851] cfg80211: (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593857] cfg80211: Updating
information on frequency 5280 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593863] cfg80211: (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593870] cfg80211: Updating
information on frequency 5300 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593876] cfg80211: (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593882] cfg80211: Updating
information on frequency 5320 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593888] cfg80211: (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593894] cfg80211: Updating
information on frequency 5500 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593900] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593906] cfg80211: Updating
information on frequency 5520 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593913] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593919] cfg80211: Updating
information on frequency 5540 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593925] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593931] cfg80211: Updating
information on frequency 5560 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593937] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593943] cfg80211: Updating
information on frequency 5580 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593950] cfg80211: (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593956] cfg80211: Disabling
freq 5600 MHz for good
Nov 21 07:53:23 MrProper kernel: [ 9.593961] cfg80211: Disabling
freq 5620 MHz for good
Nov 21 07:53:23 MrProper kernel: [ 9.593966] cfg80211: Disabling
freq 5640 MHz for good
Nov 21 07:53:23 MrProper kernel: [ 9.593972] cfg80211: Updating
information on frequency 5660 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593978] cfg80211: (5650000 KHz
- 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593984] cfg80211: Updating
information on frequency 5680 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.593990] cfg80211: (5650000 KHz
- 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.593997] cfg80211: Updating
information on frequency 5700 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.594004] cfg80211: (5650000 KHz
- 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.594009] cfg80211: Disabling
freq 5720 MHz for good
Nov 21 07:53:23 MrProper kernel: [ 9.594015] cfg80211: Updating
information on frequency 5745 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.594021] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.594027] cfg80211: Updating
information on frequency 5765 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.594033] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.594040] cfg80211: Updating
information on frequency 5785 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.594046] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.594052] cfg80211: Updating
information on frequency 5805 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.594058] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [ 9.594064] cfg80211: Updating
information on frequency 5825 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [ 9.594070] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:25 MrProper dhclient: DHCPDISCOVER on eth1 to
255.255.255.255 port 67 interval 5 (xid=3D0x7e93e3c2)
Nov 21 07:53:25 MrProper kernel: [ 10.946730] sky2 0000:08:00.0
eth1: Link is up at 1000 Mbps, full duplex, flow control both
Nov 21 07:53:25 MrProper kernel: [ 10.946777] IPv6:
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Nov 21 07:53:30 MrProper dhclient: DHCPDISCOVER on eth1 to
255.255.255.255 port 67 interval 10 (xid=3D0x7e93e3c2)
Nov 21 07:53:31 MrProper dhclient: DHCPREQUEST of 192.168.10.141 on
eth1 to 255.255.255.255 port 67 (xid=3D0x7e93e3c2)
Nov 21 07:53:31 MrProper dhclient: DHCPOFFER of 192.168.10.141 from 192.168=
.10.1
Nov 21 07:53:31 MrProper dhclient: DHCPACK of 192.168.10.141 from 192.168.1=
0.1
Nov 21 07:53:31 MrProper dhclient: bound to 192.168.10.141 -- renewal
in 39009 seconds.
Nov 21 07:53:31 MrProper cron[816]: (CRON) INFO (pidfile fd =3D 3)
Nov 21 07:53:31 MrProper cron[847]: (CRON) STARTUP (fork ok)
Nov 21 07:53:31 MrProper cron[847]: (CRON) INFO (Running @reboot jobs)
Nov 21 07:53:32 MrProper dnsmasq[888]: started, version 2.68 cachesize 150
Nov 21 07:53:32 MrProper dnsmasq[888]: compile time options: IPv6
GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth
Nov 21 07:53:32 MrProper dnsmasq[888]: reading /var/run/dnsmasq/resolv.conf
Nov 21 07:53:32 MrProper dnsmasq[888]: using nameserver 147.83.2.10#53
Nov 21 07:53:32 MrProper dnsmasq[888]: using nameserver 147.83.2.3#53
Nov 21 07:53:32 MrProper dnsmasq[888]: read /etc/hosts - 4 addresses
Nov 21 07:53:40 MrProper ntpdate[778]: no server suitable for
synchronization found
Nov 21 07:53:46 MrProper dnsmasq[888]: reading /var/run/dnsmasq/resolv.conf
Nov 21 07:53:46 MrProper dnsmasq[888]: using nameserver 147.83.2.10#53
Nov 21 07:53:46 MrProper dnsmasq[888]: using nameserver 147.83.2.3#53
Nov 21 07:53:55 MrProper ntpdate[980]: no server suitable for
synchronization found
Nov 21 07:54:23 MrProper kernel: [ 69.620067] cfg80211: Verifying
active interfaces after reg change
It seems that there are some frequency slots wth the @8000KHz
then
root@MrProper:~# iw dev wlan0 interface add mp0 type mp
root@MrProper:~# iw dev mp0 set freq 5745 80 5775
command failed: Invalid argument (-22)
root@MrProper:~# iw dev mp0 set freq 5715 80 5860
command failed: Invalid argument (-22)
root@MrProper:~# iw dev mp0 set freq 5715 80 5795
command failed: Invalid argument (-22)
root@MrProper:~# iw dev mp0 set freq 5250 80 5330
command failed: Invalid argument (-22)
root@MrProper:~# iw dev mp0 set freq 5140 80 5360
command failed: Invalid argument (-22)
root@MrProper:~# iw dev mp0 set freq 5140 80 5220
command failed: Invalid argument (-22)
So I performed
iw dev mp0 set channel 149 HT40+
ifconfig mp0 192.168.149.201
and syslog start to spam this messge:
Nov 21 08:08:44 MrProper kernel: [ 930.230501] util.c |
ieee80211_set_wmm_default: ac=3D0, enable_qos=3Dtrue, vif.type=3D7,
NL80211_IFTYPE_STATION=3D2
Nov 21 08:08:44 MrProper kernel: [ 930.231078] IPv6:
ADDRCONF(NETDEV_UP): mp0: link is not ready
Nov 21 08:08:44 MrProper kernel: [ 930.557731] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:44 MrProper kernel: [ 930.559964] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:44 MrProper kernel: [ 930.570153] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:44 MrProper kernel: [ 930.629822] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:44 MrProper kernel: [ 930.638655] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:44 MrProper kernel: [ 930.639220] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:44 MrProper kernel: [ 930.646044] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:44 MrProper kernel: [ 930.650553] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:45 MrProper kernel: [ 930.650936] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:45 MrProper kernel: [ 930.684057] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:50 MrProper kernel: [ 935.858389] ath10k_warn: 12
callbacks suppressed
Nov 21 08:08:50 MrProper kernel: [ 935.858441] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:50 MrProper kernel: [ 936.104414] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:50 MrProper kernel: [ 936.104778] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:50 MrProper kernel: [ 936.195287] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:53 MrProper kernel: [ 938.769794] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:53 MrProper kernel: [ 939.004773] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:54 MrProper kernel: [ 939.723923] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:54 MrProper kernel: [ 939.981543] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:08:56 MrProper kernel: [ 942.534539] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:09:01 MrProper kernel: [ 947.401511] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:09:05 MrProper kernel: [ 951.507954] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:09:05 MrProper kernel: [ 951.514654] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:09:07 MrProper kernel: [ 952.837610] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:09:24 MrProper kernel: [ 970.049900] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:09:24 MrProper kernel: [ 970.050242] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:09:41 MrProper kernel: [ 987.160219] util.c |
ieee80211_set_wmm_default: ac=3D0, enable_qos=3Dtrue, vif.type=3D7,
NL80211_IFTYPE_STATION=3D2
Nov 21 08:09:41 MrProper kernel: [ 987.161400] IPv6:
ADDRCONF(NETDEV_UP): mp0: link is not ready
Nov 21 08:09:42 MrProper kernel: [ 988.010692] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 08:09:42 MrProper kernel: [ 988.488288] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
...
I had this issue in the past but only in some cases when the module
ath10k_core was loaded without the rawmode =3D 1 parameter:
Now It's happening everytime and it stops as soon as the interface
join the mesh:
Nov 21 09:29:39 MrProper kernel: [ 1409.470318] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 09:29:40 MrProper kernel: [ 1409.875986] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 09:29:40 MrProper kernel: [ 1410.496021] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 09:29:40 MrProper kernel: [ 1410.509777] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 09:29:40 MrProper kernel: [ 1410.571394] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Nov 21 09:29:43 MrProper kernel: [ 1412.762457] mp0: setting non-peer
PM to user value
Nov 21 09:29:43 MrProper kernel: [ 1412.763537] IPv6:
ADDRCONF(NETDEV_CHANGE): mp0: link becomes ready
Nov 21 09:29:43 MrProper kernel: [ 1412.941533] mp0: Allocated STA
04:f0:21:15:ac:79
Nov 21 09:29:43 MrProper kernel: [ 1412.941564] mp0: moving STA
04:f0:21:15:ac:79 to state 2
Nov 21 09:29:43 MrProper kernel: [ 1412.941581] mp0: moving STA
04:f0:21:15:ac:79 to state 3
Nov 21 09:29:43 MrProper kernel: [ 1412.941598] mp0: moving STA
04:f0:21:15:ac:79 to state 4
Nov 21 09:29:43 MrProper kernel: [ 1412.942118] mp0: Inserted STA
04:f0:21:15:ac:79
Nov 21 09:29:43 MrProper kernel: [ 1412.942174] mp0: Mesh plink:
starting establishment with 04:f0:21:15:ac:79
Nov 21 09:29:43 MrProper kernel: [ 1412.942190] mp0: setting non-peer
PM to active for peering
Nov 21 09:29:43 MrProper kernel: [ 1412.944349] mp0: peer
04:f0:21:15:ac:79 in state OPN-SNT got event OPN_ACPT
Nov 21 09:29:43 MrProper kernel: [ 1412.944653] mp0: peer
04:f0:21:15:ac:79 in state OPN-RCVD got event CNF_ACPT
Nov 21 09:29:43 MrProper kernel: [ 1412.944679] mp0: selected new HT
protection mode 0
Nov 21 09:29:43 MrProper kernel: [ 1412.944702] mp0: mesh_plink
04:f0:21:15:ac:77: ERP short slot time 1
Nov 21 09:29:43 MrProper kernel: [ 1412.944717] mp0: Mesh plink with
04:f0:21:15:ac:79 ESTABLISHED
Nov 21 09:29:43 MrProper kernel: [ 1412.944734] mp0: local STA
operates in mode 1 with 04:f0:21:15:ac:79
Nov 21 09:29:43 MrProper kernel: [ 1412.944755] mp0: announcing
peer-specific power mode to 04:f0:21:15:ac:79
Nov 21 09:29:43 MrProper kernel: [ 1412.944794] mp0: setting non-peer
PM to user value
Nov 21 09:29:43 MrProper kernel: [ 1413.117282] mp0: Allocated STA
e0:ca:94:5f:a7:d6
Nov 21 09:29:43 MrProper kernel: [ 1413.117312] mp0: moving STA
e0:ca:94:5f:a7:d6 to state 2
Nov 21 09:29:43 MrProper kernel: [ 1413.117333] mp0: moving STA
e0:ca:94:5f:a7:d6 to state 3
Nov 21 09:29:43 MrProper kernel: [ 1413.117350] mp0: moving STA
e0:ca:94:5f:a7:d6 to state 4
Nov 21 09:29:43 MrProper kernel: [ 1413.117882] mp0: Inserted STA
e0:ca:94:5f:a7:d6
Nov 21 09:29:43 MrProper kernel: [ 1413.117941] mp0: Mesh plink:
starting establishment with e0:ca:94:5f:a7:d6
Nov 21 09:29:43 MrProper kernel: [ 1413.117957] mp0: setting non-peer
PM to active for peering
Nov 21 09:29:43 MrProper kernel: [ 1413.121287] mp0: peer
e0:ca:94:5f:a7:d6 in state OPN-SNT got event OPN_ACPT
Nov 21 09:29:43 MrProper kernel: [ 1413.121387] mp0: peer
e0:ca:94:5f:a7:d6 in state OPN-RCVD got event CNF_ACPT
Nov 21 09:29:43 MrProper kernel: [ 1413.121410] mp0: nonHT sta
(e0:ca:94:5f:a7:d6) is present
Nov 21 09:29:43 MrProper kernel: [ 1413.121426] mp0: selected new HT
protection mode 3
Nov 21 09:29:43 MrProper kernel: [ 1413.121443] mp0: Mesh plink with
e0:ca:94:5f:a7:d6 ESTABLISHED
Nov 21 09:29:43 MrProper kernel: [ 1413.121461] mp0: local STA
operates in mode 1 with e0:ca:94:5f:a7:d6
Nov 21 09:29:43 MrProper kernel: [ 1413.121478] mp0: announcing
peer-specific power mode to e0:ca:94:5f:a7:d6
Nov 21 09:29:43 MrProper kernel: [ 1413.121514] mp0: setting non-peer
PM to user value
Nov 21 09:29:43 MrProper kernel: [ 1413.122713] mp0: STA
e0:ca:94:5f:a7:d6 enters mode 1
Other (hopefully) useful info:
root@MrProper:~# iw reg get
global
country US: DFS-UNSET
(2402 - 2472 @ 40), (3, 27), (N/A)
(5170 - 5250 @ 40), (3, 17), (N/A)
(5250 - 5330 @ 40), (3, 20), (0 ms), DFS
(5490 - 5600 @ 40), (3, 20), (0 ms), DFS
(5650 - 5710 @ 40), (3, 20), (0 ms), DFS
(5735 - 5835 @ 40), (3, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
phy#2
country US: DFS-UNSET
(2402 - 2472 @ 40), (3, 27), (N/A)
(5170 - 5250 @ 40), (3, 17), (N/A)
(5250 - 5330 @ 40), (3, 20), (0 ms), DFS
(5490 - 5600 @ 40), (3, 20), (0 ms), DFS
(5650 - 5710 @ 40), (3, 20), (0 ms), DFS
(5735 - 5835 @ 40), (3, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
phy#0
country US: DFS-UNSET
(2402 - 2472 @ 40), (3, 27), (N/A)
(5170 - 5250 @ 40), (3, 17), (N/A)
(5250 - 5330 @ 40), (3, 20), (0 ms), DFS
(5490 - 5600 @ 40), (3, 20), (0 ms), DFS
(5650 - 5710 @ 40), (3, 20), (0 ms), DFS
(5735 - 5835 @ 40), (3, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
phy#1
country US: DFS-UNSET
(2402 - 2472 @ 40), (3, 27), (N/A)
(5170 - 5250 @ 40), (3, 17), (N/A)
(5250 - 5330 @ 40), (3, 20), (0 ms), DFS
(5490 - 5600 @ 40), (3, 20), (0 ms), DFS
(5650 - 5710 @ 40), (3, 20), (0 ms), DFS
(5735 - 5835 @ 40), (3, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
root@MrProper:~# iw dev wlan0 info #Compex WLE600V5-27 ath10k QCA988X
Interface wlan0
ifindex 9
wdev 0x200000001
addr 04:f0:21:15:ac:77
type managed
wiphy 2
txpower 0.00 dBm
root@MrProper:~# iw dev mp0 info #Virtual interface acting as mesh point
Interface mp0
ifindex 10
wdev 0x200000002
addr 04:f0:21:15:ac:77
type mesh point
wiphy 2
txpower 0.00 dBm
root@MrProper:~# iw dev wlan3 info #Compex WLE-200NX ath9k
Interface wlan3
ifindex 7
wdev 0x100000001
addr 04:f0:21:0a:6c:7c
type managed
wiphy 1
txpower 0.00 dBm
root@MrProper:~# iw dev mp0 info #Virtual mp interface after join the
mesh network
Interface mp0
ifindex 11
wdev 0x100000002
addr 04:f0:21:15:ac:77
type mesh point
wiphy 1
channel 48 (5240 MHz), width: 40 MHz, center1: 5230 MHz
txpower 17.00 dBm
root@MrProper:~# iw --version
iw version 4.9
Checking on Internet I didn't find a working solution, and the data
rate stucks to 120Mbps MCS7.
For me it still a mistery, I hope in your help.
All the Best
Matteo
2016-11-20 12:09 GMT+01:00 Michal Kazior <michal.kazior@tieto.com>:
> On 20 November 2016 at 02:07, Bob Copeland <me@bobcopeland.com> wrote:
>> On Fri, Nov 18, 2016 at 10:43:06PM +0100, Matteo Grandi wrote:
>>> So the question is: who decide if use MIMO and higher MCS hopefully on
>>> 80MHz channel or not? Is the firmware? Is there a way to force the
>>> interface to use 80MHz and/or MIMO? (iw provide the possibility to
>>> choose between [HT20/HT40-/HT40+]).
>>
>> You can specify the channel width like so:
>>
>> iw dev wlan0 set freq 5745 80 5775
>> iw dev wlan0 mesh join mesh-vht
>
> With recent enough `iw` you can check the operational (max) bandwidth
> of the interface with:
>
> iw dev wlan0 info
>
> I don't know how mesh nodes negotiate their capabilities to each other
> though so I don't know how reliable this is.
>
> Actual modulation is picked by rate control in firmware. You can try
> to force a fixed rate with[1]:
>
> iw dev wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:9
>
> It doesn't allow setting fixed bandwidth though so you'll need to
> check rx bitrate on the receiving end to verify.
>
> [1]: https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug?s[]=
=3Dset&s[]=3Dbitrates#manual_bitrates_configuration
>
>
> Micha=C5=82
^ permalink raw reply
* Re: BCM4356 + Ubuntu 16.10
From: Arend Van Spriel @ 2016-11-21 9:34 UTC (permalink / raw)
To: Familie Stepniak
Cc: mailto:brcm80211-dev-list.pdl@broadcom.com, linux-wireless
In-Reply-To: <AM3PR06MB1043FFF175E7DB0D4DB510D9A3B20@AM3PR06MB1043.eurprd06.prod.outlook.com>
+ linux-wireless
On 20-11-2016 14:26, Familie Stepniak wrote:
> Hi,
>
> I try run Ubuntu 16.10 on the Trekstor W2 Tablet but Wi-Fi donts work..
> that find WLAN-Network, I give to Passwort and Nothing.. the chip ist
> BCM4356B.. please Help me to install the true Driver on the Linux-Ubuntu..
Not sure what "true Driver" means, but let me see if I can help. First
see if I understand your issue. So you were able to select to WLAN
network and got a pop-up to provide the password. After that you are not
getting a connection. Is this right?
So is this a first attempt to run Ubuntu on it or have you been able to
run older version.
Can you do the following:
- open a terminal.
- run following commands (assuming wlan0):
$ iw dev
$ iw list
$ lspci
$ sudo nmcli nm wifi off
$ sudo rfkill unblock wifi
$ sudo ifconfig wlan0 up
$ sudo iw wlan0 scan
$ dmesg
- send me output of all these commands.
Regards,
Arend
^ permalink raw reply
* Re: [ath9k-devel] [RFC v2 2/2] ath9k: Reset chip on potential deaf state
From: Ferry Huberts @ 2016-11-21 9:15 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: ath9k-devel, linux-wireless, ath9k-devel, Simon Wunderlich
In-Reply-To: <2358985.PI5q6nxgha@bentobox>
On 21/11/16 10:10, Sven Eckelmann wrote:
> On Montag, 21. November 2016 10:07:43 CET Ferry Huberts wrote:
> [...]
>>> v2:
>>> - reduce amount of possible goto-raptor attacks by one (thanks Kalle Valo)
>>>
>>> This problem was discovered in mesh setups. It was noticed that some nodes
>>
>>
>> What kind of setup?
>> Using 802.11s?
>
> Unencrypted IBSS.
>
ok, thanks. that is different then.
I _can_ tell you that using the high priority queue (EF class traffic)
seems to somehow 'unwedge' the chip during/after rekeying. Still have to
verify this again, but that is what I saw last week.
^ permalink raw reply
* Re: [ath9k-devel] [RFC v2 2/2] ath9k: Reset chip on potential deaf state
From: Sven Eckelmann @ 2016-11-21 9:10 UTC (permalink / raw)
To: Ferry Huberts; +Cc: ath9k-devel, linux-wireless, ath9k-devel, Simon Wunderlich
In-Reply-To: <d23407cb-a1c0-860a-3436-5e72402a080b@hupie.com>
[-- Attachment #1: Type: text/plain, Size: 324 bytes --]
On Montag, 21. November 2016 10:07:43 CET Ferry Huberts wrote:
[...]
> > v2:
> > - reduce amount of possible goto-raptor attacks by one (thanks Kalle Valo)
> >
> > This problem was discovered in mesh setups. It was noticed that some nodes
>
>
> What kind of setup?
> Using 802.11s?
Unencrypted IBSS.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [ath9k-devel] [RFC v2 2/2] ath9k: Reset chip on potential deaf state
From: Ferry Huberts @ 2016-11-21 9:07 UTC (permalink / raw)
To: Sven Eckelmann, ath9k-devel; +Cc: linux-wireless, ath9k-devel, Simon Wunderlich
In-Reply-To: <20161117083614.19188-2-sven.eckelmann@open-mesh.com>
On 17/11/16 09:36, Sven Eckelmann wrote:
> From: Simon Wunderlich <simon.wunderlich@open-mesh.com>
>
> The chip is switching seemingly random into a state which can be described
> as "deaf". No or nearly no interrupts are generated anymore for incoming
> packets. Existing links either break down after a while and new links will
> not be established.
>
> The driver doesn't know if there is no other device available or if it
> ended up in an "deaf" state. Resetting the chip proactively avoids
> permanent problems in case the chip really was in its "deaf" state but
> maybe causes unnecessary resets in case it wasn't "deaf".
>
> Signed-off-by: Simon Wunderlich <simon.wunderlich@open-mesh.com>
> [sven.eckelmann@open-mesh.com: port to recent ath9k, add commit message]
> Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
> ---
> v2:
> - reduce amount of possible goto-raptor attacks by one (thanks Kalle Valo)
>
> This problem was discovered in mesh setups. It was noticed that some nodes
What kind of setup?
Using 802.11s?
I ask this because I have almost completed a patch for authsae that
checks rekey.
The problems there might show as the behaviour described here.
> were not able to see their neighbors (mostly after running for a while) -
> even when those neighbors received data from them via IBSS. A simple `iw
> dev wlan0 scan` fixed the problem for them. But the problem seems to
> reappear after while(tm) in a large enough(tm) mesh.
>
> This patch is a little bit obscure because it requires CONFIG_ATH9K_DEBUGFS
> to actually work. But there still seems to be potential interest in
> Freifunk communities or Freifunk meta-projects (e.g. freifunk-gluon). It is
> currently not known if it helps them but publishing this to allow them to
> test and play around with it will not hurt :)
> ---
> drivers/net/wireless/ath/ath9k/ath9k.h | 3 +++
> drivers/net/wireless/ath/ath9k/debug.c | 1 +
> drivers/net/wireless/ath/ath9k/debug.h | 1 +
> drivers/net/wireless/ath/ath9k/link.c | 48 +++++++++++++++++++++++++++++++++-
> 4 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
> index 9c6fee7..3987ad5 100644
> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
> @@ -996,6 +996,9 @@ struct ath_softc {
> short nbcnvifs;
> unsigned long ps_usecount;
>
> + unsigned long last_check_time;
> + u32 last_check_interrupts;
> +
> struct ath_rx rx;
> struct ath_tx tx;
> struct ath_beacon beacon;
> diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
> index 608b370..6d5c253 100644
> --- a/drivers/net/wireless/ath/ath9k/debug.c
> +++ b/drivers/net/wireless/ath/ath9k/debug.c
> @@ -768,6 +768,7 @@ static int read_file_reset(struct seq_file *file, void *data)
> [RESET_TX_DMA_ERROR] = "Tx DMA stop error",
> [RESET_RX_DMA_ERROR] = "Rx DMA stop error",
> [RESET_TYPE_DEADBEEF] = "deadbeef hang",
> + [RESET_TYPE_DEAF] = "deaf hang",
> };
> int i;
>
> diff --git a/drivers/net/wireless/ath/ath9k/debug.h b/drivers/net/wireless/ath/ath9k/debug.h
> index 0d77abbf6..6f186bd 100644
> --- a/drivers/net/wireless/ath/ath9k/debug.h
> +++ b/drivers/net/wireless/ath/ath9k/debug.h
> @@ -53,6 +53,7 @@ enum ath_reset_type {
> RESET_TX_DMA_ERROR,
> RESET_RX_DMA_ERROR,
> RESET_TYPE_DEADBEEF,
> + RESET_TYPE_DEAF,
> __RESET_TYPE_MAX
> };
>
> diff --git a/drivers/net/wireless/ath/ath9k/link.c b/drivers/net/wireless/ath/ath9k/link.c
> index 04195d5..ae99c02 100644
> --- a/drivers/net/wireless/ath/ath9k/link.c
> +++ b/drivers/net/wireless/ath/ath9k/link.c
> @@ -158,13 +158,59 @@ static bool ath_hw_hang_deadbeef(struct ath_softc *sc)
> return true;
> }
>
> +static bool ath_hw_hang_deaf(struct ath_softc *sc)
> +{
> +#ifndef CONFIG_ATH9K_DEBUGFS
> + return false;
> +#else
> + struct ath_common *common = ath9k_hw_common(sc->sc_ah);
> + u32 interrupts, interrupt_per_s;
> + unsigned int interval;
> +
> + /* get historic data */
> + interval = jiffies_to_msecs(jiffies - sc->last_check_time);
> + if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_EDMA)
> + interrupts = sc->debug.stats.istats.rxlp;
> + else
> + interrupts = sc->debug.stats.istats.rxok;
> +
> + interrupts -= sc->last_check_interrupts;
> +
> + /* save current data */
> + sc->last_check_time = jiffies;
> + if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_EDMA)
> + sc->last_check_interrupts = sc->debug.stats.istats.rxlp;
> + else
> + sc->last_check_interrupts = sc->debug.stats.istats.rxok;
> +
> + /* sanity check, should be 30 seconds */
> + if (interval > 40000 || interval < 20000)
> + return false;
> +
> + /* should be at least one interrupt per second */
> + interrupt_per_s = interrupts / (interval / 1000);
> + if (interrupt_per_s >= 1)
> + return false;
> +
> + ath_dbg(common, RESET,
> + "RX deaf hang is detected. Schedule chip reset\n");
> + ath9k_queue_reset(sc, RESET_TYPE_DEAF);
> +
> + return true;
> +#endif
> +}
> +
> void ath_hw_hang_work(struct work_struct *work)
> {
> struct ath_softc *sc = container_of(work, struct ath_softc,
> hw_hang_work.work);
>
> - ath_hw_hang_deadbeef(sc);
> + if (ath_hw_hang_deadbeef(sc))
> + goto requeue_worker;
> +
> + ath_hw_hang_deaf(sc);
>
> +requeue_worker:
> ieee80211_queue_delayed_work(sc->hw, &sc->hw_hang_work,
> msecs_to_jiffies(ATH_HANG_WORK_INTERVAL));
> }
>
--
Ferry Huberts
^ permalink raw reply
* form factor subsystem (Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support)
From: Johannes Berg @ 2016-11-21 8:50 UTC (permalink / raw)
To: Wei-Ning Huang, Linux-Wireless, Luca Coelho, haim.dreyfuss
Cc: Sameer Nanda, Todd Broch, linux-kernel
In-Reply-To: <1462430663-9448-1-git-send-email-wnhuang@chromium.org>
Hi,
I'm revisiting this since we're asked to do the same for iwlwifi.
On Thu, 2016-05-05 at 14:44 +0800, Wei-Ning Huang wrote:
> Recent new hardware has the ability to switch between tablet mode and
> clamshell mode. To optimize WiFi performance, we want to be able to
> use different power table between modes. This patch adds a new
> netlink message type and cfg80211_ops function to allow userspace to
> trigger a power mode switch for a given wireless interface.
I've thought about this a bit more, and also heard this in different
contexts now, and I'm actually not convinced that the wifi subsystem
exposing this *in any way* is the right thing to do.
Why don't we add a minimal "form factor" subsystem to the kernel?
Something that allows
1) sensor/BIOS/... drivers to call a function to switch form factor
2) consumers to register and get callbacks when switching happens
If the sensor driver is in the kernel (some kind of driver probably has
to be anyway), or form factor switch ends up being a BIOS notification,
then this gets rid of a lot of complexity - no more need to bump this
through userspace etc.
If, for some reason, the sensor driver really has to be in userspace,
then some kind of API *to this subsystem* can be implemented to set the
form factor mode from userspace, and all the other stuff can be left as
is.
This would also allow other clients to know about this information,
let's say, for the sake of an argument that doesn't seem *too* far-
fetched, that the compass driver needs to adjust the direction if you
switch modes.
It seems to me that this would be more robust, which can only be a good
thing if we start using it for things that might be regulatory
relevant.
Additionally, the subsystem could allow userspace to also get an event
if it wants to know about this, e.g. to switch to a more touch-friendly
UI on switching to tablet mode, or something.
Thoughts?
johannes
^ permalink raw reply
* RE: Problems getting mwifiex with sd8887 to work
From: Amitkumar Karwar @ 2016-11-21 7:07 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-wireless@vger.kernel.org, Nishant Sarmukadam, Kalle Valo
In-Reply-To: <20161113141348.GA32086@katana>
Hi Wolfram,
> From: Wolfram Sang [mailto:wsa@the-dreams.de]
> Sent: Sunday, November 13, 2016 7:44 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Nishant Sarmukadam; Kalle Valo
> Subject: Re: Problems getting mwifiex with sd8887 to work
>
> > 0x242 command failure is expected for sd8887, as It's not supported.
>
> Is the same true for 0x10f?
>
> mwifiex_sdio mmc2:0001:1: CMD_RESP: cmd 0x10f error, result=0x2
>
> Otherwise I can connect to the network and run performance tests now.
Error code 2 from firmware is unsupported command. You can ignore this and earlier
error seen for 0x242 command. They aren't harmful.
Regards,
Amitkumar
^ permalink raw reply
* Re: [PATCH 4.9.0-rc5] AR9300 calibration problems with antenna selected
From: miaoqing @ 2016-11-21 5:48 UTC (permalink / raw)
To: Krzysztof Hałasa, ath9k-devel, Kalle Valo, linux-wireless,
ath9k-devel, netdev, linux-kernel
In-Reply-To: <61055e757c5645dfb69da3fc555cbcf5@aptaiexm02f.ap.qualcomm.com>
I would prefer that you didn't submit this.
>
> I recently tried to select a single antenna on AR9300 and it works for
> 30 seconds only. The subsequent calibration makes the RX signal level
> to drop from the usual -30/-40 dBm to -70/-80 dBm, and the
> transmission practically stops.
>
> With the attached patch it works, though selecting the antenna doesn't
> seem to have any visible effect, at least with "iw wlanX station dump"
> (perhaps it works for TX).
>
> I'm using ad-hoc mode:
>
> rmmod ath9k
> modprobe ath9k
> iw dev wlan0 set type ibss
> iw phy phyX set antenna 2
2 is a bad mask. We use bitmap, the valid masks are 1, 3, 7.
--
Miaoqing
^ permalink raw reply
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