Re: ath10k mesh + ap + encryption?

[Pedersen, Thomas]

On Mon, 2016-09-19 at 08:43 +0200, Simon Wunderlich wrote:
> On Tuesday, September 13, 2016 5:54:38 PM CEST Pedersen, Thomas wrote:
> > On Tue, 2016-09-13 at 14:30 +0200, Simon Wunderlich wrote:
> > 
> > > [...]
> > >
> > > Thanks for the clarification. We will then stick to the 70's branch
> > > then.
> > > 
> > > Does anyone have pointers for the other questions? :) I would believe
> > > hat many 
> > > people would be interested in running AP + Mesh encrypted at the same
> > > time (at 
> > > least in the open source community ...).
> > 
> > 
> > We're testing encrypted AP + Mesh quite successfully right now with
> > this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b
> > 06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip.
> > Which chip are you using? I can poke the firmware guys for possibility
> > of getting a 10.4.3.2 firmware build for it.
> 
> Hi Thomas,
> 
> thanks for the hint! We are using an older QCA9882. I assume your firmware 
> will 
> not work for this one? If you can poke the firmware guys, that would be 
> great. 
> :)

Hi Simon,

According to firmware guys the latest code can actually compile down to
any chipset, so it should simply be a matter of getting builds released.

[PATCH 0/3] Add memory limits to fq.h and mac80211 TXQ

[Toke Høiland-Jørgensen]

This is a series of small patches to avoid OOM conditions on small
wireless devices with the mac80211 intermediate TXQ structure. The
current default limit in fq.h translates to up to 16 Mbytes of memory
usage, which can be fatal to a device with 32 MBytes of total RAM.

Rather than just change the fq_limit, this ports the memory limit
mechanism from the fq_codel qdisc. The second patch in the series just
adds the new fields to the mac80211 'aqm' debugfs file.

The third patch changes mac80211 to set a lower memory limit for non-VHT
devices. The assumption is that (a) for 802.11n and lower 4 Mbytes of
total queue (2048 packets, 64 max-size aggregates) is plenty, and so it
is safe to simply limit the queue size. And (b) that VHT-capable devices
are usually installed in systems equipped with more system memory.

Toke Høiland-Jørgensen (3):
  fq.h: Port memory limit mechanism from fq_codel
  mac80211: Export fq memory limit information in debugfs
  mac80211: Set lower memory limit for non-VHT devices

 include/net/fq.h   |  3 +++
 include/net/fq_impl.h  |  7 ++-
 net/mac80211/debugfs.c |  8 
 net/mac80211/tx.c  | 18 ++
 4 files changed, 35 insertions(+), 1 deletion(-)

-- 
2.9.3

base-commit: fb2a3d5c7c85cb6e8bc88192be919b4ef8d6e630

[PATCH 3/3] mac80211: Set lower memory limit for non-VHT devices

[Toke Høiland-Jørgensen]

Small devices can run out of memory from queueing too many packets. If
VHT is not supported by the PHY, having more than 4 MBytes of total
queue in the TXQ intermediate queues is not needed, and so we can safely
limit the memory usage in these cases and avoid OOM.

Signed-off-by: Toke Høiland-Jørgensen 
---
 net/mac80211/tx.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 1ff08be..82f41fc 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1434,6 +1434,8 @@ int ieee80211_txq_setup_flows(struct ieee80211_local 
*local)
struct fq *fq = >fq;
int ret;
int i;
+   bool supp_vht = false;
+   enum nl80211_band band;
 
if (!local->ops->wake_tx_queue)
return 0;
@@ -1442,6 +1444,22 @@ int ieee80211_txq_setup_flows(struct ieee80211_local 
*local)
if (ret)
return ret;
 
+   /*
+* If the hardware doesn't support VHT, it is safe to limit the maximum
+* queue size. 4 Mbytes is 64 max-size aggregates in 802.11n.
+*/
+   for (band = 0; band < NUM_NL80211_BANDS; band++) {
+   struct ieee80211_supported_band *sband;
+
+   sband = local->hw.wiphy->bands[band];
+   if (!sband)
+   continue;
+
+   supp_vht = supp_vht || sband->vht_cap.vht_supported;
+   }
+   if (!supp_vht)
+   fq->memory_limit = 4 << 20; /* 4 Mbytes */
+
codel_params_init(>cparams);
local->cparams.interval = MS2TIME(100);
local->cparams.target = MS2TIME(20);
-- 
2.9.3

