date:20180227

Re: fixed bit rate 9Mbps set as 24Mbps in g mode(legacy)

2018-02-27 Thread KAVITA MATHUR




On Tue, 27 Feb 2018 08:41:50 -0800, Ben Greear wrote
> On 02/27/2018 12:49 AM, KAVITA MATHUR wrote:
> > Hi,
> >
> > I have configured AP in g mode and tested legacy rates.All basic rates and 
> > supported
> > rates(1,2,5.5,11,6,9,12,18,24,36,48,54) are set except 9Mbps.
> >
> > When fixed bit rate 9Mbps is set, it gets set as 24 Mbps. This issue has 
> > been observed
> > in backports-4.4.2-1 as well as latest git version of ath10k driver.
> >
> >
> > Is anybody aware of this issue? How can I fix this rate 9Mbps?
> 
> You should specify which firmware/chipset you are using, since this might
> easily be a firmware issue.


Chipset : QCA988x
ath10k version : git 16 oct 2017(v4.14-rc2-1-24-gc6db471)
firmware version : firmware-5.bin_10.2.4.70.66
Kernel version : 3.12 

> And, how are you determining that 'it gets set to 24Mbps'.  Is that the 
> encoding you see in a wifi sniff, or is the driver being set to 24Mbps 
> improperly when you use iw (or whatever) to try configuring the rate?

I have used command "iw wlan0 station dump" to see set data rate as well as I 
have
sniffer. Measured data throughput is also as per 24Mbps.



> Recent upstream mac80211 has broken the ability to set a single tx rate as 
> well, last I checked.

Other rates are set properly except 9Mbps.By default it sets as 6Mbps, when data
transfer starts, then it set to the mentioned fixed data rate.

Thanks & Regards,
Kavita
> Thanks,
> Ben
> 
> >
> >
> > Thanks & Regards,
> > Kavita
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe backports" in
> >
> 
> -- 
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com


Thanks & Regards,
कविता माथुर Kavita Mathur 
वरिष्ठ अनुसंधान अभियंता  Senior Research Engineer 
सी-डॉट  C-DOT
इलैक्ट्रॉनिक्स सिटी फेज़ I Electronics City Phase I
होसूर रोड, बेंगलूरु   Hosur Road, Bengaluru – 560100
फोन  Ph 080-28529896
Disclaimer:
--
This email and any files transmitted with it


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

2018-02-27 Thread Sebastian Gottschall


Am 27.02.2018 um 23:08 schrieb Rafał Miłecki:

On 26 February 2018 at 09:44,   wrote:

From: Sebastian Gottschall 

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and can be 
controlled with various triggers.
adds also debugfs interface for gpio control.

Hi Sebastian,

I just noticed this patch and have one question. It seems you register
GPIO chip and that WiFi LED is controller by a GPIO. Shouldn't you use
leds-gpio driver and just register platform device with
gpio_led_platform_data? That way you could avoid some code duplication
I think? It seems to be the purpose of leds-gpio driver.
leds-gpio is crap and limited. you can just register one platform data 
at kernel runtime since its identified by its object name "led-gpio" but 
the kernel forbidds to register 2 platform datas with the same name
consider the ar71xx devices with qca988x wifi chipsets. they all have 
already a led platform data registered
at boottime. a second can't be registered anymore so gpio_led is useless 
at all for most developers on such platforms. its mainly used for early 
kernel platform data initialisation for system leds.
at the beginning of development of this patch i started in that way and 
found out this limitation, so i had to rewrite everything.
the good point now is, it works even without gpiolib support since the 
gpio device is just a option, but not required for led control.


--
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


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[RFC] ath10k: Attempt to work around napi_synchronize hang.

2018-02-27 Thread greearb

From: Ben Greear 

