Re: [PATCH] ssb: Reenable PCI host on !MIPS
On Sat, Jan 27, 2018 at 06:29:18AM +0200, Kalle Valo wrote:
> Krzysztof Mazur writes:
>
> > The commit 58eae1416b804d900014d84feadda7195007cc30
> > ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC") disabled
> > CONFIG_SSB_PCIHOST and CONFIG_SSB_B43_PCI_BRIDGE, which are
> > required for SSB-based b43 PCI cards, on everything except MIPS
> > with PCI_DRIVERS_LEGACY, including x86 (only MIPS defines
> > that config option). Reenable it.
> >
> > Signed-off-by: Krzysztof Mazur
>
> I have already applied an identical patch but missed the deadline for
> final 4.15:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=a9e6d44ddeccd3522670e641f1ed9b068e746ff7
>
> That patch will go to 4.16 and from there to 4.15 via the stable tree.
Thanks,
Krzysiek
Re: [PATCH] ssb: Reenable PCI host on !MIPS
Krzysztof Mazur writes:
> The commit 58eae1416b804d900014d84feadda7195007cc30
> ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC") disabled
> CONFIG_SSB_PCIHOST and CONFIG_SSB_B43_PCI_BRIDGE, which are
> required for SSB-based b43 PCI cards, on everything except MIPS
> with PCI_DRIVERS_LEGACY, including x86 (only MIPS defines
> that config option). Reenable it.
>
> Signed-off-by: Krzysztof Mazur
I have already applied an identical patch but missed the deadline for
final 4.15:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=a9e6d44ddeccd3522670e641f1ed9b068e746ff7
That patch will go to 4.16 and from there to 4.15 via the stable tree.
--
Kalle Valo
[PATCH v2] mac80211: Add txq flags to debugfs
From: Ben Greear
Might help one figure out why aqm drivers may fail to transmit
frames sometimes.
Signed-off-by: Ben Greear
---
v2: Fix checking wrong flag for NO-AMSDU
net/mac80211/debugfs_sta.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index b15412c..bf101bd 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -160,12 +160,12 @@ static ssize_t sta_aqm_read(struct file *file, char
__user *userbuf,
sta->cparams.ecn ? "yes" : "no");
p += scnprintf(p,
bufsz+buf-p,
- "tid ac backlog-bytes backlog-packets new-flows drops
marks overlimit collisions tx-bytes tx-packets\n");
+ "tid ac backlog-bytes backlog-packets new-flows drops
marks overlimit collisions tx-bytes tx-packets flags\n");
for (i = 0; i < IEEE80211_NUM_TIDS; i++) {
txqi = to_txq_info(sta->sta.txq[i]);
p += scnprintf(p, bufsz+buf-p,
- "%d %d %u %u %u %u %u %u %u %u %u\n",
+ "%d %d %u %u %u %u %u %u %u %u %u
0x%lx(%s%s%s)\n",
txqi->txq.tid,
txqi->txq.ac,
txqi->tin.backlog_bytes,
@@ -176,7 +176,11 @@ static ssize_t sta_aqm_read(struct file *file, char __user
*userbuf,
txqi->tin.overlimit,
txqi->tin.collisions,
txqi->tin.tx_bytes,
- txqi->tin.tx_packets);
+ txqi->tin.tx_packets,
+ txqi->flags,
+ txqi->flags & (1
[PATCH] mac80211: Add txq flags to debugfs
From: Ben Greear
Might help one figure out why aqm drivers may fail to transmit
frames sometimes.
Signed-off-by: Ben Greear
---
net/mac80211/debugfs_sta.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index b15412c..570bc27 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -160,12 +160,12 @@ static ssize_t sta_aqm_read(struct file *file, char
__user *userbuf,
sta->cparams.ecn ? "yes" : "no");
p += scnprintf(p,
bufsz+buf-p,
- "tid ac backlog-bytes backlog-packets new-flows drops
marks overlimit collisions tx-bytes tx-packets\n");
+ "tid ac backlog-bytes backlog-packets new-flows drops
marks overlimit collisions tx-bytes tx-packets flags\n");
for (i = 0; i < IEEE80211_NUM_TIDS; i++) {
txqi = to_txq_info(sta->sta.txq[i]);
p += scnprintf(p, bufsz+buf-p,
- "%d %d %u %u %u %u %u %u %u %u %u\n",
+ "%d %d %u %u %u %u %u %u %u %u %u
0x%lx(%s%s%s)\n",
txqi->txq.tid,
txqi->txq.ac,
txqi->tin.backlog_bytes,
@@ -176,7 +176,11 @@ static ssize_t sta_aqm_read(struct file *file, char __user
*userbuf,
txqi->tin.overlimit,
txqi->tin.collisions,
txqi->tin.tx_bytes,
- txqi->tin.tx_packets);
+ txqi->tin.tx_packets,
+ txqi->flags,
+ txqi->flags & (1
[PATCH] ath9k: Print has_queued in debugfs.
From: Ben Greear
The PAUSED field was never printed per tid. Replace that
with has_queued, which might help someone track down strange
bugs related to aqm.
And, make tx-queue debug info show peer BSSID as well as vdev
MAC to aid debugging with multiple stations connected to the
same peer.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath9k/debug_sta.c | 10 ++
drivers/net/wireless/ath/ath9k/xmit.c | 5 +++--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug_sta.c
b/drivers/net/wireless/ath/ath9k/debug_sta.c
index efc692e..a45f1f5 100644
--- a/drivers/net/wireless/ath/ath9k/debug_sta.c
+++ b/drivers/net/wireless/ath/ath9k/debug_sta.c
@@ -48,9 +48,10 @@ static ssize_t read_file_node_aggr(struct file *file, char
__user *user_buf,
an->mpdudensity);
len += scnprintf(buf + len, size - len,
-"\n%3s%11s%10s%10s%10s%10s%9s%6s%8s\n",
+"\n%3s%11s%10s%10s%10s%10s%9s%6s%9s\n",
"TID", "SEQ_START", "SEQ_NEXT", "BAW_SIZE",
-"BAW_HEAD", "BAW_TAIL", "BAR_IDX", "SCHED", "PAUSED");
+"BAW_HEAD", "BAW_TAIL", "BAR_IDX", "SCHED",
+"HAS-QUED");
for (tidno = 0; tidno < IEEE80211_NUM_TIDS; tidno++) {
tid = ath_node_to_tid(an, tidno);
@@ -58,7 +59,7 @@ static ssize_t read_file_node_aggr(struct file *file, char
__user *user_buf,
ath_txq_lock(sc, txq);
if (tid->active) {
len += scnprintf(buf + len, size - len,
-"%3d%11d%10d%10d%10d%10d%9d%6d\n",
+"%3d%11d%10d%10d%10d%10d%9d%6d%9d\n",
tid->tidno,
tid->seq_start,
tid->seq_next,
@@ -66,7 +67,8 @@ static ssize_t read_file_node_aggr(struct file *file, char
__user *user_buf,
tid->baw_head,
tid->baw_tail,
tid->bar_index,
-!list_empty(&tid->list));
+!list_empty(&tid->list),
+tid->has_queued);
}
ath_txq_unlock(sc, txq);
}
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
b/drivers/net/wireless/ath/ath9k/xmit.c
index 26bf9d4..c28f62f 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -157,8 +157,9 @@ void ath9k_wake_tx_queue(struct ieee80211_hw *hw, struct
ieee80211_txq *queue)
struct ath_atx_tid *tid = (struct ath_atx_tid *) queue->drv_priv;
struct ath_txq *txq = tid->txq;
- ath_dbg(common, QUEUE, "Waking TX queue: %pM (%d)\n",
- queue->sta ? queue->sta->addr : queue->vif->addr,
+ ath_dbg(common, QUEUE,
+ "Waking TX queue: sta-addr %pM vif: %pM (tid %d)\n",
+ queue->sta ? queue->sta->addr : NULL, queue->vif->addr,
tid->tidno);
ath_txq_lock(sc, txq);
--
2.4.11
[PATCH] ssb: Reenable PCI host on !MIPS
The commit 58eae1416b804d900014d84feadda7195007cc30
("ssb: Disable PCI host for PCI_DRIVERS_GENERIC") disabled
CONFIG_SSB_PCIHOST and CONFIG_SSB_B43_PCI_BRIDGE, which are
required for SSB-based b43 PCI cards, on everything except MIPS
with PCI_DRIVERS_LEGACY, including x86 (only MIPS defines
that config option). Reenable it.
Signed-off-by: Krzysztof Mazur
---
drivers/ssb/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig
index 71c73766ee22..3dc57414e06b 100644
--- a/drivers/ssb/Kconfig
+++ b/drivers/ssb/Kconfig
@@ -32,7 +32,7 @@ config SSB_BLOCKIO
config SSB_PCIHOST_POSSIBLE
bool
- depends on SSB && (PCI = y || PCI = SSB) && PCI_DRIVERS_LEGACY
+ depends on SSB && (PCI = y || PCI = SSB) && (!MIPS ||
PCI_DRIVERS_LEGACY)
default y
config SSB_PCIHOST
--
2.16.0.rc1.238.g530d649a7
ath9k will not tx packets sometimes.
I'm doing a test with 200 virtual stations on each of 6 ath9k radios. When I configure stations for DHCP, I see cases where stations on a particular radio will not transmit anything sometimes. I see no 'XMIT' logs that show indication of frames being received in the driver from the upper stack, but if I use 'tshark' on a station interface, it shows frames being 'transmitted'. I do, however, see this, which looks like it might show an issue. It looks like whatever 'aqm' is, it has an ever expanding number of backlog packets: [root@2u-6n lanforge]# cat /debug/ieee80211/wiphy2/netdev\:sta30194/stations/00\:0e\:8e\:69\:b8\:f7/aqm target 4us interval 29us ecn no tid ac backlog-bytes backlog-packets new-flows drops marks overlimit collisions tx-bytes tx-packets 0 2 27616 440 9 0 0 0 428 998 7 1 3 0 0 0 0 0 0 0 0 0 2 3 0 0 0 0 0 0 0 0 0 3 2 0 0 0 0 0 0 0 0 0 4 1 0 0 0 0 0 0 0 0 0 5 1 0 0 0 0 0 0 0 0 0 6 0 0 0 1 0 0 0 0 390 1 7 0 0 0 637 0 0 0 792 22072 903 8 2 0 0 0 0 0 0 0 0 0 9 3 0 0 0 0 0 0 0 0 0 10 3 0 0 0 0 0 0 0 0 0 11 2 0 0 0 0 0 0 0 0 0 12 1 0 0 0 0 0 0 0 0 0 13 1 0 0 0 0 0 0 0 0 0 14 0 0 0 0 0 0 0 0 0 0 15 0 0 0 0 0 0 0 0 0 0 Anyone have any pointers as to whether this might be a real issue or not? I'll go digging in the meantime Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [PATCH 1/2] wireless: set correct mandatory rate flags
On 09/07/2017 05:47 PM, Richard Schütz wrote:
> According to IEEE Std 802.11-2016 (16.2.3.4 Long PHY SIGNAL field) all of
> the following rates are mandatory for a HR/DSSS PHY: 1 Mb/s, 2 Mb/s,
> 5.5 Mb/s and 11 Mb/s. Set IEEE80211_RATE_MANDATORY_B flag for all of these
> instead of just 1 Mb/s to correctly reflect this.
>
> Signed-off-by: Richard Schütz
We've noticed that this is breaking interoperability of 11s nodes in
OpenWrt: association is only possible when neither or both peers have this
patch. I have not tested interop with non-Linux 11s peers.
I propose to revert this for now (I assume it's too late for 4.15, but
hopefully the regression can be fixed in 4.15.1).
Regards,
Matthias
> ---
> net/wireless/util.c | 22 +-
> 1 file changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/net/wireless/util.c b/net/wireless/util.c
> index bcb1284c3415..c69b5c31caf8 100644
> --- a/net/wireless/util.c
> +++ b/net/wireless/util.c
> @@ -157,32 +157,28 @@ static void set_mandatory_flags_band(struct
> ieee80211_supported_band *sband)
> case NL80211_BAND_2GHZ:
> want = 7;
> for (i = 0; i < sband->n_bitrates; i++) {
> - if (sband->bitrates[i].bitrate == 10) {
> + if (sband->bitrates[i].bitrate == 10 ||
> + sband->bitrates[i].bitrate == 20 ||
> + sband->bitrates[i].bitrate == 55 ||
> + sband->bitrates[i].bitrate == 110) {
> sband->bitrates[i].flags |=
> IEEE80211_RATE_MANDATORY_B |
> IEEE80211_RATE_MANDATORY_G;
> want--;
> + } else {
> + sband->bitrates[i].flags |=
> + IEEE80211_RATE_ERP_G;
> }
>
> - if (sband->bitrates[i].bitrate == 20 ||
> - sband->bitrates[i].bitrate == 55 ||
> - sband->bitrates[i].bitrate == 110 ||
> - sband->bitrates[i].bitrate == 60 ||
> + if (sband->bitrates[i].bitrate == 60 ||
> sband->bitrates[i].bitrate == 120 ||
> sband->bitrates[i].bitrate == 240) {
> sband->bitrates[i].flags |=
> IEEE80211_RATE_MANDATORY_G;
> want--;
> }
> -
> - if (sband->bitrates[i].bitrate != 10 &&
> - sband->bitrates[i].bitrate != 20 &&
> - sband->bitrates[i].bitrate != 55 &&
> - sband->bitrates[i].bitrate != 110)
> - sband->bitrates[i].flags |=
> - IEEE80211_RATE_ERP_G;
> }
> - WARN_ON(want != 0 && want != 3 && want != 6);
> + WARN_ON(want != 0 && want != 3);
> break;
> case NL80211_BAND_60GHZ:
> /* check for mandatory HT MCS 1..4 */
>
signature.asc
Description: OpenPGP digital signature
[PATCH v4] mac80211: mesh: fix wrong mesh TTL offset calculation
From: Peter Oh
mesh TTL offset in Mesh Channel Switch Parameters element depends on
not only Secondary Channel Offset element, but also affected by
HT Control field and Wide Bandwidth Channel Switch element.
So use element structure to manipulate mesh channel swich param IE
after removing its constant attribution to correct the miscalculation.
Signed-off-by: Peter Oh
---
net/mac80211/ieee80211_i.h | 2 +-
net/mac80211/mesh.c| 17 ++---
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 2690002..ae9c33c 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1467,7 +1467,7 @@ struct ieee802_11_elems {
const struct ieee80211_timeout_interval_ie *timeout_int;
const u8 *opmode_notif;
const struct ieee80211_sec_chan_offs_ie *sec_chan_offs;
- const struct ieee80211_mesh_chansw_params_ie *mesh_chansw_params_ie;
+ struct ieee80211_mesh_chansw_params_ie *mesh_chansw_params_ie;
const struct ieee80211_bss_max_idle_period_ie *max_idle_period_ie;
/* length of them, respectively */
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 73ac607..6a381cb 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1255,13 +1255,12 @@ int ieee80211_mesh_csa_beacon(struct
ieee80211_sub_if_data *sdata,
}
static int mesh_fwd_csa_frame(struct ieee80211_sub_if_data *sdata,
- struct ieee80211_mgmt *mgmt, size_t len)
+ struct ieee80211_mgmt *mgmt, size_t len,
+ struct ieee802_11_elems *elems)
{
struct ieee80211_mgmt *mgmt_fwd;
struct sk_buff *skb;
struct ieee80211_local *local = sdata->local;
- u8 *pos = mgmt->u.action.u.chan_switch.variable;
- size_t offset_ttl;
skb = dev_alloc_skb(local->tx_headroom + len);
if (!skb)
@@ -1269,13 +1268,9 @@ static int mesh_fwd_csa_frame(struct
ieee80211_sub_if_data *sdata,
skb_reserve(skb, local->tx_headroom);
mgmt_fwd = skb_put(skb, len);
- /* offset_ttl is based on whether the secondary channel
-* offset is available or not. Subtract 1 from the mesh TTL
-* and disable the initiator flag before forwarding.
-*/
- offset_ttl = (len < 42) ? 7 : 10;
- *(pos + offset_ttl) -= 1;
- *(pos + offset_ttl + 1) &= ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
+ elems->mesh_chansw_params_ie->mesh_ttl--;
+ elems->mesh_chansw_params_ie->mesh_flags &=
+ ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
memcpy(mgmt_fwd, mgmt, len);
eth_broadcast_addr(mgmt_fwd->da);
@@ -1323,7 +1318,7 @@ static void mesh_rx_csa_frame(struct
ieee80211_sub_if_data *sdata,
/* forward or re-broadcast the CSA frame */
if (fwd_csa) {
- if (mesh_fwd_csa_frame(sdata, mgmt, len) < 0)
+ if (mesh_fwd_csa_frame(sdata, mgmt, len, &elems) < 0)
mcsa_dbg(sdata, "Failed to forward the CSA frame");
}
}
--
2.7.4
Re: [PATCH v2] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init
On 01/26/2018 10:38 AM, Jia-Ju Bai wrote: After checking all possible call chains to bcma_pmu_resources_init() here, my tool finds that this function is never called in atomic context, namely never in an interrupt handler or holding a spinlock. Thus mdelay can be replaced with usleep_range to avoid busy wait. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai --- v2: * Use usleep_range(2000, 2500), instead of (1500, 2000) in v1. --- drivers/bcma/driver_chipcommon_pmu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bcma/driver_chipcommon_pmu.c b/drivers/bcma/driver_chipcommon_pmu.c index f1eb4d3..478948c 100644 --- a/drivers/bcma/driver_chipcommon_pmu.c +++ b/drivers/bcma/driver_chipcommon_pmu.c @@ -203,7 +203,7 @@ static void bcma_pmu_resources_init(struct bcma_drv_cc *cc) * Add some delay; allow resources to come up and settle. * Delay is required for SoC (early init). */ - mdelay(2); + usleep_range(2000, 2500); I have no means of testing this patch, but it should be OK. Acked-by: Larry Finger } /* Disable to allow reading SPROM. Don't know the adventages of enabling it. */
Re: ath9k, irq 16: nobody cared, 4.13.16+ kernel
On 01/26/2018 10:04 AM, Ben Greear wrote: Hello, I'm testing on a heavily loaded system. It has 6 ath9k radios, each of which have 200 stations on them. When I try to start some slow-speed UDP traffic on each virtual station, I see this splat below. Is this just expected on a heavily loaded system? Or, any ideas how to make it better (I'll investigate this irqpoll thing it suggests...) Maybe a related question... The ath9k driver has a napi budget of 512. I added code and verified that at least sometimes it would take more than 5 jiffies in this handler. Maybe it is a good idea to have a jiffies timeout breakout as well as a budget to stop the while loop and exit this handler? If so, is 5 jiffies a good number do you think? And, from looking at the IRQ code, it seems that it will re-enable the IRQ later even if I see the splat below, so the system should recover OK? Thanks, Ben [ 2833.533351] irq 16: nobody cared (try booting with the "irqpoll" option) [ 2833.539111] CPU: 4 PID: 0 Comm: swapper/4 Tainted: GW O4.13.16+ #36 [ 2833.539112] Hardware name: Iron_Systems,Inc CS-CAD-2U-A02/X10SRL-F, BIOS 2.0b 05/02/2017 [ 2833.539113] Call Trace: [ 2833.539114] [ 2833.539119] dump_stack+0x63/0x87 [ 2833.539122] __report_bad_irq+0x2e/0xc0 [ 2833.539123] note_interrupt+0x227/0x270 [ 2833.539124] handle_irq_event_percpu+0x40/0x50 [ 2833.539126] handle_irq_event+0x34/0x60 [ 2833.539127] handle_fasteoi_irq+0x78/0x140 [ 2833.539128] handle_irq+0x18/0x30 [ 2833.539129] do_IRQ+0x41/0xc0 [ 2833.539130] common_interrupt+0x89/0x89 [ 2833.539133] RIP: 0010:fib_rules_lookup+0x3e/0x1a0 [ 2833.539134] RSP: 0018:88087fd03828 EFLAGS: 0283 ORIG_RAX: ffac [ 2833.539135] RAX: 0353 RBX: 8807eb10c300 RCX: 88087fd03868 [ 2833.539135] RDX: RSI: 88087fd038e0 RDI: 88085ab55b40 [ 2833.539136] RBP: 88087fd03858 R08: R09: 0001 [ 2833.539136] R10: 81efd500 R11: 88081ae6ac00 R12: 88085ab55b40 [ 2833.539137] R13: 88087fd03868 R14: 88085ab55bc0 R15: 88087fd038e0 [ 2833.539139] ? fib_rules_lookup+0x2a/0x1a0 [ 2833.539141] __fib_lookup+0x4f/0x80 [ 2833.539143] ip_route_input_rcu+0xa0d/0xc20 [ 2833.539144] ip_route_input_noref+0x3e/0x60 [ 2833.539147] ? ioapic_ir_ack_level+0x29/0x30 [ 2833.539147] ? handle_fasteoi_irq+0xff/0x140 [ 2833.539149] arp_process+0x486/0x820 [ 2833.539150] ? do_IRQ+0x4a/0xc0 [ 2833.539151] ? common_interrupt+0x89/0x89 [ 2833.539152] arp_rcv+0x112/0x1b0 [ 2833.539155] __netif_receive_skb_core+0x689/0xa90 [ 2833.539156] __netif_receive_skb+0x13/0x60 [ 2833.539156] ? __netif_receive_skb+0x13/0x60 [ 2833.539158] netif_receive_skb_internal+0x1c6/0x440 [ 2833.539159] netif_receive_skb+0x17/0x80 [ 2833.539178] ieee80211_deliver_skb+0x165/0x1d0 [mac80211] [ 2833.539187] ieee80211_rx_handlers+0xe50/0x26f0 [mac80211] [ 2833.539188] ? skb_copy_bits+0x5f/0x260 [ 2833.539189] ? copy_skb_header+0x12/0x90 [ 2833.539197] ieee80211_prepare_and_rx_handle+0x638/0x1130 [mac80211] [ 2833.539198] ? ioapic_ir_ack_level+0x29/0x30 [ 2833.539206] ieee80211_rx_napi+0x87d/0xa70 [mac80211] [ 2833.539210] ath_rx_tasklet+0xa99/0x11a0 [ath9k] [ 2833.539213] ath9k_tasklet+0x113/0x2e0 [ath9k] [ 2833.539215] tasklet_action+0x10c/0x120 [ 2833.539216] __do_softirq+0xc1/0x2a0 [ 2833.539217] irq_exit+0x9b/0xa0 [ 2833.539218] do_IRQ+0x4a/0xc0 [ 2833.539219] common_interrupt+0x89/0x89 [ 2833.539221] RIP: 0010:cpuidle_enter_state+0xf8/0x2a0 [ 2833.539221] RSP: 0018:c900031fbe78 EFLAGS: 0246 ORIG_RAX: ffac [ 2833.539222] RAX: 88087fd1c000 RBX: 88087fd25f00 RCX: 001f [ 2833.539223] RDX: RSI: e691b77ea649 RDI: [ 2833.539223] RBP: c900031fbeb0 R08: c442b282beb1 R09: 02eb [ 2833.539224] R10: 035c R11: 88087fd18ee4 R12: 0004 [ 2833.539224] R13: 0004 R14: 0004 R15: 0293855eb8ba [ 2833.539225] [ 2833.539226] ? cpuidle_enter_state+0xd4/0x2a0 [ 2833.539227] cpuidle_enter+0x12/0x20 [ 2833.539229] call_cpuidle+0x1e/0x40 [ 2833.539229] do_idle+0x17f/0x1d0 [ 2833.539230] cpu_startup_entry+0x5f/0x70 [ 2833.539231] start_secondary+0x14b/0x180 [ 2833.539233] secondary_startup_64+0x9f/0x9f [ 2833.539233] handlers: [ 2833.540606] [] ath_isr [ath9k] [ 2833.544278] Disabling IRQ #16 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
ath9k, irq 16: nobody cared, 4.13.16+ kernel
Hello, I'm testing on a heavily loaded system. It has 6 ath9k radios, each of which have 200 stations on them. When I try to start some slow-speed UDP traffic on each virtual station, I see this splat below. Is this just expected on a heavily loaded system? Or, any ideas how to make it better (I'll investigate this irqpoll thing it suggests...) [ 2833.533351] irq 16: nobody cared (try booting with the "irqpoll" option) [ 2833.539111] CPU: 4 PID: 0 Comm: swapper/4 Tainted: GW O4.13.16+ #36 [ 2833.539112] Hardware name: Iron_Systems,Inc CS-CAD-2U-A02/X10SRL-F, BIOS 2.0b 05/02/2017 [ 2833.539113] Call Trace: [ 2833.539114] [ 2833.539119] dump_stack+0x63/0x87 [ 2833.539122] __report_bad_irq+0x2e/0xc0 [ 2833.539123] note_interrupt+0x227/0x270 [ 2833.539124] handle_irq_event_percpu+0x40/0x50 [ 2833.539126] handle_irq_event+0x34/0x60 [ 2833.539127] handle_fasteoi_irq+0x78/0x140 [ 2833.539128] handle_irq+0x18/0x30 [ 2833.539129] do_IRQ+0x41/0xc0 [ 2833.539130] common_interrupt+0x89/0x89 [ 2833.539133] RIP: 0010:fib_rules_lookup+0x3e/0x1a0 [ 2833.539134] RSP: 0018:88087fd03828 EFLAGS: 0283 ORIG_RAX: ffac [ 2833.539135] RAX: 0353 RBX: 8807eb10c300 RCX: 88087fd03868 [ 2833.539135] RDX: RSI: 88087fd038e0 RDI: 88085ab55b40 [ 2833.539136] RBP: 88087fd03858 R08: R09: 0001 [ 2833.539136] R10: 81efd500 R11: 88081ae6ac00 R12: 88085ab55b40 [ 2833.539137] R13: 88087fd03868 R14: 88085ab55bc0 R15: 88087fd038e0 [ 2833.539139] ? fib_rules_lookup+0x2a/0x1a0 [ 2833.539141] __fib_lookup+0x4f/0x80 [ 2833.539143] ip_route_input_rcu+0xa0d/0xc20 [ 2833.539144] ip_route_input_noref+0x3e/0x60 [ 2833.539147] ? ioapic_ir_ack_level+0x29/0x30 [ 2833.539147] ? handle_fasteoi_irq+0xff/0x140 [ 2833.539149] arp_process+0x486/0x820 [ 2833.539150] ? do_IRQ+0x4a/0xc0 [ 2833.539151] ? common_interrupt+0x89/0x89 [ 2833.539152] arp_rcv+0x112/0x1b0 [ 2833.539155] __netif_receive_skb_core+0x689/0xa90 [ 2833.539156] __netif_receive_skb+0x13/0x60 [ 2833.539156] ? __netif_receive_skb+0x13/0x60 [ 2833.539158] netif_receive_skb_internal+0x1c6/0x440 [ 2833.539159] netif_receive_skb+0x17/0x80 [ 2833.539178] ieee80211_deliver_skb+0x165/0x1d0 [mac80211] [ 2833.539187] ieee80211_rx_handlers+0xe50/0x26f0 [mac80211] [ 2833.539188] ? skb_copy_bits+0x5f/0x260 [ 2833.539189] ? copy_skb_header+0x12/0x90 [ 2833.539197] ieee80211_prepare_and_rx_handle+0x638/0x1130 [mac80211] [ 2833.539198] ? ioapic_ir_ack_level+0x29/0x30 [ 2833.539206] ieee80211_rx_napi+0x87d/0xa70 [mac80211] [ 2833.539210] ath_rx_tasklet+0xa99/0x11a0 [ath9k] [ 2833.539213] ath9k_tasklet+0x113/0x2e0 [ath9k] [ 2833.539215] tasklet_action+0x10c/0x120 [ 2833.539216] __do_softirq+0xc1/0x2a0 [ 2833.539217] irq_exit+0x9b/0xa0 [ 2833.539218] do_IRQ+0x4a/0xc0 [ 2833.539219] common_interrupt+0x89/0x89 [ 2833.539221] RIP: 0010:cpuidle_enter_state+0xf8/0x2a0 [ 2833.539221] RSP: 0018:c900031fbe78 EFLAGS: 0246 ORIG_RAX: ffac [ 2833.539222] RAX: 88087fd1c000 RBX: 88087fd25f00 RCX: 001f [ 2833.539223] RDX: RSI: e691b77ea649 RDI: [ 2833.539223] RBP: c900031fbeb0 R08: c442b282beb1 R09: 02eb [ 2833.539224] R10: 035c R11: 88087fd18ee4 R12: 0004 [ 2833.539224] R13: 0004 R14: 0004 R15: 0293855eb8ba [ 2833.539225] [ 2833.539226] ? cpuidle_enter_state+0xd4/0x2a0 [ 2833.539227] cpuidle_enter+0x12/0x20 [ 2833.539229] call_cpuidle+0x1e/0x40 [ 2833.539229] do_idle+0x17f/0x1d0 [ 2833.539230] cpu_startup_entry+0x5f/0x70 [ 2833.539231] start_secondary+0x14b/0x180 [ 2833.539233] secondary_startup_64+0x9f/0x9f [ 2833.539233] handlers: [ 2833.540606] [] ath_isr [ath9k] [ 2833.544278] Disabling IRQ #16 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [PATCH] ssb: Do not disable PCI host on non-Mips
On Fri, Jan 26, 2018 at 07:01:49PM +0200, Kalle Valo wrote:
> Kalle Valo writes:
>
> > James Hogan writes:
> >
> >> On Fri, Jan 26, 2018 at 10:38:01AM +0100, Sven Joachim wrote:
> >>> After upgrading an old laptop to 4.15-rc9, I found that the eth0 and
> >>> wlan0 interfaces had disappeared. It turns out that the b43 and b44
> >>> drivers require SSB_PCIHOST_POSSIBLE which depends on
> >>> PCI_DRIVERS_LEGACY, a config option that only exists on Mips.
> >>>
> >>> Fixes: 58eae1416b80 ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC")
> >>> Cc: sta...@vger.org
> >>> Signed-off-by: Sven Joachim
> >>
> >> Whoops, thats a very good point. I hadn't twigged that
> >> PCI_DRIVERS_LEGACY was MIPS specific (one of the disadvantages of using
> >> "tig grep" I suppose!).
> >>
> >> Reviewed-by: James Hogan
> >>
> >> I think this is obviously correct, so it'd be great to squeeze it into
> >> 4.15 final.
> >
> > I'm not sure if I'm able to get it to 4.15 as it has go via the net
> > tree, and we have only two days before the (likely) final release, but
> > I'll try.
>
> Too late, Dave already sent his last pull request for 4.15. This will be
> in 4.16.
Okay, thanks anyway (and sorry again!).
Cheers
James
signature.asc
Description: Digital signature
pull-request: wireless-drivers-next 2018-01-26
Hi Dave, this is a pull request to net-next for 4.16, more info in the signed tag below. Please let me know if you have any problems. Kalle The following changes since commit ebdd7b491b8a65d65936e07004caabca4a3c94a0: Merge branch 'mlxsw-Add-support-for-mirror-action-with-flower' (2018-01-21 18:21:31 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2018-01-26 for you to fetch changes up to 30ce7f4456ae40e970d9e82fe63c5e55147af0c0: mt76: validate rx CCMP PN (2018-01-26 11:20:52 +0200) wireless-drivers-next patches for 4.16 Major changes: wil6210 * add PCI device id for Talyn * support flashless device ath9k * improve RSSI/signal accuracy on AR9003 series mt76 * validate CCMP PN from received frames to avoid replay attacks qtnfmac * support 64-bit network stats * report more hardware information to kernel log and some via ethtool Arend Van Spriel (2): brcmfmac: assure bcdc dcmd api does not return value > 0 brcmfmac: separate firmware errors from i/o errors Dedy Lansky (1): wil6210: support flashless device Felix Fietkau (10): mt76: fix transmission of encrypted management frames ath9k: discard undersized packets mt76: retry rx polling as long as there is budget left mt76: fix TSF value in probe responses mt76: add an intermediate struct for rx status information mt76: get station pointer by wcid and pass it to mac80211 mt76: implement A-MPDU rx reordering in the driver code mt76: split mt76_rx_complete mt76: pass the per-vif wcid to the core for multicast rx mt76: validate rx CCMP PN Igor Mitsyanko (2): qtnfmac: do not use mutexes in timer context qtnfmac: do not use bus mutex for events processing Kalle Valo (1): Merge ath-next from git://git.kernel.org/.../kvalo/ath.git Lior David (2): wil6210: fix random failure to bring network interface up wil6210: enlarge FW mac_rgf_ext section for Sparrow D0 Lorenzo Bianconi (5): mt76x2: fix WMM parameter configuration mt76x2: dfs: avoid tasklet scheduling during mt76x2_dfs_init_params() mt76x2: dfs: add set_domain handler mt76x2: dfs: take into account dfs region in mt76x2_dfs_init_params() mt76x2: init: disable all pending tasklets during device removal Luis de Bethencourt (1): rtl8xxxu: Fix trailing semicolon Maya Erez (5): wil6210: add Talyn PCIe device ID wil6210: recognize Talyn JTAG ID wil6210: add support for Talyn AHB address map wil6210: configure OTP HW vectors in SW reset flow wil6210: support parsing brd file address from fw file Ping-Ke Shih (10): rtlwifi: btcoex: extend get_wifi_bw to support bandwidth 80M rtlwifi: btcoex: Add switch band notify for btc rtlwifi: btcoex: Add variable ant_div_cfg to support antenna diversity rtlwifi: btcoex: add scan_notify within ips_notify if RFON rtlwifi: btcoex: Add wifi_only series ops to control solo card rtlwifi: btcoex: add boolean variables dbg_mode rtlwifi: 8822be has to report vht capability to mac80211 rtlwifi: Add ratr_table for newer IC rtlwifi: Add spec_ver to check whether use new rate-id or not rtlwifi: btcoex: Fix some static warnings from Sparse Ramon Fried (1): wcn36xx: release DMA memory in case of error Sergey Matyukevich (4): qtnfmac: modify supported interface combinations qtnfmac: validate interface combinations on changes qtnfmac: fix STA disconnect procedure qtnfmac: remove redundant 'unlikely' checks Vasily Ulyanov (5): qtnfmac: remove struct qlink_cmd_set_mac_acl qtnfmac: fix warnings when mBSS setup is stopped qtnfmac: support 64-bit network interface stats qtnfmac: get more hardware info from card qtnfmac: report hardware/firmware information via ethtool Wojciech Dubowik (4): ath9k: Alternative EEPROM size for AR9003 ath9k: Read noise floor calibration data from eeprom ath9k: Use calibrated noise floor value when available ath9k: Display calibration data piers in debugfs drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 133 ++- drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 10 + drivers/net/wireless/ath/ath9k/calib.c | 38 +-- drivers/net/wireless/ath/ath9k/hw.h| 2 + drivers/net/wireless/ath/ath9k/recv.c | 4 +- drivers/net/wireless/ath/wcn36xx/dxe.c | 46 +++- drivers/net/wireless/ath/wil6210/boot_loader.h | 9 +- drivers/net/wireless/ath/wil6210/fw.h | 18 +- drivers/net/wireless/ath/wil6210/fw_inc.c | 167 - drivers/net/wireless/ath/wil6210/interrupt.c | 6 +- drivers/
Re: [PATCH] ssb: Do not disable PCI host on non-Mips
Kalle Valo writes:
> James Hogan writes:
>
>> On Fri, Jan 26, 2018 at 10:38:01AM +0100, Sven Joachim wrote:
>>> After upgrading an old laptop to 4.15-rc9, I found that the eth0 and
>>> wlan0 interfaces had disappeared. It turns out that the b43 and b44
>>> drivers require SSB_PCIHOST_POSSIBLE which depends on
>>> PCI_DRIVERS_LEGACY, a config option that only exists on Mips.
>>>
>>> Fixes: 58eae1416b80 ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC")
>>> Cc: sta...@vger.org
>>> Signed-off-by: Sven Joachim
>>
>> Whoops, thats a very good point. I hadn't twigged that
>> PCI_DRIVERS_LEGACY was MIPS specific (one of the disadvantages of using
>> "tig grep" I suppose!).
>>
>> Reviewed-by: James Hogan
>>
>> I think this is obviously correct, so it'd be great to squeeze it into
>> 4.15 final.
>
> I'm not sure if I'm able to get it to 4.15 as it has go via the net
> tree, and we have only two days before the (likely) final release, but
> I'll try.
Too late, Dave already sent his last pull request for 4.15. This will be
in 4.16.
--
Kalle Valo
Re: pull-request: wireless-drivers 2018-01-26
David Miller writes: > From: Kalle Valo > Date: Fri, 26 Jan 2018 18:33:33 +0200 > >> this is a pull request to the net tree for 4.15. I hate to do late pull >> requests like this but today Sven Joachim found a serious regression in >> one of ssb patches, I hope there's still enough time to get this to >> 4.15. >> >> But if it's too late, just let me know and I'll queue this for 4.16. > > I think this is going to have to wait for 4.16, I just sent what I hope > is my last pull to Linus for this cycle. Yeah, I guessed that when I noticed you sent your pull request just 3 minutes after mine :) I'll send this to you next week in another pull request, please drop this one. -- Kalle Valo
Re: pull-request: wireless-drivers 2018-01-26
From: Kalle Valo Date: Fri, 26 Jan 2018 18:33:33 +0200 > this is a pull request to the net tree for 4.15. I hate to do late pull > requests like this but today Sven Joachim found a serious regression in > one of ssb patches, I hope there's still enough time to get this to > 4.15. > > But if it's too late, just let me know and I'll queue this for 4.16. I think this is going to have to wait for 4.16, I just sent what I hope is my last pull to Linus for this cycle. Thanks.
[PATCH v2] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init
After checking all possible call chains to bcma_pmu_resources_init() here, my tool finds that this function is never called in atomic context, namely never in an interrupt handler or holding a spinlock. Thus mdelay can be replaced with usleep_range to avoid busy wait. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai --- v2: * Use usleep_range(2000, 2500), instead of (1500, 2000) in v1. --- drivers/bcma/driver_chipcommon_pmu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bcma/driver_chipcommon_pmu.c b/drivers/bcma/driver_chipcommon_pmu.c index f1eb4d3..478948c 100644 --- a/drivers/bcma/driver_chipcommon_pmu.c +++ b/drivers/bcma/driver_chipcommon_pmu.c @@ -203,7 +203,7 @@ static void bcma_pmu_resources_init(struct bcma_drv_cc *cc) * Add some delay; allow resources to come up and settle. * Delay is required for SoC (early init). */ - mdelay(2); + usleep_range(2000, 2500); } /* Disable to allow reading SPROM. Don't know the adventages of enabling it. */ -- 1.7.9.5
Re: [PATCH] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init
On 2018/1/27 0:26, Larry Finger wrote: On 01/26/2018 03:13 AM, Jia-Ju Bai wrote: After checking all possible call chains to bcma_pmu_resources_init() here, my tool finds that this function is never called in atomic context, namely never in an interrupt handler or holding a spinlock. Thus mdelay can be replaced with usleep_range to avoid busy wait. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai --- drivers/bcma/driver_chipcommon_pmu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bcma/driver_chipcommon_pmu.c b/drivers/bcma/driver_chipcommon_pmu.c index f1eb4d3..478948c 100644 --- a/drivers/bcma/driver_chipcommon_pmu.c +++ b/drivers/bcma/driver_chipcommon_pmu.c @@ -203,7 +203,7 @@ static void bcma_pmu_resources_init(struct bcma_drv_cc *cc) * Add some delay; allow resources to come up and settle. * Delay is required for SoC (early init). */ -mdelay(2); +usleep_range(1500, 2000); I have no idea how critical this delay might be, but it would be safer to never make the sleep be shorter than the original delay. Using (2000, 2500) would be a better choice of arguments for usleep_range(). Okay, I have used usleep_range(2000, 2500) and sent patch v2. Thanks, Jia-Ju Bai
pull-request: wireless-drivers 2018-01-26
Hi Dave, this is a pull request to the net tree for 4.15. I hate to do late pull requests like this but today Sven Joachim found a serious regression in one of ssb patches, I hope there's still enough time to get this to 4.15. But if it's too late, just let me know and I'll queue this for 4.16. Kalle The following changes since commit 1e19c4d689dc1e95bafd23ef68fbc0c6b9e05180: net: vrf: Add support for sends to local broadcast address (2018-01-25 21:51:03 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2018-01-26 for you to fetch changes up to a9e6d44ddeccd3522670e641f1ed9b068e746ff7: ssb: Do not disable PCI host on non-Mips (2018-01-26 16:55:34 +0200) wireless-drivers fixes for 4.15 ssb * last minute patch to fix b43 and b44 drivers on non-mips platforms, a regression from v4.15-rc9 Sven Joachim (1): ssb: Do not disable PCI host on non-Mips drivers/ssb/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init
On 01/26/2018 10:13 AM, Kalle Valo wrote: Jia-Ju Bai writes: After checking all possible call chains to bcma_pmu_resources_init() here, my tool finds that this function is never called in atomic context, namely never in an interrupt handler or holding a spinlock. Thus mdelay can be replaced with usleep_range to avoid busy wait. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai --- drivers/bcma/driver_chipcommon_pmu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bcma/driver_chipcommon_pmu.c b/drivers/bcma/driver_chipcommon_pmu.c index f1eb4d3..478948c 100644 --- a/drivers/bcma/driver_chipcommon_pmu.c +++ b/drivers/bcma/driver_chipcommon_pmu.c @@ -203,7 +203,7 @@ static void bcma_pmu_resources_init(struct bcma_drv_cc *cc) * Add some delay; allow resources to come up and settle. * Delay is required for SoC (early init). */ - mdelay(2); + usleep_range(1500, 2000); I would like to have an ack from someone familiar with bcma before I apply this. No ack for this one. Larry
Re: [PATCH] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init
On 01/26/2018 03:13 AM, Jia-Ju Bai wrote: After checking all possible call chains to bcma_pmu_resources_init() here, my tool finds that this function is never called in atomic context, namely never in an interrupt handler or holding a spinlock. Thus mdelay can be replaced with usleep_range to avoid busy wait. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai --- drivers/bcma/driver_chipcommon_pmu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bcma/driver_chipcommon_pmu.c b/drivers/bcma/driver_chipcommon_pmu.c index f1eb4d3..478948c 100644 --- a/drivers/bcma/driver_chipcommon_pmu.c +++ b/drivers/bcma/driver_chipcommon_pmu.c @@ -203,7 +203,7 @@ static void bcma_pmu_resources_init(struct bcma_drv_cc *cc) * Add some delay; allow resources to come up and settle. * Delay is required for SoC (early init). */ - mdelay(2); + usleep_range(1500, 2000); I have no idea how critical this delay might be, but it would be safer to never make the sleep be shorter than the original delay. Using (2000, 2500) would be a better choice of arguments for usleep_range(). NACK Larry
Re: [PATCH] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init
Jia-Ju Bai writes: > After checking all possible call chains to bcma_pmu_resources_init() here, > my tool finds that this function is never called in atomic context, > namely never in an interrupt handler or holding a spinlock. > Thus mdelay can be replaced with usleep_range to avoid busy wait. > > This is found by a static analysis tool named DCNS written by myself. > > Signed-off-by: Jia-Ju Bai > --- > drivers/bcma/driver_chipcommon_pmu.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/bcma/driver_chipcommon_pmu.c > b/drivers/bcma/driver_chipcommon_pmu.c > index f1eb4d3..478948c 100644 > --- a/drivers/bcma/driver_chipcommon_pmu.c > +++ b/drivers/bcma/driver_chipcommon_pmu.c > @@ -203,7 +203,7 @@ static void bcma_pmu_resources_init(struct bcma_drv_cc > *cc) >* Add some delay; allow resources to come up and settle. >* Delay is required for SoC (early init). >*/ > - mdelay(2); > + usleep_range(1500, 2000); I would like to have an ack from someone familiar with bcma before I apply this. -- Kalle Valo
Re: [PATCH v2] mac80211_hwsim: don't use WQ_MEM_RECLAIM
Hi, Am 26.01.2018 um 16:05 schrieb Tejun Heo: > Hello, > > On Fri, Jan 26, 2018 at 09:08:02AM +0100, Johannes Berg wrote: >> Not that you mention it ... Honestly though, wifi connections break all >> the time, so not sure you'd really want that. But anyway, that's what >> we have. > I'd be a lot happier to remove WQ_MEM_RECLAIM from wireless drivers > too, and glancing the code, it looked like there already are so many > holes that whether having that flag or not shouldn't matter all that > much. It was just difficult for me to make a case for removing it > preemptively. If you're up for it, please be my guest. I think, it is quite clear, why this error is produced, since in memory reclaim, we should not synchronously flush unimportant work queues. I think there could be valid use cases to have work queues with that flag in wireless drivers, if the are used carefully. Therefore I suggest a hint in the work queue documentation like: "Check whether work_items on WQ_MEM_RECLAIM wq may actively delay memory reclaim with network timeouts and check whether other work queues without WQ_MEM_RECLAIM may be flushed within work_items of the queue, as this will prioritize non-reclaiming work_items on the flushed queue the same level as reclaiming work_items". At least this can help for future usage, as it could have avoided my error :-D > Thanks. > -- M.Sc. Benjamin Beichler Universität Rostock, Fakultät für Informatik und Elektrotechnik Institut für Angewandte Mikroelektronik und Datentechnik University of Rostock, Department of CS and EE Institute of Applied Microelectronics and CE Richard-Wagner-Straße 31 18119 Rostock Deutschland/Germany phone: +49 (0) 381 498 - 7278 email: benjamin.beich...@uni-rostock.de www: http://www.imd.uni-rostock.de/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] ath9k: Fix get channel default noise floor
the regression has been solved with that patch. so noise floor looks
normal for me on the 9280 chipset again
Am 26.01.2018 um 15:35 schrieb Kalle Valo:
Wojciech Dubowik writes:
Commit 8da58553cc63 ("ath9k: Use calibrated noise floor value
when available") introduced regression in ath9k_hw_getchan_noise
where per chain nominal noise floor has been taken instead default
for channel.
Revert to original default channel noise floor.
Reported-by: Sebastian Gottschall
Signed-off-by: Wojciech Dubowik
Fixes: 8da58553cc63 ("ath9k: Use calibrated noise floor value when available")
I can add that if this passes Sebastian's tests.
And I'm planning to queue this for 4.16.
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
Re: [PATCH v2] mac80211_hwsim: don't use WQ_MEM_RECLAIM
Hello, On Fri, Jan 26, 2018 at 09:08:02AM +0100, Johannes Berg wrote: > Not that you mention it ... Honestly though, wifi connections break all > the time, so not sure you'd really want that. But anyway, that's what > we have. I'd be a lot happier to remove WQ_MEM_RECLAIM from wireless drivers too, and glancing the code, it looked like there already are so many holes that whether having that flag or not shouldn't matter all that much. It was just difficult for me to make a case for removing it preemptively. If you're up for it, please be my guest. Thanks. -- tejun
Re: ssb: Do not disable PCI host on non-Mips
Sven Joachim wrote:
> After upgrading an old laptop to 4.15-rc9, I found that the eth0 and
> wlan0 interfaces had disappeared. It turns out that the b43 and b44
> drivers require SSB_PCIHOST_POSSIBLE which depends on
> PCI_DRIVERS_LEGACY, a config option that only exists on Mips.
>
> Fixes: 58eae1416b80 ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC")
> Cc: sta...@vger.org
> Signed-off-by: Sven Joachim
> Reviewed-by: James Hogan
Patch applied to wireless-drivers.git, thanks.
a9e6d44ddecc ssb: Do not disable PCI host on non-Mips
--
https://patchwork.kernel.org/patch/10185397/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support
On 01/26/2018 03:20 PM, Sebastian Gottschall wrote: > Am 26.01.2018 um 15:16 schrieb Wojciech Dubowik: >> >> >> On 26/01/18 12:42, Sebastian Gottschall wrote: >>> i have a idea what one cause could ne >>> >>> + nfval = >>> + ath9k_hw_get_nf_limits(ah, chan)->cal[i]; >>> + if (nfval > -60 || nfval < -127) >>> + nfval = default_nf; >>> >> This is just a check to make sure we have sane calibrated values. Anything >> above >> -60 or under -127 will not work so >> we take nominal value. > yes. but that means all < -127 and all > -60 catches it. this is the full > value > range. the check is wrong > everything is above -60 and bellow -127 at the same time. OR must ne AND > The minus sign generates some confusion here (had to evaluate the condition several times myself to get it right). what it does is defining the valid range for the nfval as follows -128: nok (Atheros code for invalid RSSI) [-127...-60]: ok [-59...127]: nok Cheers, Zefir
Re: [PATCH] ath9k: Fix get channel default noise floor
Wojciech Dubowik writes:
> Commit 8da58553cc63 ("ath9k: Use calibrated noise floor value
> when available") introduced regression in ath9k_hw_getchan_noise
> where per chain nominal noise floor has been taken instead default
> for channel.
> Revert to original default channel noise floor.
>
> Reported-by: Sebastian Gottschall
> Signed-off-by: Wojciech Dubowik
Fixes: 8da58553cc63 ("ath9k: Use calibrated noise floor value when available")
I can add that if this passes Sebastian's tests.
And I'm planning to queue this for 4.16.
--
Kalle Valo
Re: [PATCH] ssb: Do not disable PCI host on non-Mips
James Hogan writes:
> On Fri, Jan 26, 2018 at 10:38:01AM +0100, Sven Joachim wrote:
>> After upgrading an old laptop to 4.15-rc9, I found that the eth0 and
>> wlan0 interfaces had disappeared. It turns out that the b43 and b44
>> drivers require SSB_PCIHOST_POSSIBLE which depends on
>> PCI_DRIVERS_LEGACY, a config option that only exists on Mips.
>>
>> Fixes: 58eae1416b80 ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC")
>> Cc: sta...@vger.org
>> Signed-off-by: Sven Joachim
>
> Whoops, thats a very good point. I hadn't twigged that
> PCI_DRIVERS_LEGACY was MIPS specific (one of the disadvantages of using
> "tig grep" I suppose!).
>
> Reviewed-by: James Hogan
>
> I think this is obviously correct, so it'd be great to squeeze it into
> 4.15 final.
I'm not sure if I'm able to get it to 4.15 as it has go via the net
tree, and we have only two days before the (likely) final release, but
I'll try.
--
Kalle Valo
Re: [PATCH] ath9k: Fix get channel default noise floor
let me check
Am 26.01.2018 um 15:20 schrieb Wojciech Dubowik:
Commit 8da58553cc63 ("ath9k: Use calibrated noise floor value
when available") introduced regression in ath9k_hw_getchan_noise
where per chain nominal noise floor has been taken instead default
for channel.
Revert to original default channel noise floor.
Reported-by: Sebastian Gottschall
Signed-off-by: Wojciech Dubowik
---
drivers/net/wireless/ath/ath9k/calib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/calib.c
b/drivers/net/wireless/ath/ath9k/calib.c
index 3d9447e..695c779 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -72,7 +72,7 @@ static s16 ath9k_hw_get_default_nf(struct ath_hw *ah,
s16 ath9k_hw_getchan_noise(struct ath_hw *ah, struct ath9k_channel *chan,
s16 nf)
{
- s8 noise = ath9k_hw_get_default_nf(ah, chan, 0);
+ s8 noise = ATH_DEFAULT_NOISE_FLOOR;
if (nf) {
s8 delta = nf - ATH9K_NF_CAL_NOISE_THRESH -
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
[PATCH] ath9k: Fix get channel default noise floor
Commit 8da58553cc63 ("ath9k: Use calibrated noise floor value
when available") introduced regression in ath9k_hw_getchan_noise
where per chain nominal noise floor has been taken instead default
for channel.
Revert to original default channel noise floor.
Reported-by: Sebastian Gottschall
Signed-off-by: Wojciech Dubowik
---
drivers/net/wireless/ath/ath9k/calib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/calib.c
b/drivers/net/wireless/ath/ath9k/calib.c
index 3d9447e..695c779 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -72,7 +72,7 @@ static s16 ath9k_hw_get_default_nf(struct ath_hw *ah,
s16 ath9k_hw_getchan_noise(struct ath_hw *ah, struct ath9k_channel *chan,
s16 nf)
{
- s8 noise = ath9k_hw_get_default_nf(ah, chan, 0);
+ s8 noise = ATH_DEFAULT_NOISE_FLOOR;
if (nf) {
s8 delta = nf - ATH9K_NF_CAL_NOISE_THRESH -
--
2.7.4
Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support
Am 26.01.2018 um 15:16 schrieb Wojciech Dubowik: On 26/01/18 12:42, Sebastian Gottschall wrote: i have a idea what one cause could ne + nfval = + ath9k_hw_get_nf_limits(ah, chan)->cal[i]; + if (nfval > -60 || nfval < -127) + nfval = default_nf; This is just a check to make sure we have sane calibrated values. Anything above -60 or under -127 will not work so we take nominal value. yes. but that means all < -127 and all > -60 catches it. this is the full value range. the check is wrong everything is above -60 and bellow -127 at the same time. OR must ne AND this code here will allways return the default_nf since all possible returned values are within that range and the || is likelly wrong too and must be replaced with &&. but the range itself looks bogus. can't be right so please do me a favor and test your code against 9280 chipsets too and check if its working. right now its a full regression incidence and should be reverted Am 26.01.2018 um 12:07 schrieb Wojciech Dubowik: Are you sure you have applied path 4 in the series. You should see calibration piers. Sth like: Calibration data Chain 0 Freq ref volt temp nf_cal nf_pow rx_temp 2412 14 0 136 0 0 0 2437 13 0 136 0 0 0 2472 11 0 136 0 0 0 Chain 1 Freq ref volt temp nf_cal nf_pow rx_temp 2412 11 0 137 0 0 0 2437 11 0 139 0 0 0 2472 10 0 137 0 0 0 Chain 2 Freq ref volt temp nf_cal nf_pow rx_temp 2412 13 0 138 0 0 0 2437 14 0 139 0 0 0 2472 14 0 139 0 0 0 I have just done backports from ath.git and I can see these entries with my Compex card. Wojtek On 26/01/18 11:36, Sebastian Gottschall wrote: Am 26.01.2018 um 11:27 schrieb Wojciech Dubowik: I will try it with again with couple of OEM cards. this is no card. the eeprom is stored in flash memory. so the chip is a 9280 pcie chip which is connected on board, but has no own flash memory for calibration data. this is stored in system flash memory Is nanostation calibrated for noisefloor? You can see it with modal_eeprom in debugfs. root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom 2GHz modal Header : Chain0 Ant. Control : 0 Chain1 Ant. Control : 0 Chain2 Ant. Control : 0 Ant. Common Control : 0 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 11 Chain1 TxRxAtten : 11 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 11 Chain1 RxTxMargin : 11 Chain2 RxTxMargin : 11 ADC Desired size : 224 PGA Desired size : 0 Chain0 xlna Gain : 14 Chain1 xlna Gain : 14 Chain2 xlna Gain : 14 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 0 Chain0 NF Threshold : 202 Chain1 NF Threshold : 202 Chain2 NF Threshold : 202 xpdGain : 9 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient : 0 Chain2 Q Coefficient : 0 pdGainOverlap : 6 Chain0 OutputBias : 2 Chain0 DriverBias : 2 xPA Bias Level : 0 2chain pwr decrease : 0 3chain pwr decrease : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 2 Chain0 bswAtten : 21 Chain1 bswAtten : 21 Chain2 bswAtten : 0 Chain0 bswMargin : 31 Chain1 bswMargin : 31 Chain2 bswMargin : 0 HT40 Switch Settle : 44 Chain0 xatten2Db : 0 Chain1 xatten2Db : 0 Chain2 xatten2Db : 0 Chain0 xatten2Margin : 0 Chain1 xatten2Margin : 0 Chain2 xatten2Margin : 0 Chain1 OutputBias : 2 Chain1 DriverBias : 2 LNA Control : 13 XPA Bias Freq0 : 0 XPA Bias Freq1 : 0 XPA Bias Freq2 : 0 5GHz modal Header : Chain0 Ant. Control : 16 Chain1 Ant. Control : 16 Chain2 Ant. Control : 0 Ant. Common Control : 288 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 32 Chain1 TxRxAtten : 32 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 0 Chain1 RxTxMargin : 0 Chain2 RxTxMargin : 16 ADC De
Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support
On 26/01/18 12:42, Sebastian Gottschall wrote: i have a idea what one cause could ne + nfval = + ath9k_hw_get_nf_limits(ah, chan)->cal[i]; + if (nfval > -60 || nfval < -127) + nfval = default_nf; This is just a check to make sure we have sane calibrated values. Anything above -60 or under -127 will not work so we take nominal value. this code here will allways return the default_nf since all possible returned values are within that range and the || is likelly wrong too and must be replaced with &&. but the range itself looks bogus. can't be right so please do me a favor and test your code against 9280 chipsets too and check if its working. right now its a full regression incidence and should be reverted Am 26.01.2018 um 12:07 schrieb Wojciech Dubowik: Are you sure you have applied path 4 in the series. You should see calibration piers. Sth like: Calibration data Chain 0 Freq ref volt temp nf_cal nf_pow rx_temp 2412 14 0 136 0 0 0 2437 13 0 136 0 0 0 2472 11 0 136 0 0 0 Chain 1 Freq ref volt temp nf_cal nf_pow rx_temp 2412 11 0 137 0 0 0 2437 11 0 139 0 0 0 2472 10 0 137 0 0 0 Chain 2 Freq ref volt temp nf_cal nf_pow rx_temp 2412 13 0 138 0 0 0 2437 14 0 139 0 0 0 2472 14 0 139 0 0 0 I have just done backports from ath.git and I can see these entries with my Compex card. Wojtek On 26/01/18 11:36, Sebastian Gottschall wrote: Am 26.01.2018 um 11:27 schrieb Wojciech Dubowik: I will try it with again with couple of OEM cards. this is no card. the eeprom is stored in flash memory. so the chip is a 9280 pcie chip which is connected on board, but has no own flash memory for calibration data. this is stored in system flash memory Is nanostation calibrated for noisefloor? You can see it with modal_eeprom in debugfs. root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom 2GHz modal Header : Chain0 Ant. Control : 0 Chain1 Ant. Control : 0 Chain2 Ant. Control : 0 Ant. Common Control : 0 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 11 Chain1 TxRxAtten : 11 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 11 Chain1 RxTxMargin : 11 Chain2 RxTxMargin : 11 ADC Desired size : 224 PGA Desired size : 0 Chain0 xlna Gain : 14 Chain1 xlna Gain : 14 Chain2 xlna Gain : 14 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 0 Chain0 NF Threshold : 202 Chain1 NF Threshold : 202 Chain2 NF Threshold : 202 xpdGain : 9 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient : 0 Chain2 Q Coefficient : 0 pdGainOverlap : 6 Chain0 OutputBias : 2 Chain0 DriverBias : 2 xPA Bias Level : 0 2chain pwr decrease : 0 3chain pwr decrease : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 2 Chain0 bswAtten : 21 Chain1 bswAtten : 21 Chain2 bswAtten : 0 Chain0 bswMargin : 31 Chain1 bswMargin : 31 Chain2 bswMargin : 0 HT40 Switch Settle : 44 Chain0 xatten2Db : 0 Chain1 xatten2Db : 0 Chain2 xatten2Db : 0 Chain0 xatten2Margin : 0 Chain1 xatten2Margin : 0 Chain2 xatten2Margin : 0 Chain1 OutputBias : 2 Chain1 DriverBias : 2 LNA Control : 13 XPA Bias Freq0 : 0 XPA Bias Freq1 : 0 XPA Bias Freq2 : 0 5GHz modal Header : Chain0 Ant. Control : 16 Chain1 Ant. Control : 16 Chain2 Ant. Control : 0 Ant. Common Control : 288 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 32 Chain1 TxRxAtten : 32 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 0 Chain1 RxTxMargin : 0 Chain2 RxTxMargin : 16 ADC Desired size : 226 PGA Desired size : 0 Chain0 xlna Gain : 13 Chain1 xlna Gain : 13 Chain2 xlna Gain : 13 txEndToXpaOff : 0 txEndToRxOn : 2
Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support
On 26/01/18 12:35, Sebastian Gottschall wrote: after reverting your patches all looks normal again. noise is -95 root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat dump_nfcal Channel Noise Floor : -95 Chain | privNF | # Readings | NF Readings 0 -108 5 -108 -108 -107 -108 -108 1 -106 5 -106 -106 -106 -105 -106 I will send a patch which fixes it. I have been taking per chain nominal noise which is not the same as per channel noise. root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom 2GHz modal Header : Chain0 Ant. Control : 0 Chain1 Ant. Control : 0 Chain2 Ant. Control : 0 Ant. Common Control : 0 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 11 Chain1 TxRxAtten : 11 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 11 Chain1 RxTxMargin : 11 Chain2 RxTxMargin : 11 ADC Desired size : 224 PGA Desired size : 0 Chain0 xlna Gain : 14 Chain1 xlna Gain : 14 Chain2 xlna Gain : 14 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 0 Chain0 NF Threshold : 202 Chain1 NF Threshold : 202 Chain2 NF Threshold : 202 xpdGain : 9 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient : 0 Chain2 Q Coefficient : 0 pdGainOverlap : 6 Chain0 OutputBias : 2 Chain0 DriverBias : 2 xPA Bias Level : 0 2chain pwr decrease : 0 3chain pwr decrease : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 2 Chain0 bswAtten : 21 Chain1 bswAtten : 21 Chain2 bswAtten : 0 Chain0 bswMargin : 31 Chain1 bswMargin : 31 Chain2 bswMargin : 0 HT40 Switch Settle : 44 Chain0 xatten2Db : 0 Chain1 xatten2Db : 0 Chain2 xatten2Db : 0 Chain0 xatten2Margin : 0 Chain1 xatten2Margin : 0 Chain2 xatten2Margin : 0 Chain1 OutputBias : 2 Chain1 DriverBias : 2 LNA Control : 13 XPA Bias Freq0 : 0 XPA Bias Freq1 : 0 XPA Bias Freq2 : 0 5GHz modal Header : Chain0 Ant. Control : 16 Chain1 Ant. Control : 16 Chain2 Ant. Control : 0 Ant. Common Control : 288 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 32 Chain1 TxRxAtten : 32 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 0 Chain1 RxTxMargin : 0 Chain2 RxTxMargin : 16 ADC Desired size : 226 PGA Desired size : 0 Chain0 xlna Gain : 13 Chain1 xlna Gain : 13 Chain2 xlna Gain : 13 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 28 Chain0 NF Threshold : 255 Chain1 NF Threshold : 255 Chain2 NF Threshold : 255 xpdGain : 1 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient : 0 Chain2 Q Coefficient : 0 pdGainOverlap : 6 Chain0 OutputBias : 3 Chain0 DriverBias : 3 xPA Bias Level : 2 2chain pwr decrease : 0 3chain pwr decrease : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 0 Chain0 bswAtten : 34 Chain1 bswAtten : 34 Chain2 bswAtten : 0 Chain0 bswMargin : 22 Chain1 bswMargin : 22 Chain2 bswMargin : 0 HT40 Switch Settle : 45 Chain0 xatten2Db : 0 Chain1 xatten2Db : 0 Chain2 xatten2Db : 0 Chain0 xatten2Margin : 0 Chain1 xatten2Margin : 0 Chain2 xatten2Margin : 0 Chain1 OutputBias : 3 Chain1 DriverBias : 3 LNA Control : 13 XPA Bias Freq0 : 0 XPA Bias Freq1 : 0 XPA Bias Freq2 : 0 Am 26.01.2018 um 12:07 schrieb Wojciech Dubowik: Are you sure you have applied path 4 in the series. You should see calibration piers. Sth like: Calibration data Chain 0
Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support
i have a idea what one cause could ne + nfval = + ath9k_hw_get_nf_limits(ah, chan)->cal[i]; + if (nfval > -60 || nfval < -127) + nfval = default_nf; this code here will allways return the default_nf since all possible returned values are within that range and the || is likelly wrong too and must be replaced with &&. but the range itself looks bogus. can't be right so please do me a favor and test your code against 9280 chipsets too and check if its working. right now its a full regression incidence and should be reverted Am 26.01.2018 um 12:07 schrieb Wojciech Dubowik: Are you sure you have applied path 4 in the series. You should see calibration piers. Sth like: Calibration data Chain 0 Freq ref volt temp nf_cal nf_pow rx_temp 2412 14 0 136 0 0 0 2437 13 0 136 0 0 0 2472 11 0 136 0 0 0 Chain 1 Freq ref volt temp nf_cal nf_pow rx_temp 2412 11 0 137 0 0 0 2437 11 0 139 0 0 0 2472 10 0 137 0 0 0 Chain 2 Freq ref volt temp nf_cal nf_pow rx_temp 2412 13 0 138 0 0 0 2437 14 0 139 0 0 0 2472 14 0 139 0 0 0 I have just done backports from ath.git and I can see these entries with my Compex card. Wojtek On 26/01/18 11:36, Sebastian Gottschall wrote: Am 26.01.2018 um 11:27 schrieb Wojciech Dubowik: I will try it with again with couple of OEM cards. this is no card. the eeprom is stored in flash memory. so the chip is a 9280 pcie chip which is connected on board, but has no own flash memory for calibration data. this is stored in system flash memory Is nanostation calibrated for noisefloor? You can see it with modal_eeprom in debugfs. root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom 2GHz modal Header : Chain0 Ant. Control : 0 Chain1 Ant. Control : 0 Chain2 Ant. Control : 0 Ant. Common Control : 0 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 11 Chain1 TxRxAtten : 11 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 11 Chain1 RxTxMargin : 11 Chain2 RxTxMargin : 11 ADC Desired size : 224 PGA Desired size : 0 Chain0 xlna Gain : 14 Chain1 xlna Gain : 14 Chain2 xlna Gain : 14 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 0 Chain0 NF Threshold : 202 Chain1 NF Threshold : 202 Chain2 NF Threshold : 202 xpdGain : 9 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient : 0 Chain2 Q Coefficient : 0 pdGainOverlap : 6 Chain0 OutputBias : 2 Chain0 DriverBias : 2 xPA Bias Level : 0 2chain pwr decrease : 0 3chain pwr decrease : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 2 Chain0 bswAtten : 21 Chain1 bswAtten : 21 Chain2 bswAtten : 0 Chain0 bswMargin : 31 Chain1 bswMargin : 31 Chain2 bswMargin : 0 HT40 Switch Settle : 44 Chain0 xatten2Db : 0 Chain1 xatten2Db : 0 Chain2 xatten2Db : 0 Chain0 xatten2Margin : 0 Chain1 xatten2Margin : 0 Chain2 xatten2Margin : 0 Chain1 OutputBias : 2 Chain1 DriverBias : 2 LNA Control : 13 XPA Bias Freq0 : 0 XPA Bias Freq1 : 0 XPA Bias Freq2 : 0 5GHz modal Header : Chain0 Ant. Control : 16 Chain1 Ant. Control : 16 Chain2 Ant. Control : 0 Ant. Common Control : 288 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 32 Chain1 TxRxAtten : 32 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 0 Chain1 RxTxMargin : 0 Chain2 RxTxMargin : 16 ADC Desired size : 226 PGA Desired size : 0 Chain0 xlna Gain : 13 Chain1 xlna Gain : 13 Chain2 xlna Gain : 13 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 28 Chain0 NF Threshold : 255 Chain1 NF Threshold : 255
Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support
after reverting your patches all looks normal again. noise is -95 root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat dump_nfcal Channel Noise Floor : -95 Chain | privNF | # Readings | NF Readings 0 -108 5 -108 -108 -107 -108 -108 1 -106 5 -106 -106 -106 -105 -106 root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom 2GHz modal Header : Chain0 Ant. Control : 0 Chain1 Ant. Control : 0 Chain2 Ant. Control : 0 Ant. Common Control : 0 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 11 Chain1 TxRxAtten : 11 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 11 Chain1 RxTxMargin : 11 Chain2 RxTxMargin : 11 ADC Desired size : 224 PGA Desired size : 0 Chain0 xlna Gain : 14 Chain1 xlna Gain : 14 Chain2 xlna Gain : 14 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 0 Chain0 NF Threshold : 202 Chain1 NF Threshold : 202 Chain2 NF Threshold : 202 xpdGain : 9 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient : 0 Chain2 Q Coefficient : 0 pdGainOverlap : 6 Chain0 OutputBias : 2 Chain0 DriverBias : 2 xPA Bias Level : 0 2chain pwr decrease : 0 3chain pwr decrease : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 2 Chain0 bswAtten : 21 Chain1 bswAtten : 21 Chain2 bswAtten : 0 Chain0 bswMargin : 31 Chain1 bswMargin : 31 Chain2 bswMargin : 0 HT40 Switch Settle : 44 Chain0 xatten2Db : 0 Chain1 xatten2Db : 0 Chain2 xatten2Db : 0 Chain0 xatten2Margin : 0 Chain1 xatten2Margin : 0 Chain2 xatten2Margin : 0 Chain1 OutputBias : 2 Chain1 DriverBias : 2 LNA Control : 13 XPA Bias Freq0 : 0 XPA Bias Freq1 : 0 XPA Bias Freq2 : 0 5GHz modal Header : Chain0 Ant. Control : 16 Chain1 Ant. Control : 16 Chain2 Ant. Control : 0 Ant. Common Control : 288 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 32 Chain1 TxRxAtten : 32 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 0 Chain1 RxTxMargin : 0 Chain2 RxTxMargin : 16 ADC Desired size : 226 PGA Desired size : 0 Chain0 xlna Gain : 13 Chain1 xlna Gain : 13 Chain2 xlna Gain : 13 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 28 Chain0 NF Threshold : 255 Chain1 NF Threshold : 255 Chain2 NF Threshold : 255 xpdGain : 1 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient : 0 Chain2 Q Coefficient : 0 pdGainOverlap : 6 Chain0 OutputBias : 3 Chain0 DriverBias : 3 xPA Bias Level : 2 2chain pwr decrease : 0 3chain pwr decrease : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 0 Chain0 bswAtten : 34 Chain1 bswAtten : 34 Chain2 bswAtten : 0 Chain0 bswMargin : 22 Chain1 bswMargin : 22 Chain2 bswMargin : 0 HT40 Switch Settle : 45 Chain0 xatten2Db : 0 Chain1 xatten2Db : 0 Chain2 xatten2Db : 0 Chain0 xatten2Margin : 0 Chain1 xatten2Margin : 0 Chain2 xatten2Margin : 0 Chain1 OutputBias : 3 Chain1 DriverBias : 3 LNA Control : 13 XPA Bias Freq0 : 0 XPA Bias Freq1 : 0 XPA Bias Freq2 : 0 Am 26.01.2018 um 12:07 schrieb Wojciech Dubowik: Are you sure you have applied path 4 in the series. You should see calibration piers. Sth like: Calibration data Chain 0 Freq ref volt temp nf_cal nf_pow rx_temp 2412 14 0 136 0 0 0 2437 13 0 136 0 0 0 2472 11 0 136 0 0 0 Ch
Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support
Am 26.01.2018 um 12:07 schrieb Wojciech Dubowik: Are you sure you have applied path 4 in the series. You should see calibration piers. Sth like: yes. all of them root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat dump_nfcal Channel Noise Floor : -112 Chain | privNF | # Readings | NF Readings 0 -107 5 -107 -107 -107 -108 -108 1 -106 5 -106 -106 -106 -106 -106 but looks different from yours, but chipset is 9280 as i said. let me just revert your 4 patches to see if it changes the behaviour Calibration data Chain 0 Freq ref volt temp nf_cal nf_pow rx_temp 2412 14 0 136 0 0 0 2437 13 0 136 0 0 0 2472 11 0 136 0 0 0 Chain 1 Freq ref volt temp nf_cal nf_pow rx_temp 2412 11 0 137 0 0 0 2437 11 0 139 0 0 0 2472 10 0 137 0 0 0 Chain 2 Freq ref volt temp nf_cal nf_pow rx_temp 2412 13 0 138 0 0 0 2437 14 0 139 0 0 0 2472 14 0 139 0 0 0 I have just done backports from ath.git and I can see these entries with my Compex card. Wojtek On 26/01/18 11:36, Sebastian Gottschall wrote: Am 26.01.2018 um 11:27 schrieb Wojciech Dubowik: I will try it with again with couple of OEM cards. this is no card. the eeprom is stored in flash memory. so the chip is a 9280 pcie chip which is connected on board, but has no own flash memory for calibration data. this is stored in system flash memory Is nanostation calibrated for noisefloor? You can see it with modal_eeprom in debugfs. root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom 2GHz modal Header : Chain0 Ant. Control : 0 Chain1 Ant. Control : 0 Chain2 Ant. Control : 0 Ant. Common Control : 0 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 11 Chain1 TxRxAtten : 11 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 11 Chain1 RxTxMargin : 11 Chain2 RxTxMargin : 11 ADC Desired size : 224 PGA Desired size : 0 Chain0 xlna Gain : 14 Chain1 xlna Gain : 14 Chain2 xlna Gain : 14 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 0 Chain0 NF Threshold : 202 Chain1 NF Threshold : 202 Chain2 NF Threshold : 202 xpdGain : 9 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient : 0 Chain2 Q Coefficient : 0 pdGainOverlap : 6 Chain0 OutputBias : 2 Chain0 DriverBias : 2 xPA Bias Level : 0 2chain pwr decrease : 0 3chain pwr decrease : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 2 Chain0 bswAtten : 21 Chain1 bswAtten : 21 Chain2 bswAtten : 0 Chain0 bswMargin : 31 Chain1 bswMargin : 31 Chain2 bswMargin : 0 HT40 Switch Settle : 44 Chain0 xatten2Db : 0 Chain1 xatten2Db : 0 Chain2 xatten2Db : 0 Chain0 xatten2Margin : 0 Chain1 xatten2Margin : 0 Chain2 xatten2Margin : 0 Chain1 OutputBias : 2 Chain1 DriverBias : 2 LNA Control : 13 XPA Bias Freq0 : 0 XPA Bias Freq1 : 0 XPA Bias Freq2 : 0 5GHz modal Header : Chain0 Ant. Control : 16 Chain1 Ant. Control : 16 Chain2 Ant. Control : 0 Ant. Common Control : 288 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 32 Chain1 TxRxAtten : 32 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 0 Chain1 RxTxMargin : 0 Chain2 RxTxMargin : 16 ADC Desired size : 226 PGA Desired size : 0 Chain0 xlna Gain : 13 Chain1 xlna Gain : 13 Chain2 xlna Gain : 13 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 28 Chain0 NF Threshold : 255 Chain1 NF Threshold : 255 Chain2 NF Threshold : 255 xpdGain : 1 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient :
Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support
Are you sure you have applied path 4 in the series. You should see calibration piers. Sth like: Calibration data Chain 0 Freq ref volt temp nf_cal nf_pow rx_temp 2412 14 0 136 0 0 0 2437 13 0 136 0 0 0 2472 11 0 136 0 0 0 Chain 1 Freq ref volt temp nf_cal nf_pow rx_temp 2412 11 0 137 0 0 0 2437 11 0 139 0 0 0 2472 10 0 137 0 0 0 Chain 2 Freq ref volt temp nf_cal nf_pow rx_temp 2412 13 0 138 0 0 0 2437 14 0 139 0 0 0 2472 14 0 139 0 0 0 I have just done backports from ath.git and I can see these entries with my Compex card. Wojtek On 26/01/18 11:36, Sebastian Gottschall wrote: Am 26.01.2018 um 11:27 schrieb Wojciech Dubowik: I will try it with again with couple of OEM cards. this is no card. the eeprom is stored in flash memory. so the chip is a 9280 pcie chip which is connected on board, but has no own flash memory for calibration data. this is stored in system flash memory Is nanostation calibrated for noisefloor? You can see it with modal_eeprom in debugfs. root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom 2GHz modal Header : Chain0 Ant. Control : 0 Chain1 Ant. Control : 0 Chain2 Ant. Control : 0 Ant. Common Control : 0 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 11 Chain1 TxRxAtten : 11 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 11 Chain1 RxTxMargin : 11 Chain2 RxTxMargin : 11 ADC Desired size : 224 PGA Desired size : 0 Chain0 xlna Gain : 14 Chain1 xlna Gain : 14 Chain2 xlna Gain : 14 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 0 Chain0 NF Threshold : 202 Chain1 NF Threshold : 202 Chain2 NF Threshold : 202 xpdGain : 9 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient : 0 Chain2 Q Coefficient : 0 pdGainOverlap : 6 Chain0 OutputBias : 2 Chain0 DriverBias : 2 xPA Bias Level : 0 2chain pwr decrease : 0 3chain pwr decrease : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 2 Chain0 bswAtten : 21 Chain1 bswAtten : 21 Chain2 bswAtten : 0 Chain0 bswMargin : 31 Chain1 bswMargin : 31 Chain2 bswMargin : 0 HT40 Switch Settle : 44 Chain0 xatten2Db : 0 Chain1 xatten2Db : 0 Chain2 xatten2Db : 0 Chain0 xatten2Margin : 0 Chain1 xatten2Margin : 0 Chain2 xatten2Margin : 0 Chain1 OutputBias : 2 Chain1 DriverBias : 2 LNA Control : 13 XPA Bias Freq0 : 0 XPA Bias Freq1 : 0 XPA Bias Freq2 : 0 5GHz modal Header : Chain0 Ant. Control : 16 Chain1 Ant. Control : 16 Chain2 Ant. Control : 0 Ant. Common Control : 288 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 32 Chain1 TxRxAtten : 32 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 0 Chain1 RxTxMargin : 0 Chain2 RxTxMargin : 16 ADC Desired size : 226 PGA Desired size : 0 Chain0 xlna Gain : 13 Chain1 xlna Gain : 13 Chain2 xlna Gain : 13 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 28 Chain0 NF Threshold : 255 Chain1 NF Threshold : 255 Chain2 NF Threshold : 255 xpdGain : 1 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient : 0 Chain2 Q Coefficient : 0 pdGainOverlap : 6 Chain0 OutputBias : 3 Chain0 DriverBias : 3 xPA Bias Level : 2 2chain pwr decrease : 0 3chain pwr decrease : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 0 Chain0 bswAtten : 34 Chain1 bswAtten : 34 Chain2 bswAtten : 0
Re: [PATCH] mt76: implement AP_LINK_PS
Felix Fietkau writes:
> With software A-MPDU reordering in place, frames that notify mac80211 of
> powersave changes are reordered as well, which can cause connection
> stalls. Fix this by implementing powersave state processing in the
> driver.
>
> Fixes: aee5b8cf2477 ("mt76: implement A-MPDU rx reordering in the driver
> code")
> Signed-off-by: Felix Fietkau
I'm planning to queue this to 4.16.
--
Kalle Valo
[PATCH] mt76: implement AP_LINK_PS
With software A-MPDU reordering in place, frames that notify mac80211 of
powersave changes are reordered as well, which can cause connection
stalls. Fix this by implementing powersave state processing in the
driver.
Fixes: aee5b8cf2477 ("mt76: implement A-MPDU rx reordering in the driver code")
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/mediatek/mt76/mac80211.c| 52 +++-
drivers/net/wireless/mediatek/mt76/mt76.h| 10 +
drivers/net/wireless/mediatek/mt76/mt76x2.h | 2 +
drivers/net/wireless/mediatek/mt76/mt76x2_init.c | 1 +
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 28 ++---
5 files changed, 78 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c
b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 5fcb2deb89a2..85f8d324ebf8 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -276,6 +276,7 @@ int mt76_register_device(struct mt76_dev *dev, bool vht,
ieee80211_hw_set(hw, TX_AMSDU);
ieee80211_hw_set(hw, TX_FRAG_LIST);
ieee80211_hw_set(hw, MFP_CAPABLE);
+ ieee80211_hw_set(hw, AP_LINK_PS);
wiphy->flags |= WIPHY_FLAG_IBSS_RSN;
@@ -470,6 +471,53 @@ mt76_check_ccmp_pn(struct sk_buff *skb)
return 0;
}
+static void
+mt76_check_ps(struct mt76_dev *dev, struct sk_buff *skb)
+{
+ struct mt76_rx_status *status = (struct mt76_rx_status *) skb->cb;
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
+ struct ieee80211_sta *sta;
+ struct mt76_wcid *wcid = status->wcid;
+ bool ps;
+
+ if (!wcid || !wcid->sta)
+ return;
+
+ sta = container_of((void *) wcid, struct ieee80211_sta, drv_priv);
+
+ if (!test_bit(MT_WCID_FLAG_CHECK_PS, &wcid->flags))
+ return;
+
+ if (ieee80211_is_pspoll(hdr->frame_control)) {
+ ieee80211_sta_pspoll(sta);
+ return;
+ }
+
+ if (ieee80211_has_morefrags(hdr->frame_control) ||
+ !(ieee80211_is_mgmt(hdr->frame_control) ||
+ ieee80211_is_data(hdr->frame_control)))
+ return;
+
+ ps = ieee80211_has_pm(hdr->frame_control);
+
+ if (ps && (ieee80211_is_data_qos(hdr->frame_control) ||
+ ieee80211_is_qos_nullfunc(hdr->frame_control)))
+ ieee80211_sta_uapsd_trigger(sta, status->tid);
+
+ if (!!test_bit(MT_WCID_FLAG_PS, &wcid->flags) == ps)
+ return;
+
+ if (ps) {
+ set_bit(MT_WCID_FLAG_PS, &wcid->flags);
+ mt76_stop_tx_queues(dev, sta, true);
+ } else {
+ clear_bit(MT_WCID_FLAG_PS, &wcid->flags);
+ }
+
+ ieee80211_sta_ps_transition(sta, ps);
+ dev->drv->sta_ps(dev, sta, ps);
+}
+
void mt76_rx_complete(struct mt76_dev *dev, struct sk_buff_head *frames,
int queue)
{
@@ -498,8 +546,10 @@ void mt76_rx_poll_complete(struct mt76_dev *dev, enum
mt76_rxq_id q)
__skb_queue_head_init(&frames);
- while ((skb = __skb_dequeue(&dev->rx_skb[q])) != NULL)
+ while ((skb = __skb_dequeue(&dev->rx_skb[q])) != NULL) {
+ mt76_check_ps(dev, skb);
mt76_rx_aggr_reorder(skb, &frames);
+ }
mt76_rx_complete(dev, &frames, q);
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h
b/drivers/net/wireless/mediatek/mt76/mt76.h
index 129015c9d116..d2ce15093edd 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -121,11 +121,18 @@ struct mt76_queue_ops {
void (*kick)(struct mt76_dev *dev, struct mt76_queue *q);
};
+enum mt76_wcid_flags {
+ MT_WCID_FLAG_CHECK_PS,
+ MT_WCID_FLAG_PS,
+};
+
struct mt76_wcid {
struct mt76_rx_tid __rcu *aggr[IEEE80211_NUM_TIDS];
struct work_struct aggr_work;
+ unsigned long flags;
+
u8 idx;
u8 hw_key_idx;
@@ -206,6 +213,9 @@ struct mt76_driver_ops {
struct sk_buff *skb);
void (*rx_poll_complete)(struct mt76_dev *dev, enum mt76_rxq_id q);
+
+ void (*sta_ps)(struct mt76_dev *dev, struct ieee80211_sta *sta,
+ bool ps);
};
struct mt76_channel_state {
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2.h
b/drivers/net/wireless/mediatek/mt76/mt76x2.h
index 17df17afd9bf..e62131b88102 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2.h
@@ -218,6 +218,8 @@ void mt76x2_rx_poll_complete(struct mt76_dev *mdev, enum
mt76_rxq_id q);
void mt76x2_queue_rx_skb(struct mt76_dev *mdev, enum mt76_rxq_id q,
struct sk_buff *skb);
+void mt76x2_sta_ps(struct mt76_dev *dev, struct ieee80211_sta *sta, bool ps);
+
void mt76x2_update_channel(struct mt76_dev *mdev);
s8 mt76x2_tx_get_max_txpwr_adj(struct mt76x2_dev *dev,
diff --git a/drivers/net
Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support
Am 26.01.2018 um 11:27 schrieb Wojciech Dubowik: I will try it with again with couple of OEM cards. this is no card. the eeprom is stored in flash memory. so the chip is a 9280 pcie chip which is connected on board, but has no own flash memory for calibration data. this is stored in system flash memory Is nanostation calibrated for noisefloor? You can see it with modal_eeprom in debugfs. root@TRO2:/sys/kernel/debug/ieee80211/phy0/ath9k# cat modal_eeprom 2GHz modal Header : Chain0 Ant. Control : 0 Chain1 Ant. Control : 0 Chain2 Ant. Control : 0 Ant. Common Control : 0 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 11 Chain1 TxRxAtten : 11 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 11 Chain1 RxTxMargin : 11 Chain2 RxTxMargin : 11 ADC Desired size : 224 PGA Desired size : 0 Chain0 xlna Gain : 14 Chain1 xlna Gain : 14 Chain2 xlna Gain : 14 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 0 Chain0 NF Threshold : 202 Chain1 NF Threshold : 202 Chain2 NF Threshold : 202 xpdGain : 9 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient : 0 Chain2 Q Coefficient : 0 pdGainOverlap : 6 Chain0 OutputBias : 2 Chain0 DriverBias : 2 xPA Bias Level : 0 2chain pwr decrease : 0 3chain pwr decrease : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 2 Chain0 bswAtten : 21 Chain1 bswAtten : 21 Chain2 bswAtten : 0 Chain0 bswMargin : 31 Chain1 bswMargin : 31 Chain2 bswMargin : 0 HT40 Switch Settle : 44 Chain0 xatten2Db : 0 Chain1 xatten2Db : 0 Chain2 xatten2Db : 0 Chain0 xatten2Margin : 0 Chain1 xatten2Margin : 0 Chain2 xatten2Margin : 0 Chain1 OutputBias : 2 Chain1 DriverBias : 2 LNA Control : 13 XPA Bias Freq0 : 0 XPA Bias Freq1 : 0 XPA Bias Freq2 : 0 5GHz modal Header : Chain0 Ant. Control : 16 Chain1 Ant. Control : 16 Chain2 Ant. Control : 0 Ant. Common Control : 288 Chain0 Ant. Gain : 0 Chain1 Ant. Gain : 0 Chain2 Ant. Gain : 0 Switch Settle : 45 Chain0 TxRxAtten : 32 Chain1 TxRxAtten : 32 Chain2 TxRxAtten : 11 Chain0 RxTxMargin : 0 Chain1 RxTxMargin : 0 Chain2 RxTxMargin : 16 ADC Desired size : 226 PGA Desired size : 0 Chain0 xlna Gain : 13 Chain1 xlna Gain : 13 Chain2 xlna Gain : 13 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 28 Chain0 NF Threshold : 255 Chain1 NF Threshold : 255 Chain2 NF Threshold : 255 xpdGain : 1 External PD : 1 Chain0 I Coefficient : 0 Chain1 I Coefficient : 0 Chain2 I Coefficient : 0 Chain0 Q Coefficient : 0 Chain1 Q Coefficient : 0 Chain2 Q Coefficient : 0 pdGainOverlap : 6 Chain0 OutputBias : 3 Chain0 DriverBias : 3 xPA Bias Level : 2 2chain pwr decrease : 0 3chain pwr decrease : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 0 Chain0 bswAtten : 34 Chain1 bswAtten : 34 Chain2 bswAtten : 0 Chain0 bswMargin : 22 Chain1 bswMargin : 22 Chain2 bswMargin : 0 HT40 Switch Settle : 45 Chain0 xatten2Db : 0 Chain1 xatten2Db : 0 Chain2 xatten2Db : 0 Chain0 xatten2Margin : 0 Chain1 xatten2Margin : 0 Chain2 xatten2Margin : 0 Chain1 OutputBias : 3 Chain1 DriverBias : 3 LNA Control : 13 XPA Bias Freq0 : 0 XPA Bias Freq1 : 0 XPA Bias Freq2 : 0 Wojtek On 26/01/18 10:59, Sebastian Gottschall wrote: i dont know if this is a coincidence. but after testing your patch on a standard ubiquiti nanostation m2 the noise floor looks wrong. it will stay on -112 which is clearly impossible in 2.4 (before it was around
Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support
I will try it with again with couple of OEM cards. Is nanostation calibrated for noisefloor? You can see it with modal_eeprom in debugfs. Wojtek On 26/01/18 10:59, Sebastian Gottschall wrote: i dont know if this is a coincidence. but after testing your patch on a standard ubiquiti nanostation m2 the noise floor looks wrong. it will stay on -112 which is clearly impossible in 2.4 (before it was around -96)
Re: [PATCH 0/4] ath9k: AR9003 noise floor calibration support
i dont know if this is a coincidence. but after testing your patch on a standard ubiquiti nanostation m2 the noise floor looks wrong. it will stay on -112 which is clearly impossible in 2.4 (before it was around -96) Sebastian Am 23.01.2018 um 08:56 schrieb Kalle Valo: Wojciech Dubowik writes: AR9003 series allows to calibrate noise floor for different frequency bins. Once it's done it's possible to get more accurate rssi/signal values over whole frequency band at a given temperature. The RSSI/signal accuracy reported by calibrated RF cards improves from 6 to up to 2dB. This could be interesting for application which require good signal accuracy like roaming or mesh protocols. This is a very good description of the feature. I think you should copy it to the patch 3 commit log so that it gets archived to git. (I don't store cover letters to git.) -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565
Re: [PATCH] ssb: Do not disable PCI host on non-Mips
On Fri, Jan 26, 2018 at 10:38:01AM +0100, Sven Joachim wrote:
> After upgrading an old laptop to 4.15-rc9, I found that the eth0 and
> wlan0 interfaces had disappeared. It turns out that the b43 and b44
> drivers require SSB_PCIHOST_POSSIBLE which depends on
> PCI_DRIVERS_LEGACY, a config option that only exists on Mips.
>
> Fixes: 58eae1416b80 ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC")
> Cc: sta...@vger.org
> Signed-off-by: Sven Joachim
Whoops, thats a very good point. I hadn't twigged that
PCI_DRIVERS_LEGACY was MIPS specific (one of the disadvantages of using
"tig grep" I suppose!).
Reviewed-by: James Hogan
I think this is obviously correct, so it'd be great to squeeze it into
4.15 final.
Fortunately the other related change, commit 664eadd6f44b ("bcma: Fix
'allmodconfig' and BCMA builds on MIPS targets"), already depends on
MIPS so doesn't have the same issue.
Sorry for the breakage!
James
> ---
> drivers/ssb/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig
> index 71c73766ee22..65af12c3bdb2 100644
> --- a/drivers/ssb/Kconfig
> +++ b/drivers/ssb/Kconfig
> @@ -32,7 +32,7 @@ config SSB_BLOCKIO
>
> config SSB_PCIHOST_POSSIBLE
> bool
> - depends on SSB && (PCI = y || PCI = SSB) && PCI_DRIVERS_LEGACY
> + depends on SSB && (PCI = y || PCI = SSB) && (PCI_DRIVERS_LEGACY ||
> !MIPS)
> default y
>
> config SSB_PCIHOST
> --
> 2.15.1
>
signature.asc
Description: Digital signature
[PATCH] ssb: Do not disable PCI host on non-Mips
After upgrading an old laptop to 4.15-rc9, I found that the eth0 and
wlan0 interfaces had disappeared. It turns out that the b43 and b44
drivers require SSB_PCIHOST_POSSIBLE which depends on
PCI_DRIVERS_LEGACY, a config option that only exists on Mips.
Fixes: 58eae1416b80 ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC")
Cc: sta...@vger.org
Signed-off-by: Sven Joachim
---
drivers/ssb/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig
index 71c73766ee22..65af12c3bdb2 100644
--- a/drivers/ssb/Kconfig
+++ b/drivers/ssb/Kconfig
@@ -32,7 +32,7 @@ config SSB_BLOCKIO
config SSB_PCIHOST_POSSIBLE
bool
- depends on SSB && (PCI = y || PCI = SSB) && PCI_DRIVERS_LEGACY
+ depends on SSB && (PCI = y || PCI = SSB) && (PCI_DRIVERS_LEGACY ||
!MIPS)
default y
config SSB_PCIHOST
--
2.15.1
Re: [v2,8/8] mt76: validate rx CCMP PN
Felix Fietkau wrote: > Apparently hardware does not perform CCMP PN validation in hardware, so > we need to take care of this in the driver. This is important for > protecting against replay attacks. > > Since validation of fragmented frames is more complex, the CCMP header > for those is preserved. To keep the counter in sync, the first fragment > is verified by both mt76 and mac80211, and all other fragments only by > mac80211. > > Signed-off-by: Felix Fietkau Patch applied to wireless-drivers-next.git, thanks. 30ce7f4456ae mt76: validate rx CCMP PN -- https://patchwork.kernel.org/patch/10183891/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [1/8] mt76: retry rx polling as long as there is budget left
Felix Fietkau wrote: > Sending frames to mac80211 needs time, which could allow for more rx > packets to end up in the DMA ring. Retry polling until there are no more > frames left. Improves rx latency under load. > > Signed-off-by: Felix Fietkau 7 patches applied to wireless-drivers-next.git, thanks. 2b4307f538ab mt76: retry rx polling as long as there is budget left 1342cfea315a mt76: fix TSF value in probe responses 4e34249e9565 mt76: add an intermediate struct for rx status information 9c68a57bc22d mt76: get station pointer by wcid and pass it to mac80211 aee5b8cf2477 mt76: implement A-MPDU rx reordering in the driver code 9d9d738b4b54 mt76: split mt76_rx_complete 3675302de8e9 mt76: pass the per-vif wcid to the core for multicast rx -- https://patchwork.kernel.org/patch/10182707/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init
After checking all possible call chains to bcma_pmu_resources_init() here, my tool finds that this function is never called in atomic context, namely never in an interrupt handler or holding a spinlock. Thus mdelay can be replaced with usleep_range to avoid busy wait. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai --- drivers/bcma/driver_chipcommon_pmu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bcma/driver_chipcommon_pmu.c b/drivers/bcma/driver_chipcommon_pmu.c index f1eb4d3..478948c 100644 --- a/drivers/bcma/driver_chipcommon_pmu.c +++ b/drivers/bcma/driver_chipcommon_pmu.c @@ -203,7 +203,7 @@ static void bcma_pmu_resources_init(struct bcma_drv_cc *cc) * Add some delay; allow resources to come up and settle. * Delay is required for SoC (early init). */ - mdelay(2); + usleep_range(1500, 2000); } /* Disable to allow reading SPROM. Don't know the adventages of enabling it. */ -- 1.7.9.5
Re: sdio failure to initialize on warm boot.
* Arend van Spriel :
> On 1/19/2018 5:05 PM, Kyle Evans wrote:
> > * Arend van Spriel :
> >> On 1/18/2018 6:50 PM, Kyle Evans wrote:
> >>> * Arend van Spriel :
> On 1/12/2018 9:18 PM, Kyle Evans wrote:
> > 2) After reboot I get this nasty error...
> > [0.00] Kernel command line: console=tty0 selinux=0
> > video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x2
> > [2.269750] mmc0: Invalid maximum block size, assuming 512 bytes
> > [2.330010] mmc0: SDHCI controller on c800.sdhci [c800.sdhci]
> > using ADMA
> > [2.645242] mmc0: error -110 whilst initialising SDIO card
>
> Ok. I suppose you mean a warm reboot. So I suppose the card is not
> properly power cycled. If your SDHCI controller driver (is it
> sdhci-acpi?) is loaded as a module, you could try to unload it and load
> it again. Let me know if that works for you to confirm my guess.
> >>>
> >>> Your guess is correct. The following brings up wifi after failure to do
> >>> so during warm boot.
> >>>
> >>> modprobe -r sdhci-tegra; modprobe sdhci-tegra;
> >>
> >> Do you know if your uses a device tree and where I can find it?
> >> Typically, there is a GPIO to the wifi device that needs to be toggled
> >> using mmc powerseq.
> >
> > I had a hunch this is was the next step. This device did not ship with a
> > DT, but I have one in the works. My initial trial & error has been met
> > with error.
>
> So I am getting predictable huh?
>
> > This is what I have so far, which is wrong since adding pwrseq (boot panic):
> > sdhci@c800 {
> > compatible = "nvidia,tegra20-sdhci";
> > reg = <0xc800 0x200>;
> > interrupts = ;
> > clocks = <&tegra_car TEGRA20_CLK_SDMMC1>;
> > resets = <&tegra_car 14>;
> > reset-names = "sdhci";
> >
> > status = "okay";
> > //power-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
> > bus-width = <4>;
> > keep-power-in-suspend;
> > non-removable;
> > mmc-pwrseq = <&wlan_rst>;
> >
> > brcmf: wifi@1 {
> > compatible = "brcm,bcm4329-fmac";
> > interrupt-parent = <&gpio>;
> > interrupts = ,
> > ;
> > interrupt-names = "host-wake";
>
> Always having a hard time reading this stuff. So does interrupts
> property state 2 interrupts here?
Ok, I've slimmed it down to only S,0-"host-wake".
> If so, than interrupt-names should
> also have two names. Actually, according to the binding only a single
> interrupt should be given (only (S, 0) I think). Furthermore, you are
> missing the 'reg' property to specify the SDIO function, ie. "reg = <1>;".
I took the reg property out becuase it causes the below compiler
warnings. Putting it back in causes a black screen with no console
output. Any clues?
arch/arm/boot/dts/tegra20-tf101.dtb: Warning (reg_format): "reg"
property in /sdhci@c800/wifi@1 has invalid length (4 bytes)
(#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/tegra20-tf101.dtb: Warning (avoid_default_addr_size):
Relying on default #address-cells value for /sdhci@c800/wifi@1
arch/arm/boot/dts/tegra20-tf101.dtb: Warning (avoid_default_addr_size):
Relying on default #size-cells value for /sdhci@c800/wifi@1
>
> > };
> > };
> >
> > wlan_rst: sdhci0_pwrseq {
> > compatible = "mmc-pwrseq-simple";
> > reset-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_LOW>;
> > };
>
> Ignoring the ext_clk stuff, the pwrseq-simple does following: upon power
> on, set reset-gpios to 1, power on bus, set reset-gpios back to 0,
> optionally wait for post_power_on_delay_ms. The pre-DT kernel stuff is
> different. It simply sets the reset gpio to 1 upon power on, and wait
> for 200ms leaving the gpio as is and does the same for power off.
So pwrseq is the wrong approach here?
wlan_rst: sdhci0_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
//post-power-on-delay-ms = <200>;
post-power-off-delay-us = <200>;
};
I have tested with/without ACTIVE_LOW/HIGH, on/off-delay, all combinations.
Using ACTIVE_HIGH, which is contrary to binding documentation, allows the sdhci
controller to enumerate. It does not enumerate with ACTIVE_LOW. no
combination loads brcmfmac.
I did the same with U,0, which is the rfkill resource, moving K,6 back to
power-gpios. This got me back to square one, works on cold boot only,
with any combination.
It is indicated that power off is were the problem is. On the other
hand, it would seem that there should be a reset mechanism and we
either have the wrong
Re: [PATCH v2] mac80211_hwsim: don't use WQ_MEM_RECLAIM
On Thu, 2018-01-25 at 14:26 -0800, Tejun Heo wrote: > Yeah, that came up a couple years ago. IIRC, there wasn't a definite > answer but the sentiment seemed that things like nfs over wireless > should probably considered. No idea how serious that concern is. Not that you mention it ... Honestly though, wifi connections break all the time, so not sure you'd really want that. But anyway, that's what we have. > So, anything which can sit in memory reclaim path needs to have that > flag set and having that flag set automatically means that it can't > depend on anything which isn't protected the same way as that'd break > that protection. Right. I actually misinterpreted this though - the warning comes from: workqueue: WQ_MEM_RECLAIM hwsim_wq:destroy_radio is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog and it's flushing something in flush_all_backlogs(). Our workqueue here is only at teardown time (when you remove a netdev) so it's not sitting in any critical path for reclaim anyway. So I think this is the right patch, I'll queue it up. Thanks for the reminder on NFS :-) johannes