[PATCH 2/3] mac80211: Export fq memory limit information in debugfs

[Toke Høiland-Jørgensen]

Add memory limit, usage and overlimit counter to per-PHY 'aqm' debugfs
file.

Signed-off-by: Toke Høiland-Jørgensen 
---
 net/mac80211/debugfs.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 8ca62b6..f56e2f4 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -89,13 +89,19 @@ static ssize_t aqm_read(struct file *file,
"R fq_flows_cnt %u\n"
"R fq_backlog %u\n"
"R fq_overlimit %u\n"
+   "R fq_overmemory %u\n"
"R fq_collisions %u\n"
+   "R fq_memory_usage %u\n"
+   "RW fq_memory_limit %u\n"
"RW fq_limit %u\n"
"RW fq_quantum %u\n",
fq->flows_cnt,
fq->backlog,
+   fq->overmemory,
fq->overlimit,
fq->collisions,
+   fq->memory_usage,
+   fq->memory_limit,
fq->limit,
fq->quantum);
 
@@ -128,6 +134,8 @@ static ssize_t aqm_write(struct file *file,
 
if (sscanf(buf, "fq_limit %u", >fq.limit) == 1)
return count;
+   else if (sscanf(buf, "fq_memory_limit %u", >fq.memory_limit) == 
1)
+   return count;
else if (sscanf(buf, "fq_quantum %u", >fq.quantum) == 1)
return count;
 
-- 
2.9.3

[PATCH 1/3] fq.h: Port memory limit mechanism from fq_codel

[Toke Høiland-Jørgensen]

The reusable fairness queueing implementation (fq.h) lacks the memory
usage limit that the fq_codel qdisc has. This means that small
devices (e.g. WiFi routers) can run out of memory when flooded with a
large number of packets. This ports the memory limit feature from
fq_codel to fq.h.

Signed-off-by: Toke Høiland-Jørgensen 
---
 include/net/fq.h  | 3 +++
 include/net/fq_impl.h | 7 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/net/fq.h b/include/net/fq.h
index 268b490..6d8521a 100644
--- a/include/net/fq.h
+++ b/include/net/fq.h
@@ -72,9 +72,12 @@ struct fq {
u32 flows_cnt;
u32 perturbation;
u32 limit;
+   u32 memory_limit;
+   u32 memory_usage;
u32 quantum;
u32 backlog;
u32 overlimit;
+   u32 overmemory;
u32 collisions;
 };
 
diff --git a/include/net/fq_impl.h b/include/net/fq_impl.h
index 163f3ed..4e6131c 100644
--- a/include/net/fq_impl.h
+++ b/include/net/fq_impl.h
@@ -29,6 +29,7 @@ static struct sk_buff *fq_flow_dequeue(struct fq *fq,
tin->backlog_packets--;
flow->backlog -= skb->len;
fq->backlog--;
+   fq->memory_usage -= skb->truesize;
 
if (flow->backlog == 0) {
list_del_init(>backlogchain);
@@ -154,6 +155,7 @@ static void fq_tin_enqueue(struct fq *fq,
flow->backlog += skb->len;
tin->backlog_bytes += skb->len;
tin->backlog_packets++;
+   fq->memory_usage += skb->truesize;
fq->backlog++;
 
fq_recalc_backlog(fq, tin, flow);
@@ -166,7 +168,7 @@ static void fq_tin_enqueue(struct fq *fq,
 
__skb_queue_tail(>queue, skb);
 
-   if (fq->backlog > fq->limit) {
+   if (fq->backlog > fq->limit || fq->memory_usage > fq->memory_limit) {
flow = list_first_entry_or_null(>backlogs,
struct fq_flow,
backlogchain);
@@ -181,6 +183,8 @@ static void fq_tin_enqueue(struct fq *fq,
 
flow->tin->overlimit++;
fq->overlimit++;
+   if (fq->memory_usage > fq->memory_limit)
+   fq->overmemory++;
}
 }
 
@@ -251,6 +255,7 @@ static int fq_init(struct fq *fq, int flows_cnt)
fq->perturbation = prandom_u32();
fq->quantum = 300;
fq->limit = 8192;
+   fq->memory_limit = 16 << 20; /* 16 MBytes */
 
fq->flows = kcalloc(fq->flows_cnt, sizeof(fq->flows[0]), GFP_KERNEL);
if (!fq->flows)
-- 
2.9.3

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

[Larry Finger]

On 09/23/2016 01:27 PM, Joe Perches wrote:

Help along debugging by showing what switch/case variable is not
being processed in these messages.

Signed-off-by: Joe Perches 


Acked-by: Larry Finger 

Thanks,

Larry

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

[Joe Perches]

On Fri, 2016-09-23 at 13:59 -0500, Larry Finger wrote:
> I'm not familiar with the %#x format. What does it do?

Outputs SPECIAL prefix, it's the same as "0x%x"

lib/vsprintf.c:
#define SPECIAL 64  /* prefix hex with "0x", octal with "0" */

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

[Larry Finger]

On 09/23/2016 01:27 PM, Joe Perches wrote:

Help along debugging by showing what switch/case variable is not
being processed in these messages.

Signed-off-by: Joe Perches 


Joe,

You beat me to the patch. No problem as this one looks OK; however, I'm not 
familiar with the %#x format. What does it do?


Larry


---
 drivers/net/wireless/realtek/rtlwifi/core.c  |  3 ++-
 drivers/net/wireless/realtek/rtlwifi/pci.c   |  3 ++-
 drivers/net/wireless/realtek/rtlwifi/ps.c|  2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c  |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c | 10 ++
 .../wireless/realtek/rtlwifi/rtl8192c/fw_common.c|  4 ++--
 .../wireless/realtek/rtlwifi/rtl8192c/phy_common.c   |  8 +---
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c  |  7 ---
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/phy.c |  7 ++-
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/phy.c |  7 ++-
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c  |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 15 +++
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c  |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 10 ++
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c  |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/phy.c |  5 +++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/fw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c  |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c | 10 ++
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/fw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c  | 10 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 12 +++-
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c  |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 20 ++--
 38 files changed, 128 insertions(+), 123 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c 
b/drivers/net/wireless/realtek/rtlwifi/core.c
index 7aee5ebb1..f95760c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -765,7 +765,8 @@ static int rtl_op_config(struct ieee80211_hw *hw, u32 
changed)
mac->bw_40 = false;
mac->bw_80 = false;
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case not processed\n");
+"switch case %#x not 
processed\n",
+channel_type);
break;
}
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index d12586d..0dfa9ea 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -179,7 +179,8 @@ static void _rtl_pci_update_default_setting(struct 
ieee80211_hw *hw)
break;
default:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case not processed\n");
+"switch case %#x not processed\n",
+rtlpci->const_support_pciaspm);
break;
}

diff --git a/drivers/net/wireless/realtek/rtlwifi/ps.c 
b/drivers/net/wireless/realtek/rtlwifi/ps.c
index 9a64f9b..18d979a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/ps.c
+++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
@@ -151,7 +151,7 @@ static bool rtl_ps_set_rf_state(struct ieee80211_hw *hw,

default:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case not processed\n");
+"switch case %#x not processed\n", state_toset);
break;
}

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c 

Re: Broadcom Firmware Rollback

[David Petrizze]

I see. I guess I was hoping for some sort of mishap i.e. replacing
6.20 with 6.30 without thinking. If it wasn't released, I'll keep
working on compiling the Ubuntu driver I did find.

Thanks again

On Thu, Sep 22, 2016 at 10:48 PM, Rafał Miłecki  wrote:
> On 23 September 2016 at 04:43, David Petrizze  wrote:
>> I'm having issues with broadcom's latest firmware / driver, version
>> 6.30.163.46. Wireless is solid for about a minute, and then drops
>> completely. My research has led me to believe my chip (BCM4331) is no
>> longer supported under 6.30.X.X, or has a bug somewhere. I want to
>> roll back to the firmware that worked.
>>
>> What I'm looking for is a file named broadcom-wl-6.20.*.*.tar.bz2. I
>> found my current firmware from http://www.lwfinger.com/b43-firmware/,
>> but 6.20.X.X is nowhere to be found. 5.100.X.X is there, but the 4331
>> definitely wasn't supported for that one.
>>
>> Inside each of these archives on lwfinger is a file called wl_apsta.o,
>> where the firmware is extracted from.  Since b43-fwcutter only
>> extracts firmware from versions of wl_apsta.o that match specific
>> MD5's, I figure 6.20.X.X has to be out there somewhere.
>>
>> More info can be found from my original post:
>> https://bbs.archlinux.org/viewtopic.php?id=217326
>>
>> ...and other people confrim 6.30.X.X being a problem in this ubuntu bug:
>> https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1189611
>>
>> If anyone could point me in the right direction, I would be immensely 
>> grateful.
>
> You can't make proprietary driver using firmware of your choice, so
> don't bother looking at MIPS drivers stored at Larry's server.
>
> You just need to find a /complete/ (mostly closed source of course)
> driver 6.20 for x86/x86_64. I don't think it was ever published on
> Broadcom's site, I think it was made available to Ubuntu only under
> some agreement. So keep looking at Ubuntu resources.
>
> Also linux-wireless ML focuses on open source drivers, so you may have
> more luck asking at Ubuntu community.
>
> --
> Rafał

[PATCH] realtek: Add switch variable to 'switch case not processed' messages

[Joe Perches]

Help along debugging by showing what switch/case variable is not
being processed in these messages.

Signed-off-by: Joe Perches 
---
 drivers/net/wireless/realtek/rtlwifi/core.c  |  3 ++-
 drivers/net/wireless/realtek/rtlwifi/pci.c   |  3 ++-
 drivers/net/wireless/realtek/rtlwifi/ps.c|  2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c  |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c | 10 ++
 .../wireless/realtek/rtlwifi/rtl8192c/fw_common.c|  4 ++--
 .../wireless/realtek/rtlwifi/rtl8192c/phy_common.c   |  8 +---
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c  |  7 ---
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/phy.c |  7 ++-
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/phy.c |  7 ++-
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c  |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 15 +++
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c  |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 10 ++
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c  |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/phy.c |  5 +++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/fw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c  |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c | 10 ++
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/fw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c  | 10 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 12 +++-
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c  |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c  |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/led.c |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 20 ++--
 38 files changed, 128 insertions(+), 123 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c 
b/drivers/net/wireless/realtek/rtlwifi/core.c
index 7aee5ebb1..f95760c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -765,7 +765,8 @@ static int rtl_op_config(struct ieee80211_hw *hw, u32 
changed)
mac->bw_40 = false;
mac->bw_80 = false;
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case not processed\n");
+"switch case %#x not 
processed\n",
+channel_type);
break;
}
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index d12586d..0dfa9ea 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -179,7 +179,8 @@ static void _rtl_pci_update_default_setting(struct 
ieee80211_hw *hw)
break;
default:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case not processed\n");
+"switch case %#x not processed\n",
+rtlpci->const_support_pciaspm);
break;
}
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/ps.c 
b/drivers/net/wireless/realtek/rtlwifi/ps.c
index 9a64f9b..18d979a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/ps.c
+++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
@@ -151,7 +151,7 @@ static bool rtl_ps_set_rf_state(struct ieee80211_hw *hw,
 
default:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case not processed\n");
+"switch case %#x not processed\n", state_toset);
break;
}
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
index 6291256..5360d53 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
+++ 