Calling napi_disable twice in a row (w/out starting it and/or without
having NAPI active leads to deadlock because napi_disable sets
NAPI_STATE_SCHED and NAPI_STATE_NPSVC when it returns, as far as I
can tell.  So, guard this call to napi_disable.  I believe the
failure case is something like this:
 rmmod ath10k_pci ath10k_core
   Firmware crashes before hif_stop is called by the rmmod path
   The crash handling logic calls hif_stop
   Then rmmod gets around to calling hif_stop, but spins endlessly
   in napi_synchronize.

I think one way this could happen is that ath10k_stop checks
for state != ATH10K_STATE_OFF, but STATE_RESTARTING is also
a possibility.  That might be how we can have hif_stop called twice
without a hif_start in between. --Ben

Signed-off-by: Ben Greear 
---
 drivers/net/wireless/ath/ath10k/core.h |  1 +
 drivers/net/wireless/ath/ath10k/pci.c  | 25 +++--
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 72b4495..c7ba49f 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -1205,6 +1205,7 @@ struct ath10k {
/* NAPI */
struct net_device napi_dev;
struct napi_struct napi;
+   bool napi_enabled;
 
struct work_struct stop_scan_work;
 
diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index 398e413..9131e15 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1956,6 +1956,7 @@ static int ath10k_pci_hif_start(struct ath10k *ar)
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");
 
napi_enable(>napi);
+   ar->napi_enabled = true;
 
ath10k_pci_irq_enable(ar);
ath10k_pci_rx_post(ar);
@@ -2086,8 +2087,28 @@ static void ath10k_pci_hif_stop(struct ath10k *ar)
ath10k_pci_irq_disable(ar);
ath10k_pci_irq_sync(ar);
ath10k_pci_flush(ar);
-   napi_synchronize(>napi);
-   napi_disable(>napi);
+
+   /* Calling napi_disable twice in a row (w/out starting it and/or without
+* having NAPI active leads to deadlock because napi_disable sets
+* NAPI_STATE_SCHED and NAPI_STATE_NPSVC when it returns, as far as I
+* can tell.  So, guard this call to napi_disable.  I believe the
+* failure case is something like this:
+* rmmod ath10k_pci ath10k_core
+*   Firmware crashes before hif_stop is called by the rmmod path
+*   The crash handling logic calls hif_stop
+ *   Then rmmod gets around to calling hif_stop, but spins endlessly
+*   in napi_synchronize.
+*
+*  I think one way this could happen is that ath10k_stop checks
+*  for state != ATH10K_STATE_OFF, but STATE_RESTARTING is also
+*  a possibility.  That might be how we can have hif_stop called twice
+*  without a hif_start in between. --Ben
+*/
+   if (ar->napi_enabled) {
+   napi_synchronize(>napi);
+   napi_disable(>napi);
+   ar->napi_enabled = false;
+   }
 
spin_lock_irqsave(_pci->ps_lock, flags);
WARN_ON(ar_pci->ps_wake_refcount > 0);
-- 
2.4.11


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

RFC: Possible napi deadlock work-around?

2018-02-27 Thread Ben Greear


Does this look like a good idea?


[greearb@ben-dt3 ath10k]$ git diff
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 72b4495..c7ba49f 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -1205,6 +1205,7 @@ struct ath10k {
/* NAPI */
struct net_device napi_dev;
struct napi_struct napi;
+   bool napi_enabled;

struct work_struct stop_scan_work;

diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index 398e413..fad4fb9 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1956,6 +1956,7 @@ static int ath10k_pci_hif_start(struct ath10k *ar)
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");

napi_enable(>napi);
+   ar->napi_enabled = true;

ath10k_pci_irq_enable(ar);
ath10k_pci_rx_post(ar);
@@ -2086,8 +2087,23 @@ static void ath10k_pci_hif_stop(struct ath10k *ar)
ath10k_pci_irq_disable(ar);
ath10k_pci_irq_sync(ar);
ath10k_pci_flush(ar);
-   napi_synchronize(>napi);
-   napi_disable(>napi);
+
+   /* Calling napi_disable twice in a row (w/out starting it and/or without
+* having NAPI active leads to deadlock because napi_disable sets
+* NAPI_STATE_SCHED and NAPI_STATE_NPSVC when it returns, as far as I
+* can tell.  So, guard this call to napi_disable.  I believe the
+* failure case is something like this:
+* rmmod ath10k_pci ath10k_core
+*   Firmware crashes before hif_stop is called by the rmmod path
+*   The crash handling logic calls hif_stop
+ *   Then rmmod gets around to calling hif_stop, but spins endlessly
+*   in napi_synchronize.
+*/
+   if (ar->napi_enabled) {
+   napi_synchronize(>napi);
+   napi_disable(>napi);
+   ar->napi_enabled = false;
+   }

spin_lock_irqsave(_pci->ps_lock, flags);
WARN_ON(ar_pci->ps_wake_refcount > 0);
[greearb@ben-dt3 ath10k]$

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Deadlock debugging help.

2018-02-27 Thread Ben Greear


On 02/27/2018 01:42 PM, Ben Greear wrote:

On 02/27/2018 12:49 PM, Ben Greear wrote:

I notice I can reliably lock up the kernel if I rmmod ath10k while it is under
heavy tx/rx traffic.  First, this causes the firmware to crash, and then right
after (or possibly during?) the related kernel threads deadlock.

This is with my hacked driver and hacked firmware.  In particular, the
ath10k_debug_nop_dwork is something I added, though it is pretty trivial,
it does take the ar->conf_mutex.  It appears blocked trying to get it.

It appears something is holding the ar->conf_mutex, but it is not clear to
me from the lockdep output what process actually holds it.
Anyone see a clue they could share?


Changing how I start/stop the nop_dwork stuff seems to have made the
problem go away, so I guess maybe that was the issue.


Ok, so problem still remains.  The 'rmmod' process appears to be the
one that is really not making progress.  Unfortunately, decoding
ath10k_pci_hif_stop+0x6f leads to some bitops.h inline, which doesn't
let me know where it is actually stuck...  Off to do more debugging


[ 4037.220992] rmmod   D0 20267   3050 0x0080
[ 4037.220995] Call Trace:
[ 4037.220997]  __schedule+0x407/0xb70
[ 4037.220999]  ? _raw_spin_unlock_irqrestore+0x4e/0x70
[ 4037.221003]  schedule+0x38/0x90
[ 4037.221005]  schedule_timeout+0x224/0x580
[ 4037.221007]  ? retint_kernel+0x2d/0x2d
[ 4037.221010]  ? call_timer_fn+0x370/0x370
[ 4037.221015]  msleep+0x34/0x40
[ 4037.221017]  ? msleep+0x34/0x40
[ 4037.221021]  ath10k_pci_hif_stop+0x6f/0xd0 [ath10k_pci]
[ 4037.221032]  ath10k_core_stop+0x4d/0x90 [ath10k_core]
[ 4037.221038]  ath10k_halt+0x14b/0x1f0 [ath10k_core]
[ 4037.221044]  ath10k_stop+0x36/0x80 [ath10k_core]
[ 4037.221059]  drv_stop+0x58/0x2d0 [mac80211]
[ 4037.221075]  ieee80211_stop_device+0x3e/0x50 [mac80211]
[ 4037.221088]  ieee80211_do_stop+0x501/0x880 [mac80211]
[ 4037.221092]  ? dev_deactivate_many+0x2b2/0x2f0
[ 4037.221105]  ieee80211_stop+0x15/0x20 [mac80211]
[ 4037.221107]  __dev_close_many+0x93/0xe0
[ 4037.221110]  dev_close_many+0x7d/0x120
[ 4037.221114]  dev_close.part.85+0x36/0x50
[ 4037.221116]  dev_close+0x15/0x20
[ 4037.221155]  cfg80211_shutdown_all_interfaces+0x44/0xc0 [cfg80211]
[ 4037.221168]  ieee80211_remove_interfaces+0x42/0x1c0 [mac80211]
[ 4037.221180]  ieee80211_unregister_hw+0x45/0x130 [mac80211]
[ 4037.221187]  ath10k_mac_unregister+0x14/0x60 [ath10k_core]
[ 4037.221193]  ath10k_core_unregister+0x3a/0xa0 [ath10k_core]
[ 4037.221197]  ath10k_pci_remove+0x2d/0x70 [ath10k_pci]
[ 4037.221200]  pci_device_remove+0x34/0xb0
[ 4037.221203]  device_release_driver_internal+0x158/0x210
[ 4037.221206]  driver_detach+0x3b/0x80
[ 4037.221208]  bus_remove_driver+0x53/0xd0
[ 4037.221210]  driver_unregister+0x27/0x40
[ 4037.221213]  pci_unregister_driver+0x24/0x90
[ 4037.221216]  ath10k_pci_exit+0x10/0x6ee [ath10k_pci]
[ 4037.221218]  SyS_delete_module+0x1e1/0x2a0
[ 4037.221222]  do_syscall_64+0x64/0x140
[ 4037.221225]  entry_SYSCALL64_slow_path+0x25/0x25

Thanks,
Ben


--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

2018-02-27 Thread Rafał Miłecki

On 26 February 2018 at 09:44,   wrote:
> From: Sebastian Gottschall 
>
> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
> chipsets with on chipset connected led's
> using WMI Firmware API.
> The LED device will get available named as "ath10k-phyX" at sysfs and can be 
> controlled with various triggers.
> adds also debugfs interface for gpio control.

Hi Sebastian,

I just noticed this patch and have one question. It seems you register
GPIO chip and that WiFi LED is controller by a GPIO. Shouldn't you use
leds-gpio driver and just register platform device with
gpio_led_platform_data? That way you could avoid some code duplication
I think? It seems to be the purpose of leds-gpio driver.


> Signed-off-by: Sebastian Gottschall 
>
> v2  add correct gpio count per chipset and remove IPQ4019 support since this 
> chipset does not make use of specific gpios)
> v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error by 
> kbuild test robot which does not occur in standard builds. curious
> v6  correct return values and fix comment style
> v7  fix ath10k_unregister_led for compiling without LED_CLASS
> v8  fix various code design issues reported by reviewers
> v9  move led and led code to separate sourcefile (gpio.c)
> v10 compile fix if gpiolib isnt included
> v11 make register_gpio_chip static. advise by krobot
> v12 fix warning
> ---
>  drivers/net/wireless/ath/ath10k/Kconfig   |  10 ++
>  drivers/net/wireless/ath/ath10k/Makefile  |   1 +
>  drivers/net/wireless/ath/ath10k/core.c|  28 -
>  drivers/net/wireless/ath/ath10k/core.h|  62 +-
>  drivers/net/wireless/ath/ath10k/debug.c   | 146 ++
>  drivers/net/wireless/ath/ath10k/gpio.c| 196 
> ++
>  drivers/net/wireless/ath/ath10k/hw.h  |   2 +
>  drivers/net/wireless/ath/ath10k/mac.c |   5 +
>  drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 +-
>  drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 ++
>  drivers/net/wireless/ath/ath10k/wmi.c |  46 +++
>  drivers/net/wireless/ath/ath10k/wmi.h |  36 ++
>  12 files changed, 630 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/net/wireless/ath/ath10k/gpio.c
>
> diff --git a/drivers/net/wireless/ath/ath10k/Kconfig 
> b/drivers/net/wireless/ath/ath10k/Kconfig
> index deb5ae21a559..5d61d499dca4 100644
> --- a/drivers/net/wireless/ath/ath10k/Kconfig
> +++ b/drivers/net/wireless/ath/ath10k/Kconfig
> @@ -10,6 +10,16 @@ config ATH10K
>
>If you choose to build a module, it'll be called ath10k.
>
> +config ATH10K_LEDS
> +   bool "SoftLED Support"
> +   depends on ATH10K
> +   select MAC80211_LEDS
> +   select LEDS_CLASS
> +   select NEW_LEDS
> +   default y
> +   help
> + This option is necessary, if you want LED support for chipset 
> connected led pins
> +
>  config ATH10K_PCI
> tristate "Atheros ath10k PCI support"
> depends on ATH10K && PCI
> diff --git a/drivers/net/wireless/ath/ath10k/Makefile 
> b/drivers/net/wireless/ath/ath10k/Makefile
> index 6739ac26fd29..eccc9806fa43 100644
> --- a/drivers/net/wireless/ath/ath10k/Makefile
> +++ b/drivers/net/wireless/ath/ath10k/Makefile
> @@ -20,6 +20,7 @@ ath10k_core-$(CONFIG_NL80211_TESTMODE) += testmode.o
>  ath10k_core-$(CONFIG_ATH10K_TRACING) += trace.o
>  ath10k_core-$(CONFIG_THERMAL) += thermal.o
>  ath10k_core-$(CONFIG_MAC80211_DEBUGFS) += debugfs_sta.o
> +ath10k_core-$(CONFIG_ATH10K_LEDS) += gpio.o
>  ath10k_core-$(CONFIG_PM) += wow.o
>  ath10k_core-$(CONFIG_DEV_COREDUMP) += coredump.o
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index f3ec13b80b20..d7f89ca98c2d 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -21,6 +21,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +
>
>  #include "core.h"
>  #include "mac.h"
> @@ -65,6 +69,8 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
> .id = QCA988X_HW_2_0_VERSION,
> .dev_id = QCA988X_2_0_DEVICE_ID,
> .name = "qca988x hw2.0",
> +   .led_pin = 1,
> +   .gpio_count = 24,
> .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
> .uart_pin = 7,
> .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
> @@ -94,6 +100,8 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
> .id = QCA988X_HW_2_0_VERSION,
> .dev_id = QCA988X_2_0_DEVICE_ID_UBNT,
> .name = "qca988x hw2.0 ubiquiti",
> +   .led_pin = 1,
> +   .gpio_count = 24,
> .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
> .uart_pin = 7,
> .cc_wraparound_type =

Re: Deadlock debugging help.

2018-02-27 Thread Ben Greear


On 02/27/2018 12:49 PM, Ben Greear wrote:

I notice I can reliably lock up the kernel if I rmmod ath10k while it is under
heavy tx/rx traffic.  First, this causes the firmware to crash, and then right
after (or possibly during?) the related kernel threads deadlock.

This is with my hacked driver and hacked firmware.  In particular, the
ath10k_debug_nop_dwork is something I added, though it is pretty trivial,
it does take the ar->conf_mutex.  It appears blocked trying to get it.

It appears something is holding the ar->conf_mutex, but it is not clear to
me from the lockdep output what process actually holds it.
Anyone see a clue they could share?


Changing how I start/stop the nop_dwork stuff seems to have made the
problem go away, so I guess maybe that was the issue.

Thanks,
Ben



Thanks,
Ben


[ 1618.914057] sysrq: SysRq : Show Regs
[ 1618.916617] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW  O4.13.16+ 
#2
[ 1618.916618] Hardware name: _ _/ , BIOS 5.11 08/26/2016
[ 1618.916620] task: 88016d3ea740 task.stack: c96c8000
[ 1618.916624] RIP: 0010:cpuidle_enter_state+0x130/0x3b0
[ 1618.916625] RSP: 0018:c96cbe78 EFLAGS: 0202 ORIG_RAX: 
ff3e
[ 1618.916628] RAX: 88016d3ea740 RBX: 0008 RCX: 001f
[ 1618.916629] RDX: 0001 RSI: 0001 RDI: 88016d3ea740
[ 1618.916630] RBP: c96cbeb0 R08: 52ca R09: 
[ 1618.916631] R10:  R11:  R12: 0008
[ 1618.916633] R13: 880172d26c00 R14: 81ec66b8 R15: 0178ee494b98
[ 1618.916634] FS:  () GS:880172d0() 
knlGS:
[ 1618.916636] CS:  0010 DS:  ES:  CR0: 80050033
[ 1618.916637] CR2: 7ffdda2194b8 CR3: 01e0f000 CR4: 003406e0
[ 1618.916638] DR0:  DR1:  DR2: 
[ 1618.916639] DR3:  DR6: fffe0ff0 DR7: 0400
[ 1618.916640] Call Trace:
[ 1618.916645]  cpuidle_enter+0x12/0x20
[ 1618.916647]  call_cpuidle+0x1e/0x40
[ 1618.916649]  do_idle+0x184/0x1e0
[ 1618.916651]  cpu_startup_entry+0x5f/0x70
[ 1618.916654]  start_secondary+0x150/0x180
[ 1618.916657]  secondary_startup_64+0x9f/0x9f
[ 1618.916662] Code: b7 df 95 ff 48 89 45 d0 0f 1f 44 00 00 31 ff e8 97 6c 97 ff 8b 
45 c8 85 c0 0f 85 83 01 00 00 e8 57 5b 98 ff fb 66 0f 1f 44 00 00 <48> 8b 5d
d0 48 ba cf f7 53 e3 a5 9b c4 20 4c 29 fb 48 89 d8 48

[ 1618.916724] CPU#2: ctrl:   0007000f
[ 1618.916726] CPU#2: status: 
[ 1618.916727] CPU#2: overflow:   
[ 1618.916728] CPU#2: fixed:  00b0
[ 1618.916729] CPU#2: pebs:   
[ 1618.916730] CPU#2: debugctl:   
[ 1618.916731] CPU#2: active: 0002
[ 1618.916732] CPU#2:   gen-PMC0 ctrl:  
[ 1618.916733] CPU#2:   gen-PMC0 count: 
[ 1618.916734] CPU#2:   gen-PMC0 left:  
[ 1618.916735] CPU#2:   gen-PMC1 ctrl:  
[ 1618.916736] CPU#2:   gen-PMC1 count: 
[ 1618.916737] CPU#2:   gen-PMC1 left:  
[ 1618.916738] CPU#2:   gen-PMC2 ctrl:  
[ 1618.916739] CPU#2:   gen-PMC2 count: 
[ 1618.916740] CPU#2:   gen-PMC2 left:  
[ 1618.916742] CPU#2:   gen-PMC3 ctrl:  
[ 1618.916743] CPU#2:   gen-PMC3 count: 
[ 1618.916744] CPU#2:   gen-PMC3 left:  
[ 1618.916745] CPU#2: fixed-PMC0 count: 
[ 1618.916746] CPU#2: fixed-PMC1 count: fffed3945191
[ 1618.916747] CPU#2: fixed-PMC2 count: 
[ 1623.035449] INFO: task kworker/u8:1:273 blocked for more than 180 seconds.
[ 1623.041155]   Tainted: GW  O4.13.16+ #2
[ 1623.045173] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 1623.051966] kworker/u8:1D0   273  2 0x
[ 1623.052010] Workqueue: cfg80211 cfg80211_dfs_channels_update_work [cfg80211]
[ 1623.052026] Call Trace:
[ 1623.052032]  __schedule+0x407/0xb70
[ 1623.052037]  schedule+0x38/0x90
[ 1623.052039]  schedule_preempt_disabled+0x10/0x20
[ 1623.052041]  __mutex_lock+0x3d3/0x930
[ 1623.052044]  ? rtnl_lock+0x12/0x20
[ 1623.052050]  mutex_lock_nested+0x16/0x20
[ 1623.052052]  ? mutex_lock_nested+0x16/0x20
[ 1623.052054]  rtnl_lock+0x12/0x20
[ 1623.052066]  cfg80211_dfs_channels_update_work+0x3c/0x1c0 [cfg80211]
[ 1623.052069]  ? process_one_work+0x14f/0x6a0
[ 1623.052074]  process_one_work+0x1ce/0x6a0
[ 1623.052078]  worker_thread+0x46/0x440
[ 1623.052083]  kthread+0x10f/0x150
[ 1623.052084]  ? process_one_work+0x6a0/0x6a0
[ 1623.052086]  ? kthread_create_on_node+0x40/0x40
[ 1623.052088]  ? kthread_create_on_node+0x40/0x40
[ 1623.052091]  ret_from_fork+0x2a/0x40
[ 1623.052098] INFO: task kworker/u8:2:281 blocked for more than 180 seconds.
[ 1623.057700]   Tainted: GW  O

Deadlock debugging help.

2018-02-27 Thread Ben Greear


I notice I can reliably lock up the kernel if I rmmod ath10k while it is under
heavy tx/rx traffic.  First, this causes the firmware to crash, and then right
after (or possibly during?) the related kernel threads deadlock.

This is with my hacked driver and hacked firmware.  In particular, the
ath10k_debug_nop_dwork is something I added, though it is pretty trivial,
it does take the ar->conf_mutex.  It appears blocked trying to get it.

It appears something is holding the ar->conf_mutex, but it is not clear to
me from the lockdep output what process actually holds it.
Anyone see a clue they could share?

Thanks,
Ben


[ 1618.914057] sysrq: SysRq : Show Regs
[ 1618.916617] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW  O4.13.16+ 
#2
[ 1618.916618] Hardware name: _ _/ , BIOS 5.11 08/26/2016
[ 1618.916620] task: 88016d3ea740 task.stack: c96c8000
[ 1618.916624] RIP: 0010:cpuidle_enter_state+0x130/0x3b0
[ 1618.916625] RSP: 0018:c96cbe78 EFLAGS: 0202 ORIG_RAX: 
ff3e
[ 1618.916628] RAX: 88016d3ea740 RBX: 0008 RCX: 001f
[ 1618.916629] RDX: 0001 RSI: 0001 RDI: 88016d3ea740
[ 1618.916630] RBP: c96cbeb0 R08: 52ca R09: 
[ 1618.916631] R10:  R11:  R12: 0008
[ 1618.916633] R13: 880172d26c00 R14: 81ec66b8 R15: 0178ee494b98
[ 1618.916634] FS:  () GS:880172d0() 
knlGS:
[ 1618.916636] CS:  0010 DS:  ES:  CR0: 80050033
[ 1618.916637] CR2: 7ffdda2194b8 CR3: 01e0f000 CR4: 003406e0
[ 1618.916638] DR0:  DR1:  DR2: 
[ 1618.916639] DR3:  DR6: fffe0ff0 DR7: 0400
[ 1618.916640] Call Trace:
[ 1618.916645]  cpuidle_enter+0x12/0x20
[ 1618.916647]  call_cpuidle+0x1e/0x40
[ 1618.916649]  do_idle+0x184/0x1e0
[ 1618.916651]  cpu_startup_entry+0x5f/0x70
[ 1618.916654]  start_secondary+0x150/0x180
[ 1618.916657]  secondary_startup_64+0x9f/0x9f
[ 1618.916662] Code: b7 df 95 ff 48 89 45 d0 0f 1f 44 00 00 31 ff e8 97 6c 97 ff 8b 45 c8 85 c0 0f 85 83 01 00 00 e8 57 5b 98 ff fb 66 0f 1f 44 00 00 <48> 8b 5d 
d0 48 ba cf f7 53 e3 a5 9b c4 20 4c 29 fb 48 89 d8 48


[ 1618.916724] CPU#2: ctrl:   0007000f
[ 1618.916726] CPU#2: status: 
[ 1618.916727] CPU#2: overflow:   
[ 1618.916728] CPU#2: fixed:  00b0
[ 1618.916729] CPU#2: pebs:   
[ 1618.916730] CPU#2: debugctl:   
[ 1618.916731] CPU#2: active: 0002
[ 1618.916732] CPU#2:   gen-PMC0 ctrl:  
[ 1618.916733] CPU#2:   gen-PMC0 count: 
[ 1618.916734] CPU#2:   gen-PMC0 left:  
[ 1618.916735] CPU#2:   gen-PMC1 ctrl:  
[ 1618.916736] CPU#2:   gen-PMC1 count: 
[ 1618.916737] CPU#2:   gen-PMC1 left:  
[ 1618.916738] CPU#2:   gen-PMC2 ctrl:  
[ 1618.916739] CPU#2:   gen-PMC2 count: 
[ 1618.916740] CPU#2:   gen-PMC2 left:  
[ 1618.916742] CPU#2:   gen-PMC3 ctrl:  
[ 1618.916743] CPU#2:   gen-PMC3 count: 
[ 1618.916744] CPU#2:   gen-PMC3 left:  
[ 1618.916745] CPU#2: fixed-PMC0 count: 
[ 1618.916746] CPU#2: fixed-PMC1 count: fffed3945191
[ 1618.916747] CPU#2: fixed-PMC2 count: 
[ 1623.035449] INFO: task kworker/u8:1:273 blocked for more than 180 seconds.
[ 1623.041155]   Tainted: GW  O4.13.16+ #2
[ 1623.045173] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 1623.051966] kworker/u8:1D0   273  2 0x
[ 1623.052010] Workqueue: cfg80211 cfg80211_dfs_channels_update_work [cfg80211]
[ 1623.052026] Call Trace:
[ 1623.052032]  __schedule+0x407/0xb70
[ 1623.052037]  schedule+0x38/0x90
[ 1623.052039]  schedule_preempt_disabled+0x10/0x20
[ 1623.052041]  __mutex_lock+0x3d3/0x930
[ 1623.052044]  ? rtnl_lock+0x12/0x20
[ 1623.052050]  mutex_lock_nested+0x16/0x20
[ 1623.052052]  ? mutex_lock_nested+0x16/0x20
[ 1623.052054]  rtnl_lock+0x12/0x20
[ 1623.052066]  cfg80211_dfs_channels_update_work+0x3c/0x1c0 [cfg80211]
[ 1623.052069]  ? process_one_work+0x14f/0x6a0
[ 1623.052074]  process_one_work+0x1ce/0x6a0
[ 1623.052078]  worker_thread+0x46/0x440
[ 1623.052083]  kthread+0x10f/0x150
[ 1623.052084]  ? process_one_work+0x6a0/0x6a0
[ 1623.052086]  ? kthread_create_on_node+0x40/0x40
[ 1623.052088]  ? kthread_create_on_node+0x40/0x40
[ 1623.052091]  ret_from_fork+0x2a/0x40
[ 1623.052098] INFO: task kworker/u8:2:281 blocked for more than 180 seconds.
[ 1623.057700]   Tainted: GW  O4.13.16+ #2
[ 1623.061659] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 1623.068270] kworker/u8:2D0   281  2 0x
[ 1623.068282]

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

