* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-11-21 15:51 UTC (permalink / raw)
To: Kalle Valo, Pavel Machek, Ivaylo Dimitrov, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <201611111820.52072@pali>
On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
> Hi! I will open discussion about mac address and calibration data for
> wl1251 wireless chip again...
>
> Problem: Mac address & calibration data for wl1251 chip on Nokia N900
> are stored on second nand partition (mtd1) in special proprietary format
> which is used only for Nokia N900 (probably on N8x0 and N9 too).
> Wireless driver wl1251.ko cannot work without mac address and
> calibration data.
>
> Absence of mac address cause that driver generates random mac address at
> every kernel boot which has couple of problems (unstable identifier of
> wireless device due to udev permanent storage rules; unpredictable
> behaviour for dhcp mac address assignment, mac address filtering, ...).
>
> Currently there is no way to set (permanent) mac address for network
> interface from userspace. And it does not make sense to implement in
> linux kernel large parser for proprietary format of second nand
> partition where is mac address stored only for one device -- Nokia N900.
>
> Driver wl1251.ko loads calibration data via request_firmware() for file
> wl1251-nvs.bin. There are some "example" calibration file in linux-
> firmware repository, but it is not suitable for normal usage as real
> calibration data are per-device specific.
>
> So questions are:
>
> 1) How to set mac address from userspace for that wl1251 interface? In
> userspace I can write parser for that proprietary format of nand
> partition and extract mac address from it
Proposed solutions for 1)
* Introduce new IOCL for setting that permanent mac address from
userspace. Currently we have IOCL for get request
* Use request_firmware() (with flag from 2)) to ask for mac address from
userspace. This is already used by wl12xx driver (as mac address is
part of calibration data firmware file)
* Allow to set mac address via sysfs file, e.g.
/sys/class/ieee80211/phy0/macaddress
> 2) How to send calibration data to wl1251 driver? Those are again stored
> in proprietary format and I can write userspace parser for it.
Proposed solution for 2)
Introduce new flag for request_firmware(), so it first try to use
userspace helper for loading firmware file with possibility to fallback
to direct VFS access.
So... what do you think about it?
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [ath9k-devel] [PATCH] ath9k: Prevent radar detection and spectral scan to be used concurrently
From: Michal Kazior @ 2016-11-21 15:10 UTC (permalink / raw)
To: Zefir Kurtisi
Cc: Benjamin Berg, Kalle Valo, ath9k-devel@lists.ath9k.org,
linux-wireless
In-Reply-To: <7d04126f-0f24-b4a4-6d13-6f52046d7671@neratec.com>
On 21 November 2016 at 15:41, Zefir Kurtisi <zefir.kurtisi@neratec.com> wro=
te:
> On 11/21/2016 03:04 PM, Benjamin Berg wrote:
>> 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.
>>
>> [...]
>
> From the relevant source code portion in channel.c:ath_set_channel()
>
> 80 /* Enable radar pulse detection if on a DFS channel. Spectral
> 81 * scanning and radar detection can not be used concurrently.
> 82 */
> 83 if (hw->conf.radar_enabled) {
> 84 u32 rxfilter;
> 85
> 86 rxfilter =3D ath9k_hw_getrxfilter(ah);
> 87 rxfilter |=3D ATH9K_RX_FILTER_PHYRADAR |
> 88 ATH9K_RX_FILTER_PHYERR;
> 89 ath9k_hw_setrxfilter(ah, rxfilter);
> 90 ath_dbg(common, DFS, "DFS enabled at freq %d\n",
> 91 chan->center_freq);
> 92 } else {
> 93 /* perform spectral scan if requested. */
> 94 if (test_bit(ATH_OP_SCANNING, &common->op_flags) &&
> 95 sc->spec_priv.spectral_mode =3D=3D SPECTRAL_CH=
ANSCAN)
> 96 ath9k_cmn_spectral_scan_trigger(common, &sc->s=
pec_priv);
> 97 }
>
> it seems that spectral can't ever be activated while operating on a DFS c=
hannel.
>
> If you need to catch the opposite case, i.e. prevent feeding pseudo-radar=
pulses
> into the pattern detector, you just need to ensure that they depend on
> hw->conf.radar_enabled. A patch like the attached one should be enough.
Good point. I guess set_channel could be oversimplified as well. I
mean, it makes sense to consider radar and spectral mutually exclusive
if they use the same phyerr code. However some chips actually seem (as
per the comment I mentioned) to distinguish the two so I don't know if
the "mutually exclusive" is true for all chips per se. Just thinking
out loud.
I also wonder if calling ieee80211_radar_detect() should have any
effect if there are no radar operated interfaces in the first place?
Micha=C5=82
^ permalink raw reply
* Re: scheduled scan interval
From: Luca Coelho @ 2016-11-21 15:08 UTC (permalink / raw)
To: Arend Van Spriel, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <e176de78-6ab3-ad83-5e9d-082ceb85d786@broadcom.com>
Hi Arend,
On Mon, 2016-11-21 at 13:03 +0100, Arend Van Spriel wrote:
> 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.
With the introduction of scheduled scan plans, we sort of deprecated
the "generic" scheduled scan interval. It doesn't make sense to have
both passed at the same time, so nl80211 forbids
NL80211_ATTR_SCHED_SCAN_INTERVAL if we pass
NL80211_ATTR_SCHED_SCAN_PLANS.
The original NL80211_ATTR_SCHED_SCAN_INTERVAL was specified in msecs,
which is silly because we can never get millisecond accuracy in this.
Thus, in the plans API, we decided to use seconds instead (because it
makes much more sense). Additionally, the interval is considered
"advisory", because the FW may not be able guarantee the exact
intervals (for instance, the iwlwifi driver actually starts the
interval timer after scan completion, so if you specify 10 seconds
intervals, in practice they'll be 13-14 seconds).
I'm not sure I'm answering your question, because I'm also not sure I
understood the question. :)
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] ath9k: Prevent radar detection and spectral scan to be used concurrently
From: Zefir Kurtisi @ 2016-11-21 14:41 UTC (permalink / raw)
To: Benjamin Berg, Kalle Valo
Cc: ath9k-devel, linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <20161121140423.24367-1-benjamin@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]
On 11/21/2016 03:04 PM, Benjamin Berg wrote:
> 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.
>
> [...]
>From the relevant source code portion in channel.c:ath_set_channel()
80 /* Enable radar pulse detection if on a DFS channel. Spectral
81 * scanning and radar detection can not be used concurrently.
82 */
83 if (hw->conf.radar_enabled) {
84 u32 rxfilter;
85
86 rxfilter = ath9k_hw_getrxfilter(ah);
87 rxfilter |= ATH9K_RX_FILTER_PHYRADAR |
88 ATH9K_RX_FILTER_PHYERR;
89 ath9k_hw_setrxfilter(ah, rxfilter);
90 ath_dbg(common, DFS, "DFS enabled at freq %d\n",
91 chan->center_freq);
92 } else {
93 /* perform spectral scan if requested. */
94 if (test_bit(ATH_OP_SCANNING, &common->op_flags) &&
95 sc->spec_priv.spectral_mode == SPECTRAL_CHANSCAN)
96 ath9k_cmn_spectral_scan_trigger(common, &sc->spec_priv);
97 }
it seems that spectral can't ever be activated while operating on a DFS channel.
If you need to catch the opposite case, i.e. prevent feeding pseudo-radar pulses
into the pattern detector, you just need to ensure that they depend on
hw->conf.radar_enabled. A patch like the attached one should be enough.
Cheers,
Zefir
[-- Attachment #2: 0001-ath9k-feed-DFS-detector-only-if-operating-on-radar-c.patch --]
[-- Type: text/x-patch, Size: 986 bytes --]
>From c24edf82e1f509490ba9dd3e34eec3ac3b309321 Mon Sep 17 00:00:00 2001
From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Date: Mon, 21 Nov 2016 15:33:45 +0100
Subject: [PATCH] ath9k: feed DFS detector only if operating on radar channel
---
drivers/net/wireless/ath/ath9k/recv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 6697342..e4701a7 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -867,7 +867,8 @@ 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 (hw->conf.radar_enabled)
+ 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))
RX_STAT_INC(rx_spectral);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 4.9.0-rc5] AR9300 calibration problems with antenna selected
From: Matthias May @ 2016-11-21 14:11 UTC (permalink / raw)
To: Krzysztof Hałasa
Cc: miaoqing, ath9k-devel, Kalle Valo, linux-wireless, ath9k-devel,
netdev, linux-kernel
In-Reply-To: <m3d1hp2b0z.fsf@t19.piap.pl>
On 21/11/16 14:54, Krzysztof Hałasa wrote:
> 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?
>
No this is not really possible.
We have been playing around with this two, three years ago with this.
There are just too many things which rely on chain0
Noise calibration, DFS, Temperature measurement, Spectrum measurement
are just a few of the things I remember which don't work realiably anymore.
See [1] for more.
BR
Matthias
[1]
http://ath9k-devel.ath9k.narkive.com/QZcobwy1/ath9k-deaf-qca9558-when-setting-rxchainmask#post1
^ permalink raw reply
* Re: [PATCH] ath9k: Prevent radar detection and spectral scan to be used concurrently
From: Michal Kazior @ 2016-11-21 14:16 UTC (permalink / raw)
To: Benjamin Berg
Cc: Kalle Valo, ath9k-devel@lists.ath9k.org, linux-wireless,
Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <20161121140423.24367-1-benjamin@sipsolutions.net>
On 21 November 2016 at 15:04, Benjamin Berg <benjamin@sipsolutions.net> wro=
te:
> 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.
According to the comment in ath_cmn_process_fft() this doesn't seem to
be necessary for all chips:
515 /* AR9280 and before report via ATH9K_PHYERR_RADAR,
AR93xx and newer
516 * via ATH9K_PHYERR_SPECTRAL. Haven't seen
ATH9K_PHYERR_FALSE_RADAR_EXT
517 * yet, but this is supposed to be possible as well.
518 */
519 if (rs->rs_phyerr !=3D ATH9K_PHYERR_RADAR &&
520 rs->rs_phyerr !=3D ATH9K_PHYERR_FALSE_RADAR_EXT &&
521 rs->rs_phyerr !=3D ATH9K_PHYERR_SPECTRAL)
522 return 0;
Micha=C5=82
^ permalink raw reply
* [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
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