Re: rtl8192ce:rtl92ce_get_hw_reg():<0-0> switch case not processed

[Joe Perches]

On Thu, 2016-09-22 at 10:09 -0500, Larry Finger wrote:
> On 09/22/2016 04:51 AM, Jean Delvare wrote:
> Hello,
> 
> 
> I bought an Asus PCE-N10 PCIe Wi-Fi N card to install in my wife's
> computer. This morning it stopped working suddenly. Investigating the
> kernel logs, the following error message caught my eye:
> 
> 
> rtl8192ce:rtl92ce_get_hw_reg():<0-0> switch case not processed
> 
> 
> It was printed twice, 3.5 hours apart, the second time at the moment
> the network stopped working. I guess this is not supposed to happen.
> What additional information can I provide to help you debug the issue?
> That's the device:
> 
> 
> 03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE 
> 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:84b5]
>   Flags: bus master, fast devsel, latency 0, IRQ 17
>   I/O ports at e800 [size=256]
>   Memory at febfc000 (64-bit, non-prefetchable) [size=16K]
>   Capabilities: 
>   Kernel driver in use: rtl8192ce
>   Kernel modules: rtl8192ce
> 
> 
> Kernel version is 4.5.4-1-default x86_64 (openSUSE Tumbleweed.)
> 
> 
> Reloading the rtl8192ce module and restarting the network service got
> everything back up.
> 
> 
> 
> 
> Unfortunately, that message is not as helpful as it might be.
> 
> 
> Do you build your own kernel, or are you using openSUSE's supplied version? 
> If 
> the latter, I will need to think how we might debug the issue. If the former, 
> please add the attached patch.