2018-02-27 Thread Sebastian Gottschall


Am 27.02.2018 um 18:03 schrieb Steve deRosier:

On Mon, Feb 26, 2018 at 12:44 AM,  wrote:

From: Sebastian Gottschall 

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and can be 
controlled with various triggers.
adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall 

v2  add correct gpio count per chipset and remove IPQ4019 support since this 
chipset does not make use of specific gpios)
v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error by 
kbuild test robot which does not occur in standard builds. curious
v6  correct return values and fix comment style
v7  fix ath10k_unregister_led for compiling without LED_CLASS
v8  fix various code design issues reported by reviewers
v9  move led and led code to separate sourcefile (gpio.c)
v10 compile fix if gpiolib isnt included
v11 make register_gpio_chip static. advise by krobot
v12 fix warning
---
  drivers/net/wireless/ath/ath10k/Kconfig   |  10 ++
  drivers/net/wireless/ath/ath10k/Makefile  |   1 +
  drivers/net/wireless/ath/ath10k/core.c|  28 -
  drivers/net/wireless/ath/ath10k/core.h|  62 +-
  drivers/net/wireless/ath/ath10k/debug.c   | 146 ++
  drivers/net/wireless/ath/ath10k/gpio.c| 196 ++
  drivers/net/wireless/ath/ath10k/hw.h  |   2 +
  drivers/net/wireless/ath/ath10k/mac.c |   5 +
  drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 +-
  drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 ++
  drivers/net/wireless/ath/ath10k/wmi.c |  46 +++
  drivers/net/wireless/ath/ath10k/wmi.h |  36 ++
  12 files changed, 630 insertions(+), 3 deletions(-)
  create mode 100644 drivers/net/wireless/ath/ath10k/gpio.c


Assuming that kbuild robot doesn't kick back another build-time
warning, it looks OK to me.

:-) seems so


Reviewed-by: Steve deRosier 

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/



--
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


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

2018-02-27 Thread Steve deRosier

On Mon, Feb 26, 2018 at 12:44 AM,  wrote:
>
> From: Sebastian Gottschall 
>
> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
> chipsets with on chipset connected led's
> using WMI Firmware API.
> The LED device will get available named as "ath10k-phyX" at sysfs and can be 
> controlled with various triggers.
> adds also debugfs interface for gpio control.
>
> Signed-off-by: Sebastian Gottschall 
>
> v2  add correct gpio count per chipset and remove IPQ4019 support since this 
> chipset does not make use of specific gpios)
> v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error by 
> kbuild test robot which does not occur in standard builds. curious
> v6  correct return values and fix comment style
> v7  fix ath10k_unregister_led for compiling without LED_CLASS
> v8  fix various code design issues reported by reviewers
> v9  move led and led code to separate sourcefile (gpio.c)
> v10 compile fix if gpiolib isnt included
> v11 make register_gpio_chip static. advise by krobot
> v12 fix warning
> ---
>  drivers/net/wireless/ath/ath10k/Kconfig   |  10 ++
>  drivers/net/wireless/ath/ath10k/Makefile  |   1 +
>  drivers/net/wireless/ath/ath10k/core.c|  28 -
>  drivers/net/wireless/ath/ath10k/core.h|  62 +-
>  drivers/net/wireless/ath/ath10k/debug.c   | 146 ++
>  drivers/net/wireless/ath/ath10k/gpio.c| 196 
> ++
>  drivers/net/wireless/ath/ath10k/hw.h  |   2 +
>  drivers/net/wireless/ath/ath10k/mac.c |   5 +
>  drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 +-
>  drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 ++
>  drivers/net/wireless/ath/ath10k/wmi.c |  46 +++
>  drivers/net/wireless/ath/ath10k/wmi.h |  36 ++
>  12 files changed, 630 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/net/wireless/ath/ath10k/gpio.c