It might be better to add the switch value to all the
RT_TRACE(,,,"switch case not processed\n"); uses in
drivers/net/wireless/realtek/rtlwifi/

I'll send a patch.

Re: rtl8192ce:rtl92ce_get_hw_reg():<0-0> switch case not processed

[Larry Finger]

On 09/23/2016 07:16 AM, Jean Delvare wrote:

Hi Larry,

On Thu, 22 Sep 2016 10:09:58 -0500, Larry Finger wrote:

Do you build your own kernel, or are you using openSUSE's supplied version? If
the latter, I will need to think how we might debug the issue. If the former,
please add the attached patch.


Lost network this morning, but no error message. We restarted the
network service, things were back up and the error message was logged
then:

rtl8192ce:rtl92ce_get_hw_reg():<0-0> switch case 92 not processed

So I think this is happening when the interface is put down, and is
probably not related with the loss of connectivity. But it would be
good to understand and fix it nevertheless.

92 is HAL_DEF_WOWLAN. I see it is handled differently in 2 other
rtlwifi drivers: rtl8192cu ignores it, while rtl8821ae processes it:

case HAL_DEF_WOWLAN:
if (ppsc->wo_wlan_mode)
*((bool *)(val)) = true;
else
*((bool *)(val)) = false;
break;

I don't know what is the appropriate course of action in the case of
the rtl8192ce. Let me know if you need anything else from me.