Assuming that kbuild robot doesn't kick back another build-time
warning, it looks OK to me.

Reviewed-by: Steve deRosier 

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k: update the IRAM banks number for QCA9377

2018-02-27 Thread Kalle Valo

ryan...@codeaurora.org wrote:

> Preparation for a new QCA9377 firmware release. The new firmware release
> requires more IRAM banks, hence update that on ath10k.
> 
> The IRAM banks promotion won't break any backwards compatibility, as those 
> IRAM
> banks were not getting used in previous firmware releases.
> 
> Signed-off-by: Ryan Hsu 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

fc8b92635f79 ath10k: update the IRAM bank number for QCA9377

-- 
https://patchwork.kernel.org/patch/10208159/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k: Fix log message for hif power on failure

2018-02-27 Thread Kalle Valo

Govind Singh  wrote:

> HIF power-on failure is applicable to each underlying
> bus type. Fix log message for hif power on failure.
> 
> Signed-off-by: Govind Singh 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

cf0d37aecc06 ath10k: fix log message for hif power on failure

-- 
https://patchwork.kernel.org/patch/10199829/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fixed bit rate 9Mbps set as 24Mbps in g mode(legacy)

2018-02-27 Thread Ben Greear


On 02/27/2018 12:49 AM, KAVITA MATHUR wrote:

Hi,

I have configured AP in g mode and tested legacy rates.All basic rates and 
supported
rates(1,2,5.5,11,6,9,12,18,24,36,48,54) are set except 9Mbps.

When fixed bit rate 9Mbps is set, it gets set as 24 Mbps. This issue has been 
observed
in backports-4.4.2-1 as well as latest git version of ath10k driver.


Is anybody aware of this issue? How can I fix this rate 9Mbps?


You should specify which firmware/chipset you are using, since this might
easily be a firmware issue.

And, how are you determining that 'it gets set to 24Mbps'.  Is that the encoding
you see in a wifi sniff, or is the driver being set to 24Mbps improperly when
you use iw (or whatever) to try configuring the rate?

Recent upstream mac80211 has broken the ability to set a single tx rate as well,
last I checked.

Thanks,
Ben




Thanks & Regards,
Kavita


--
To unsubscribe from this list: send the line "unsubscribe backports" in




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PULL] ath10k firmware 20180219

2018-02-27 Thread Sebastian Gottschall

the latest 9984 firmware firmware-5.bin_10.4-3.5.3-00053 
 
will crash under certain configuration.
it was configured as wds ap with vht 160. client (wds sta) was a wrt3200 
with 88W8964 chipset
it seems that this crash only occures with vht160 configuration from 
what i have seen so far and only with this client chipset.