As the RTL8192CE does not support WOWLAN, the correct response is to ignore that 
call. Clearly, it has nothing to do with your network drops. One thing you might 
do is add the appropriate file in /etc/modprobe.d/ so that the module is loaded 
with the "ips=0" option to see if power save is messing up.


I am in the process of fixing all the instances where the log entry for the 
default case does not output the switch variable. With these patches, I will 
also handle the HAL_DEF_WOWLAN case.


I'm sorry about my original comments regarding patching the kernel. I sent that 
E-mail before I even read your name and address. As a long-time openSUSE user, I 
certainly recognize your name and your abilities.


Larry

Re: staging: wilc1000: kernel Oops while opening the device

[Greg KH]

On Fri, Sep 23, 2016 at 01:17:08PM +, aditya.shan...@microchip.com wrote:
> On Thursday 22 September 2016 06:04 PM, Ganesh Krishna - I00112 wrote:
> >> -Original Message-
> >> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] 
> >> Sent: Monday, September 19, 2016 7:12 PM
> >> To: Nicolas Ferre
> >> Cc: linux-wireless@vger.kernel.org; Aditya Shankar - I16078; Ganesh 
> >> Krishna - I00112; lui...@osg.samsung.com
> >> Subject: Re: staging: wilc1000: kernel Oops while opening the device
> >>
> >> On Mon, Sep 19, 2016 at 02:06:02PM +0200, Nicolas Ferre wrote:
> >>> Hi all,
> >>>
> >>> While using the wilc1000 driver with latest 4.8-rc7, I have 
> >>> difficulties to open the device and actually use it as I have this 
> >>> kernel Oops right after the loading of the firmware 
> >>> (wilc1003_firmware.bin).
> >>>
> >>> If I revert back the driver to its 
> >>> b9811891a9f60ca9c314dcab3244c65930c4cf37 state, it works okay. I did 
> >>> this because I tend to think that it might be related to the latest move 
> >>> on this driver to "completion" or "work queues".
> >>> It seems to be a regression from 4.7.
> >>
> >> Ick, not good at all.
> >>
> >> Any chance you can run 'git bisect' to see if you can find the offending 
> >> patch?
> >>
> >> I thought the maintainers were testing this driver over time :(
> > 
> >> thanks,
> >>
> >> greg k-h
> > 
> > Ick indeed. Maintainers are on it full time. Thank you very much for the 
> > flag. While I am only reporting activity, hope to have results soon.
> > Regards,
> > ganesh k 
> > 
> Hi All,
> 
> bisecting changes on the wilc1000 host driver, I find that this problem seems 
> to occur after the below change. 
> As of now, I only know the where and not the why. So I will continue to 
> figure out why this happens.
> 
> commit 2518ac59eb27ed003c5a97e8f9588adafdfe4a8a
> Author: Binoy Jayan 
> Date:   Thu Jun 23 11:11:51 2016 +0530
> 
> staging: wilc1000: Replace kthread with workqueue for host interface
> 
> Deconstruct the kthread / message_queue logic, replacing it with
> create_singlethread_workqueue() / queue_work() setup, by adding a
> 'struct work_struct' to 'struct host_if_msg'. The current kthread
> hostIFthread() is converted to a work queue helper with the name
> 'host_if_work'.

So if you revert this, it works?

If so, let us know and I will gladly revert it, as breaking things is
not ok.

thanks,

greg k-h

[PATCH] brcmfmac: drop unused fields from struct brcmf_pub

[Rafał Miłecki]

From: Rafał Miłecki 

They seem to be there from the first day. We calculate these values but
never use them.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 3 ---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h | 4 
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 2 --
 3 files changed, 9 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 65e8c87..27cd50a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -519,9 +519,6 @@ int brcmf_net_attach(struct brcmf_if *ifp, bool rtnl_locked)
ndev->needed_headroom += drvr->hdrlen;
ndev->ethtool_ops = _ethtool_ops;
 
-   drvr->rxsz = ndev->mtu + ndev->hard_header_len +
- drvr->hdrlen;
-
/* set the mac address */
memcpy(ndev->dev_addr, ifp->mac_addr, ETH_ALEN);
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
index 8fa34ca..f16cfc9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
@@ -112,15 +112,11 @@ struct brcmf_pub {
 
/* Internal brcmf items */
uint hdrlen;/* Total BRCMF header length (proto + bus) */
-   uint rxsz;  /* Rx buffer size bus module should use */
 
/* Dongle media info */
char fwver[BRCMF_DRIVER_FIRMWARE_VERSION_LEN];
u8 mac[ETH_ALEN];   /* MAC address obtained from dongle */
 
-   /* Multicast data packets sent to dongle */
-   unsigned long tx_multicast;
-
struct mac_address addresses[BRCMF_MAX_IFS];
 
struct brcmf_if *iflist[BRCMF_MAX_IFS];
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
index 9f9024a..a190f53 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
@@ -2104,8 +2104,6 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct 
sk_buff *skb)
if ((skb->priority == 0) || (skb->priority > 7))
skb->priority = cfg80211_classify8021d(skb, NULL);
 
-   drvr->tx_multicast += !!multicast;
-
if (fws->avoid_queueing) {
rc = brcmf_proto_txdata(drvr, ifp->ifidx, 0, skb);
if (rc < 0)
-- 
2.9.3

Re: staging: wilc1000: kernel Oops while opening the device

[Aditya.Shankar]

On Thursday 22 September 2016 06:04 PM, Ganesh Krishna - I00112 wrote:
>> -Original Message-
>> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] 
>> Sent: Monday, September 19, 2016 7:12 PM
>> To: Nicolas Ferre
>> Cc: linux-wireless@vger.kernel.org; Aditya Shankar - I16078; Ganesh Krishna 
>> - I00112; lui...@osg.samsung.com
>> Subject: Re: staging: wilc1000: kernel Oops while opening the device
>>
>> On Mon, Sep 19, 2016 at 02:06:02PM +0200, Nicolas Ferre wrote:
>>> Hi all,
>>>
>>> While using the wilc1000 driver with latest 4.8-rc7, I have 
>>> difficulties to open the device and actually use it as I have this 
>>> kernel Oops right after the loading of the firmware (wilc1003_firmware.bin).
>>>
>>> If I revert back the driver to its 
>>> b9811891a9f60ca9c314dcab3244c65930c4cf37 state, it works okay. I did 
>>> this because I tend to think that it might be related to the latest move on 
>>> this driver to "completion" or "work queues".
>>> It seems to be a regression from 4.7.
>>
>> Ick, not good at all.
>>
>> Any chance you can run 'git bisect' to see if you can find the offending 
>> patch?
>>
>> I thought the maintainers were testing this driver over time :(
> 
>> thanks,
>>
>> greg k-h
> 
> Ick indeed. Maintainers are on it full time. Thank you very much for the 
> flag. While I am only reporting activity, hope to have results soon.
> Regards,
> ganesh k 
> 
Hi All,

bisecting changes on the wilc1000 host driver, I find that this problem seems 
to occur after the below change. 
As of now, I only know the where and not the why. So I will continue to figure 
out why this happens.

commit 2518ac59eb27ed003c5a97e8f9588adafdfe4a8a
Author: Binoy Jayan 
Date:   Thu Jun 23 11:11:51 2016 +0530

staging: wilc1000: Replace kthread with workqueue for host interface

Deconstruct the kthread / message_queue logic, replacing it with
create_singlethread_workqueue() / queue_work() setup, by adding a
'struct work_struct' to 'struct host_if_msg'. The current kthread
hostIFthread() is converted to a work queue helper with the name
'host_if_work'.

Thanks!
Aditya

Re: ath10k mesh mode issue

[Michal Kazior]

On 21 September 2016 at 18:27, Matteo Grandi  wrote:
> Hi Michal,
> thanks for the reply:
> I've already loaded the ath10k_core with the rowmode parameters, this
> is the modinfo result:
> root@Tam:~# modinfo ath10k_core
> filename:
> /lib/modules/3.14.48-g408ccb9/kernel/drivers/net/wireless/ath/ath10k/ath10k_core.ko
> license:Dual BSD/GPL
> description:Core module for QCA988X PCIe devices.
> author: Qualcomm Atheros
> srcversion: 407804E6D5A63597F137E9B
> depends:mac80211,cfg80211,compat,ath
> vermagic:   3.14.48-g408ccb9 SMP mod_unload modversions ARMv7 p2v8
> parm:   debug_mask:Debugging mask (uint)
> parm:   uart_print:Uart target debugging (bool)
> parm:   skip_otp:Skip otp failure for calibration in testmode (bool)
> parm:   cryptmode:Crypto mode: 0-hardware, 1-software (uint)
> parm:   rawmode:Use raw 802.11 frame datapath (bool)
[...]
> I've loaded adding the line ath10k_core rawmode=1 to the file etc/modules

Hmm... are you sure the module is actually loaded with the parameter?

You can check it with:

 grep . /sys/module/ath10k*/parameters/*


Michał

Re: rtl8192ce:rtl92ce_get_hw_reg():<0-0> switch case not processed

[Jean Delvare]

Hi Larry,

On Thu, 22 Sep 2016 10:09:58 -0500, Larry Finger wrote:
> Do you build your own kernel, or are you using openSUSE's supplied version? 
> If 
> the latter, I will need to think how we might debug the issue. If the former, 
> please add the attached patch.

Lost network this morning, but no error message. We restarted the
network service, things were back up and the error message was logged
then:

rtl8192ce:rtl92ce_get_hw_reg():<0-0> switch case 92 not processed

So I think this is happening when the interface is put down, and is
probably not related with the loss of connectivity. But it would be
good to understand and fix it nevertheless.

92 is HAL_DEF_WOWLAN. I see it is handled differently in 2 other
rtlwifi drivers: rtl8192cu ignores it, while rtl8821ae processes it:

case HAL_DEF_WOWLAN:
if (ppsc->wo_wlan_mode)
*((bool *)(val)) = true;
else
*((bool *)(val)) = false;
break;

I don't know what is the appropriate course of action in the case of
the rtl8192ce. Let me know if you need anything else from me.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH] brcmfmac: fix memory leak in brcmf_fill_bss_param

[Arend Van Spriel]

On 21-9-2016 8:23, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This function is called from get_station callback which means that every
> time user space was getting/dumping station(s) we were leaking 2 KiB.
> 

Acked-by: Arend van Spriel 
> Signed-off-by: Rafał Miłecki 
> Fixes: 1f0dc59a6de ("brcmfmac: rework .get_station() callback")
> Cc: sta...@vger.kernel.org # 4.2+
> ---
> Kalle, ideally this should go as 4.8 fix, but I'm aware it's quite late.
> If you are not planning to send another pull request, just get it for
> the next release and let's let stable guys backport it.
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index b8aec5e5..62a7675 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -2533,7 +2533,7 @@ static void brcmf_fill_bss_param(struct brcmf_if *ifp, 
> struct station_info *si)
>WL_BSS_INFO_MAX);
>   if (err) {
>   brcmf_err("Failed to get bss info (%d)\n", err);
> - return;
> + goto out_kfree;
>   }
>   si->filled |= BIT(NL80211_STA_INFO_BSS_PARAM);
>   si->bss_param.beacon_interval = le16_to_cpu(buf->bss_le.beacon_period);
> @@ -2545,6 +2545,9 @@ static void brcmf_fill_bss_param(struct brcmf_if *ifp, 
> struct station_info *si)
>   si->bss_param.flags |= BSS_PARAM_FLAGS_SHORT_PREAMBLE;
>   if (capability & WLAN_CAPABILITY_SHORT_SLOT_TIME)
>   si->bss_param.flags |= BSS_PARAM_FLAGS_SHORT_SLOT_TIME;
> +
> +out_kfree:
> + kfree(buf);
>  }
>  
>  static s32
> 

Re: brcmf_txfinalize misses 802.1x packet leading to infinite WARNINGs

[Rafał Miłecki]

On 22 September 2016 at 16:09, Rafał Miłecki  wrote:
> On 22 September 2016 at 14:24, Rafał Miłecki  wrote:
>> I got the same problem again, but this time there was only 1 skb in my
>> flowring.
>> That resulted in less serial console messages and no reboot.
>>
>> It doesn't look good. brcmf_txfinalize was called 11 times after deleting
>> flowring. Everytime it was working with the same skb that was already freed.
>
> I'm wondering if there is some bug in flowring code. Please take a
> look if my following understanding it correct.
>
> 1) Every skb that is supposed to reach the device gets queued on a flowring.
> 2) Dequeuing means skb is not available in a flowring anymore
> 3a) brcmf_msgbuf_txflow dequeues skbs to pass them to the firmware
> 3b) brcmf_flowring_delete dequeues skbs to delete (free) them
>
> If that simple description is correct, it shouldn't be possible to skb to:
> 1) Reach the firmware
> *and*
> 2) Get freed as part of flowring deletion
>
> But this is what seems to be happening in my case. We get one skb
> freed on flowring deletion and then reported as transmitted (sometimes
> multiple times) by the firmware.
>
> Maybe there is simply a race between brcmf_flowring_delete and
> brcmf_msgbuf_txflow?

I can see a problem with my debugging code. It may happen brcmfmac
gets skb allocated at the same address. Due to brcmf_flowring_delete
bypassing brcmf_txfinalize we don't drop tracing of the old one and
that results in the same packet listed twice in my debugging code.

I got caught into the same trap that breaks pend_8021x_cnt counting.

I believe pend_8021x_cnt related code should be moved to the place
that really queues skb for the firmware to access.

-- 
Rafał