another test running a 9984 in wds sta mode did not raise up this issue

--
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


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

fixed bit rate 9Mbps set as 24Mbps in g mode(legacy)

2018-02-27 Thread KAVITA MATHUR

Hi,

I have configured AP in g mode and tested legacy rates.All basic rates and 
supported
rates(1,2,5.5,11,6,9,12,18,24,36,48,54) are set except 9Mbps.

When fixed bit rate 9Mbps is set, it gets set as 24 Mbps. This issue has been 
observed
in backports-4.4.2-1 as well as latest git version of ath10k driver.


Is anybody aware of this issue? How can I fix this rate 9Mbps?


Thanks & Regards,
Kavita



___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PULL] ath10k firmware 20180219

2018-02-27 Thread Sebastian Gottschall


what about this?


[   90.164755] ath10k_pci 0001:03:00.0: firmware crashed! (uuid n/a)
[   90.170845] ath10k_pci 0001:03:00.0: qca9984/qca9994 hw1.0 target 
0x0100 chip_id 0x sub 168c:cafe
[   90.180747] ath10k_pci 0001:03:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 0 testmode 0
[   90.189767] ath10k_pci 0001:03:00.0: firmware ver 10.4-3.5.3-00053 
api 5 features 
no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 
4c56a386
[   90.204013] ath10k_pci 0001:03:00.0: board_file api 1 bmi_id N/A 
crc32 31ab2fd1
[   90.211307] ath10k_pci 0001:03:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 
cal otp max-sta 512 raw 0 hwcrypto 1

[   90.222712] ath10k_pci 0001:03:00.0: firmware register dump:
[   90.228360] ath10k_pci 0001:03:00.0: [00]: 0x000A 0x15B3 
0x0A0014F9 0x00975B31
[   90.236266] ath10k_pci 0001:03:00.0: [04]: 0x0A0014F9 0x00060730 
0x001D 0x000A
[   90.244171] ath10k_pci 0001:03:00.0: [08]: 0x0042F23C 0x0045E8E0 
0x000EEE00 0x0001
[   90.252075] ath10k_pci 0001:03:00.0: [12]: 0x0009 0x 
0x00973ABC 0x00973AD2
[   90.259974] ath10k_pci 0001:03:00.0: [16]: 0x0A0014F9 0x009C36CB 
0x009606CA 0x
[   90.267879] ath10k_pci 0001:03:00.0: [20]: 0x409CB97D 0x0040673C 
0x0040 0x000E
[   90.275784] ath10k_pci 0001:03:00.0: [24]: 0x809805BF 0x0040679C 
0x 0xC09CB97D
[   90.283688] ath10k_pci 0001:03:00.0: [28]: 0x809C9B59 0x004068BC 
0x 0x9026
[   90.291586] ath10k_pci 0001:03:00.0: [32]: 0x809B72AF 0x004068EC 
0x000EEE00 0x0042C264
[   90.299491] ath10k_pci 0001:03:00.0: [36]: 0x809B39F2 0x0040692C 
0x0002 0x0042C264
[   90.307396] ath10k_pci 0001:03:00.0: [40]: 0x809B30CF 0x0040695C 
0x00406980 0x0042443C
[   90.315300] ath10k_pci 0001:03:00.0: [44]: 0x8096EE0E 0x0040697C 
0x000EEDF4 0x0001
[   90.323204] ath10k_pci 0001:03:00.0: [48]: 0x8096F883 0x00406A2C 
0x0042DE2C 0x00424A64
[   90.331102] ath10k_pci 0001:03:00.0: [52]: 0x80963A26 0x00406A4C 
0x0042DE2C 0x00405528
[   90.339006] ath10k_pci 0001:03:00.0: [56]: 0x80960E80 0x00406A9C 
0x000D 0x0040

[   90.346910] ath10k_pci 0001:03:00.0: Copy Engine register dump:
[   90.352829] ath10k_pci 0001:03:00.0: [00]: 0x0004a000  15  15 3   3
[   90.359262] ath10k_pci 0001:03:00.0: [01]: 0x0004a400   7   7 74  75
[   90.365700] ath10k_pci 0001:03:00.0: [02]: 0x0004a800  47  47 46  47
[   90.372139] ath10k_pci 0001:03:00.0: [03]: 0x0004ac00  31  31 0  31
[   90.378571] ath10k_pci 0001:03:00.0: [04]: 0x0004b000  11  11 51  11
[   90.385008] ath10k_pci 0001:03:00.0: [05]: 0x0004b400   8   8 71  72
[   90.391440] ath10k_pci 0001:03:00.0: [06]: 0x0004b800   3   3 3   3
[   90.397879] ath10k_pci 0001:03:00.0: [07]: 0x0004bc00   1   1 1   1
[   90.404318] ath10k_pci 0001:03:00.0: [08]: 0x0004c000   0   0 127   0
[   90.410748] ath10k_pci 0001:03:00.0: [09]: 0x0004c400   0   0 0   0
[   90.417185] ath10k_pci 0001:03:00.0: [10]: 0x0004c800   0   0 0   0
[   90.423623] ath10k_pci 0001:03:00.0: [11]: 0x0004cc00   0   0 0   0
[   90.430142] ath10k_pci 0001:03:00.0: failed to setup peer SMPS for 
vdev 0: -108
[   90.437452] ath10k_pci 0001:03:00.0: failed to associate station 
14:91:82:b9:16:d4 for vdev 0: -108

[   90.532746] ieee80211 phy0: Hardware restart was requested
[   90.538253] ath10k_pci 0001:03:00.0: failed to delete peer 
14:91:82:b9:16:d4 for vdev 0: -108

[   94.931518] ath10k_pci 0001:03:00.0: device successfully recovered


Am 26.02.2018 um 15:58 schrieb Kalle Valo:

Sebastian Gottschall  writes:


on 9984 i see these messages with this firmware from time to time

[272972.950788] ath10k_pci :01:00.0: Unknown eventid: 36925
[272982.868922] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.123780] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.156332] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.158813] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.193144] ath10k_pci :01:00.0: Unknown eventid: 36925
[365157.869540] ath10k_pci :01:00.0: Unknown eventid: 36925
[365157.902452] ath10k_pci :01:00.0: Unknown eventid: 36925


according to the WMI header this maybe a critical internal error

Thanks for the report. We are working on a fix but just ignore the
warning for now.



--
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


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fixed bit rate 9Mbps set as 24Mbps in g mode(legacy)

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[RFC] ath10k: Attempt to work around napi_synchronize hang.

RFC: Possible napi deadlock work-around?

Re: Deadlock debugging help.

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

Re: Deadlock debugging help.

Deadlock debugging help.

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

Re: ath10k: update the IRAM banks number for QCA9377

Re: ath10k: Fix log message for hif power on failure

Re: fixed bit rate 9Mbps set as 24Mbps in g mode(legacy)

Re: [PULL] ath10k firmware 20180219

fixed bit rate 9Mbps set as 24Mbps in g mode(legacy)

Re: [PULL] ath10k firmware 20180219

16 matches

Site Navigation

Mail list logo

Footer information