event that will propagate to user-space, but should be ignored by the kernel
as far as making any changes to the regulatory logic. User-space could
ignore it as desired.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
up
[root@lf0313-63e7 lanforge]# iw phy wiphy1 info|grep STB
RX STBC 1-stream
Any idea on this?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 11/05/2018 02:49 PM, Igor Mitsyanko wrote:
On 11/05/2018 12:45 PM, Ben Greear wrote:
I see you don't implement it this way in the driver, but wouldn't it
make more sense to have this as a per-STA (RA) setting? That's really
the granularity it can be done on, I think?
Arguably even per-RA
API.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
ieee80211_local *local = hw_to_local(hw);
trace_wake_queue(local, queue, reason);
if (WARN_ON(queue >= hw->queues))
return;
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 10/23/2018 12:53 PM, Johannes Berg wrote:
On Tue, 2018-10-23 at 12:19 -0700, Ben Greear wrote:
Oct 23 12:11:05 ben-ota-2.candelatech.com kernel: Assigning beacon-in-gcd to:
240 from wdev: vap39
Oct 23 12:11:05 ben-ota-2.candelatech.com kernel: beacon-int-diff,
beacon-int-gcd: 240 new
On 10/23/2018 02:32 AM, Johannes Berg wrote:
On Mon, 2018-10-22 at 13:27 -0700, Ben Greear wrote:
I was testing on my 4.16 kernel with a bunch of VAPs and I had two configured
for 100 beacon interval, and more at 240. This failed for reasons I figured out
(gcd logic), but even once I tried
ing(wdev->netdev))
+ continue;
+
*beacon_int_different = true;
*beacon_int_gcd = gcd(*beacon_int_gcd, wdev->beacon_interval);
}
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 10/22/2018 05:07 AM, Johannes Berg wrote:
On Mon, 2018-10-22 at 14:06 +0200, Johannes Berg wrote:
On Fri, 2018-10-19 at 11:32 -0700, Ben Greear wrote:
I was hoping I could fit it into some existing stat. It is sort of like
retries, so that will be my first attempt.
By investigating an RF
ome tests to experiment with that when I have time, but curious if
others
have already done similar...
Thanks,
Ben
On 10/16/2018 04:31 PM, Ben Greear wrote:
So, I've been trying to understand why the ath10k-rate ctrl was acting
so poorly in my 20-station UDP tx case. I wrote that wifi-diag t
On 10/19/2018 11:25 AM, Steve deRosier wrote:
On Fri, Oct 19, 2018 at 10:34 AM Ben Greear wrote:
While debugging rate-ctrl in ath10k, I found the amount of mpdus transmitted vs
failed
ratio useful. Probably more useful than retries since retries could count an
attempt at
80Mhz followed
? I
currently only
get this stat for the first frame in an transmitted ampdu.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
ime at fixing things than I did.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 10/10/2018 12:13 PM, Dave Taht wrote:
On Wed, Oct 10, 2018 at 10:10 AM Ben Greear wrote:
On 10/03/2018 01:29 PM, Dave Taht wrote:
On Wed, Oct 3, 2018 at 1:16 PM Toke Høiland-Jørgensen wrote:
Ben Greear writes:
Hello,
I often find myself wanting to figure out what equipment
On 10/03/2018 01:29 PM, Dave Taht wrote:
On Wed, Oct 3, 2018 at 1:16 PM Toke Høiland-Jørgensen wrote:
Ben Greear writes:
Hello,
I often find myself wanting to figure out what equipment is to blame (and why)
in a wifi environment.
I am thinking writing a tool that would parse a pcap file
/heads/femwlan_stage2.kernel4.9
[2]
http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=package/kernel/mac80211/patches/915-use-more-time-for-multicast.patch;h=05d7fb6c2567e1abdef63a4d01f02df7f8501630;hb=refs/heads/femwlan_stage2.kernel4.9
Am 30.07.2018 16:34, schrieb Ben Greear:
On 07/30/2018 04:13
anyone have anything already written that they would like to share, or know
of projects that might already do some of this?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
ause the monitor vdev chanctx was null and that method checks a bit
later for it.
Maybe there is a way to create/configure the monitor vdev so that it has
a chanctx?
Thanks,
Ben
johannes
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 09/28/2018 12:19 AM, Johannes Berg wrote:
On Thu, 2018-09-27 at 08:32 -0700, Ben Greear wrote:
It seems though that if there's some noise or so on the channel you
wouldn't be transmitting, so what kind of "network glitches" might
affect this? AP going away unexpectedly for some
On 09/27/2018 12:12 AM, Johannes Berg wrote:
On Wed, 2018-09-26 at 15:21 -0700, Ben Greear wrote:
Now only 4 retries per frame, but it seems mac80211 is all 5 of its
null-data probes within a few miliseconds. Is that expected, or should
there be a bit more pause between each of the probe
On 09/26/2018 11:48 AM, Johannes Berg wrote:
On Wed, 2018-09-26 at 11:47 -0700, Ben Greear wrote:
I think I'll start by making sure the firmware does not do software retransmits
for frames from the driver (self-gen frames are OK to be retransmitted I guess).
You do want it to be doing
On 09/26/2018 11:48 AM, Johannes Berg wrote:
On Wed, 2018-09-26 at 11:47 -0700, Ben Greear wrote:
I think I'll start by making sure the firmware does not do software retransmits
for frames from the driver (self-gen frames are OK to be retransmitted I guess).
You do want it to be doing
On 09/26/2018 11:26 AM, Johannes Berg wrote:
On Wed, 2018-09-26 at 11:04 -0700, Ben Greear wrote:
I have been running with mac80211/mlme.c's max_nullfunc_tries set to 5 for many
years.
Long ago it helped with connectivity issues with lots of vdevs and and/orloaded
APs
if I recall correctly
On 09/26/2018 01:38 AM, Johannes Berg wrote:
On Tue, 2018-09-25 at 16:12 -0700, Ben Greear wrote:
While testing out some other issue, I noticed that my ath10k system creates
several hundred null-data probes when I abruptly down the AP the station
is connected to.
I guess this is because I use
times.
So, in the case where mac80211 is sending a null-data probe, is the assumption
that the driver will try each frame exactly once?
Or is several hundred frames expected? I'm guessing the former, but before I go
hacking firmware, I thought I would ask...
Thanks,
Ben
--
Ben Greear
Candela
On 09/19/2018 01:56 PM, Bruno Rosset wrote:
Hi,
Done, thanks
Le mer. 19 sept. 2018 à 22:45, Ben Greear a écrit :
On 09/19/2018 01:37 PM, Bruno Rosset wrote:
Hi all,
Various tests with others firmware from candelatech , stock LEDE 17.01
or dd-wrt give me firmware crash also
On 09/20/2018 12:31 AM, Johannes Berg wrote:
On Wed, 2018-09-19 at 13:47 -0700, Ben Greear wrote:
For one, the driver has no concept of the original vif, since monitor
vifs aren't added to it.
ath10k does create a monitor vif, but maybe it is not mapped directly
to mac80211.
It's
On 09/19/2018 01:35 PM, Johannes Berg wrote:
On Wed, 2018-09-19 at 13:33 -0700, Ben Greear wrote:
This is with a modified 4.16.18+ kernel, though the code in question
is from 2011, so this is not new...
I am attempting to use radiotap packet injection on a monitor port
/ath10k-ct/issues
https://www.candelatech.com/ath10k-bugs.php
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
break;
}
}
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 08/17/2018 03:49 PM, Ben Greear wrote:
I have been running some tests on un-modified Fedora 27, with a stock QCA
firmware-2.bin.
I realized a bit later than NetworkManager (or wpa_supplicant service?) was
already doing something with this
interface. When I disabled wpa_supplicant service
end trace 28cadc83f715e641 ]---
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 08/02/2018 01:20 PM, Toke Høiland-Jørgensen wrote:
Ben Greear writes:
On 08/02/2018 12:45 PM, Toke Høiland-Jørgensen wrote:
Ben Greear writes:
This is from my hacked kernel, could be my fault. I thought the fq
guys might want to know however...
Hmm, nothing obvious comes to mind
cmd_id);
+ queue_work(ar->workqueue, >restart_work);
+ }
+
return ret;
}
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 08/02/2018 12:45 PM, Toke Høiland-Jørgensen wrote:
Ben Greear writes:
This is from my hacked kernel, could be my fault. I thought the fq
guys might want to know however...
Hmm, nothing obvious comes to mind; fq_flow_dequeue() just dequeues a
packet from the queue; it only has two memory
88013d92a780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
88013d92a800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
======
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
tainly fix it
if there is no better way.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
ak supplicant to somewhat randomize the rekey timers,
but that would take a while to propagate to all of the station devices out
there.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
1:00.0: SWBA overrun on vdev 0, skipped old beacon
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
any patches you can share on this as well.
Thanks,
Ben
Regards,
M. Braun
Am 27. Juli 2018 15:35:28 MESZ schrieb Ben Greear :
Hello,
Has anyone tried making ath9k able to support 16 vAP interfaces on a
single
radio? I seem to recall that there were limitations regarding beacon
tim
On 07/16/2018 05:48 PM, gree...@candelatech.com wrote:
From: Ben Greear
Firmware already supports this, so just enable the path
to configure the vdev parameter.
One potential issue: The firmware (10.1 at least) defaults to 2,
and the mac80211 stack defaults to 4. So applying this patch
Hello,
Has anyone tried making ath9k able to support 16 vAP interfaces on a single
radio? I seem to recall that there were limitations regarding beacon
timers and such, and that is why the current limit is 8?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 07/17/2018 10:44 AM, Nicolas Cavallari wrote:
On 17/07/2018 17:02, Ben Greear wrote:
On 07/17/2018 12:57 AM, Nicolas Cavallari wrote:
In IBSS mode, all stations are required to send beacons. The protocol
is a bit
complex to arrange that, every 102.4ms, a station is chosen to emit
the beacon
.
Unfortunately, in the wild, nobody test that IBSS beacons are generated, because
without them, an open IBSS still appear to work...
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
R10: 05e7 R11: 0246 R12: 7ffe8d317310
R13: 0066b460 R14: 00007ffe8d31f380 R15:
ath10k_pci :04:00.0: boot hif power up
Suggestions are welcome.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 06/18/2018 01:46 PM, Johannes Berg wrote:
On Thu, 2018-05-31 at 08:52 -0700, Ben Greear wrote:
On 05/31/2018 02:06 AM, vnara...@codeaurora.org wrote:
On 2018-05-23 15:24, Johannes Berg wrote:
On Tue, 2018-05-22 at 14:45 +0530, Venkateswara Naralasetty wrote:
This patch provides support
to disable mac-80211 tx when FW crashes,
I think...I have not tried to backport that.
https://patchwork.kernel.org/patch/10411967/
Thanks,
Ben
Michał
On 8 June 2018 at 23:40, Arend van Spriel wrote:
On 6/8/2018 5:17 PM, Ben Greear wrote:
I recalled an email from Michał leaving tieto so
On 06/05/2018 03:53 PM, Brian Norris wrote:
Hi,
On Tue, Jun 05, 2018 at 03:27:28PM -0700, Ben Greear wrote:
I have been testing ath10k on 4.16, which uses the devcoredump API
to notify about dumps.
I am able to see the binary crash dump at /sys/class/devcoredump/devcd2/data,
for instance
on the coredump data, but it also seems to
indicate
that if I read the crash, the data should be cleared and ready to be
recreated again? How do you notify the system that the crash data has
been read?
I tried 'cat' on the data file, but that did not seem to clear anything.
Thanks,
Ben
--
Ben
to debug bugs.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 05/28/2018 10:54 AM, Sebastian Gottschall wrote:
Am 28.05.2018 um 16:43 schrieb Ben Greear:
On 05/27/2018 03:25 PM, Sebastian Gottschall wrote:
Am 25.05.2018 um 16:52 schrieb Ben Greear:
On 05/25/2018 07:44 AM, Kalle Valo wrote:
Sebastian Gottschall writes:
Am 26.04.2018 um 15
On 05/27/2018 03:25 PM, Sebastian Gottschall wrote:
Am 25.05.2018 um 16:52 schrieb Ben Greear:
On 05/25/2018 07:44 AM, Kalle Valo wrote:
Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:
Am 26.04.2018 um 15:44 schrieb Ben Greear:
On 04/26/2018 02:43 AM, s.gottsch...@dd-w
On 05/25/2018 07:44 AM, Kalle Valo wrote:
Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:
Am 26.04.2018 um 15:44 schrieb Ben Greear:
On 04/26/2018 02:43 AM, s.gottsch...@dd-wrt.com wrote:
From: Sebastian Gottschall <s.gottsch...@dd-wrt.com>
starting with firmware 10.4.
such a bad idea to use the tx callback instead of
the wake_tx_queue callback.
Kind regards,
Niklas
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
oblems more frequently, than they do
since they dont even take notice of such problems
We see recovery work often. If you see repeatable crashes, post them
to the list.
Do you know of any particular external clients that cause these crashes?
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com
FWCONF_MAP_160MHZ_M))
+#define BW_NSS_FWCONF_80_80(x)(BW_NSS_FWCONF_MAP_ENABLE | (((x - 1) <<
BW_NSS_FWCONF_MAP_80_80MHZ_S) & BW_NSS_FWCONF_MAP_80_80MHZ_M))
struct wmi_10_4_peer_assoc_complete_cmd {
struct wmi_10_2_peer_assoc_complete_cmd cmd;
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
ENABLE | (((x - 1) <<
BW_NSS_FWCONF_MAP_160MHZ_S) & BW_NSS_FWCONF_MAP_160MHZ_M))
+#define BW_NSS_FWCONF_80_80(x)(BW_NSS_FWCONF_MAP_ENABLE | (((x - 1) <<
BW_NSS_FWCONF_MAP_80_80MHZ_S) & BW_NSS_FWCONF_MAP_80_80MHZ_M))
struct wmi_10_4_peer_assoc_complete_cmd {
struct wmi_10_2_peer_assoc_complete_cmd cmd;
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
On 04/28/2018 08:26 AM, Sebastian Gottschall wrote:
Am 28.04.2018 um 17:01 schrieb Ben Greear:
On 04/27/2018 05:47 PM, s.gottsch...@dd-wrt.com wrote:
From: Sebastian Gottschall <s.gottsch...@dd-wrt.com>
current handling of peer_bw_rxnss_override parameter is based on guessing the
On 04/27/2018 05:24 PM, Sebastian Gottschall wrote:
Am 27.04.2018 um 23:57 schrieb Ben Greear:
On 04/27/2018 11:54 AM, Sebastian Gottschall wrote:
Am 27.04.2018 um 18:07 schrieb Ben Greear:
On 04/26/2018 09:40 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 22:35 schrieb Ben Greear
_160MHZ_S) & BW_NSS_FWCONF_MAP_160MHZ_M))
+#define BW_NSS_FWCONF_80_80(x)(BW_NSS_FWCONF_MAP_ENABLE | (((x - 1) <<
BW_NSS_FWCONF_MAP_80_80MHZ_S) & BW_NSS_FWCONF_MAP_80_80MHZ_M))
struct wmi_10_4_peer_assoc_complete_cmd {
struct wmi_10_2_peer_assoc_complete_cmd cmd;
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
On 04/27/2018 11:54 AM, Sebastian Gottschall wrote:
Am 27.04.2018 um 18:07 schrieb Ben Greear:
On 04/26/2018 09:40 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 22:35 schrieb Ben Greear:
On 04/26/2018 01:21 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 17:30 schrieb Ben Greear:
On 04
On 04/26/2018 09:40 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 22:35 schrieb Ben Greear:
On 04/26/2018 01:21 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 17:30 schrieb Ben Greear:
On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:
From: Sebastian Gottschall <s.gottsch...
On 04/26/2018 01:21 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 17:30 schrieb Ben Greear:
On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:
From: Sebastian Gottschall <s.gottsch...@dd-wrt.com>
current handling of peer_bw_rxnss_override parameter is based on guessing the
VHT16
(x) (BW_NSS_FWCONF_MAP_ENABLE | (((x - 1) <<
BW_NSS_FWCONF_MAP_80_80MHZ_S) & BW_NSS_FWCONF_MAP_80_80MHZ_M))
struct wmi_10_4_peer_assoc_complete_cmd {
struct wmi_10_2_peer_assoc_complete_cmd cmd;
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
r_freq2 = __cpu_to_le32(arg->band_center_freq1);
+ }
ch->min_power = arg->min_power;
ch->max_power = arg->max_power;
ch->reg_power = arg->max_reg_power;
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
On 04/22/2018 02:15 PM, Roopa Prabhu wrote:
On Sun, Apr 22, 2018 at 11:54 AM, David Miller <da...@davemloft.net> wrote:
From: Johannes Berg <johan...@sipsolutions.net>
Date: Thu, 19 Apr 2018 17:26:57 +0200
On Thu, 2018-04-19 at 08:25 -0700, Ben Greear wrote:
Maybe this could be
On 04/22/2018 11:54 AM, David Miller wrote:
From: Johannes Berg <johan...@sipsolutions.net>
Date: Thu, 19 Apr 2018 17:26:57 +0200
On Thu, 2018-04-19 at 08:25 -0700, Ben Greear wrote:
Maybe this could be in followup patches? It's going to touch a lot of files,
and might be hell to get
On 04/18/2018 11:38 PM, Johannes Berg wrote:
On Wed, 2018-04-18 at 14:51 -0700, Ben Greear wrote:
It'd be pretty hard to know which flags are firmware stats?
Yes, it is, but ethtool stats are difficult to understand in a generic
manner anyway, so someone using them is already likely aware
I'd be hearing about how
the netdev patch is useless because it has no driver support, etc.
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
.
And for the patch, it is also implied that I am able to write one.
Unfortunately, my opinion is that if you are unable to write one, then
you should not be mucking with the regulatory domain stuff at all.
Thanks,
Ben
2018-04-12 19:11 GMT+02:00 Ben Greear <gree...@candelatech.com>:
On
o improperly interpret
said rules because it's easier for them.
- Steve
--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
upstream:
https://www.spinics.net/lists/hostap/msg03677.html
So I really don't know enough to properly review
your patch. Just be aware that ath10k is weird about sw-crypt, maybe make
sure your patch is tested on it to make sure it doesn't out-right break
something.
Thanks,
Ben
--
Ben Greear
* the old key prior to switching to new key in mac80211.
+*/
+ ieee80211_key_disable_hw_accel(old);
+ } else {
idx = new->conf.keyidx;
+ }
if (sta) {
if (pairwise) {
--
Ben Greear <gree...@candelatec
the rcu_read_lock() to the
caller in ath9k.
Fixes: 50f08edf9809 ("ath9k: Switch to using mac80211 intermediate software
queues.")
Cc: sta...@vger.kernel.org
Reported-by: Ben Greear <gree...@candelatech.com>
Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
---
drivers/net/wir
MCS rates.
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
On 03/20/2018 11:24 AM, Michal Kubecek wrote:
On Tue, Mar 20, 2018 at 08:39:33AM -0700, Ben Greear wrote:
On 03/20/2018 03:37 AM, Michal Kubecek wrote:
IMHO it would be more practical to set "0 means same as GSTATS" as a
rule and make ethtool_get_stats() a wrapper for ethtool_
On 03/20/2018 09:11 AM, Steve deRosier wrote:
On Tue, Mar 20, 2018 at 8:39 AM, Ben Greear <gree...@candelatech.com> wrote:
On 03/20/2018 03:37 AM, Michal Kubecek wrote:
On Wed, Mar 07, 2018 at 11:51:29AM -0800, gree...@candelatech.com wrote:
From: Ben Greear <gree...@candel
On 03/20/2018 03:37 AM, Michal Kubecek wrote:
On Wed, Mar 07, 2018 at 11:51:29AM -0800, gree...@candelatech.com wrote:
From: Ben Greear <gree...@candelatech.com>
This is similar to ETHTOOL_GSTATS, but it allows you to specify
a 'level'. This level can be used by the driver to de
On 02/27/2018 08:03 PM, KAVITA MATHUR wrote:
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
to update ahb.c too.
I'll update ahb.c to match.
Thanks,
Ben
Michał
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
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
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
]
rtnl_lock+0x12/0x20
[ 1623.116905] #3: (>conf_mutex){+.+.+.}, at: []
ath10k_stop+0x24/0x80 [ath10k_core]
[ 1623.116915] 2 locks held by bash/7559:
[ 1623.116916] #0: (>ldisc_sem){++++.+}, at: []
ldsem_down_read+0x2d/0x40
[ 1623.116922] #1: (>atomic_read_lock){+.+...}, at:
[] n_tty_read+0xa9/0x8d0
[ 1623.116929] =
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
vita
--
To unsubscribe from this list: send the line "unsubscribe backports" in
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
On 02/26/2018 02:08 PM, Arend van Spriel wrote:
On 2/26/2018 10:39 PM, Ben Greear wrote:
On 02/07/2018 07:39 AM, Ben Greear wrote:
On 02/07/2018 02:55 AM, Johannes Berg wrote:
On Wed, 2018-02-07 at 10:16 +0100, Felix Fietkau wrote:
On 2018-02-07 00:05, gree...@candelatech.com wrote:
From
On 02/07/2018 07:39 AM, Ben Greear wrote:
On 02/07/2018 02:55 AM, Johannes Berg wrote:
On Wed, 2018-02-07 at 10:16 +0100, Felix Fietkau wrote:
On 2018-02-07 00:05, gree...@candelatech.com wrote:
From: Ben Greear <gree...@candelatech.com>
In case where the system is sluggish, we
which resource the firmware ran out of? It would seem to
be a FW bug if it is leaking, so maybe it can be fixed as well...
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
On 02/07/2018 02:55 AM, Johannes Berg wrote:
On Wed, 2018-02-07 at 10:16 +0100, Felix Fietkau wrote:
On 2018-02-07 00:05, gree...@candelatech.com wrote:
From: Ben Greear <gree...@candelatech.com>
In case where the system is sluggish, we should probably break out
early. Maybe this wi
johannes
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
On 02/01/2018 02:23 PM, Johannes Berg wrote:
On Wed, 2018-01-31 at 16:53 -0800, Ben Greear wrote:
Any idea why this might be complaining?
30917 Jan 31 15:21:01 2u-6n kernel: =
30918 Jan 31 15:21:01 2u-6n kernel: WARNING: suspicious RCU usage
well, that's
7ffee8bb8c70 RDI: 0004
31083 Jan 31 15:21:01 2u-6n kernel: RBP: 7ffee8bb8c70 R08:
0001 R09:
31084 Jan 31 15:21:01 2u-6n kernel: R10: 05e7 R11:
0246 R12: 7ffee8bb8cb0
31085 Jan 31 15:21:01 2u-6n kernel: R13: 0066b460 R14:
7ffee8bc0d20 R15:
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
On 01/30/2018 04:07 AM, Toke Høiland-Jørgensen wrote:
Ben Greear <gree...@candelatech.com> writes:
Maybe there is some way for the scheduler to get stuck and not
schedule anything?
It would appear so, yeah. Do you do anything special other than
associate a whole bunch of stations to t
On 01/29/2018 02:35 PM, Toke Høiland-Jørgensen wrote:
Ben Greear <gree...@candelatech.com> writes:
On 01/29/2018 01:47 PM, Toke Høiland-Jørgensen wrote:
Ben Greear <gree...@candelatech.com> writes:
On 01/27/2018 05:11 AM, Toke Høiland-Jørgensen wrote:
Ben Greear <gree...@
On 01/29/2018 01:47 PM, Toke Høiland-Jørgensen wrote:
Ben Greear <gree...@candelatech.com> writes:
On 01/27/2018 05:11 AM, Toke Høiland-Jørgensen wrote:
Ben Greear <gree...@candelatech.com> writes:
I'm doing a test with 200 virtual stations on each of 6 ath9k radios.
When
On 01/27/2018 05:11 AM, Toke Høiland-Jørgensen wrote:
Ben Greear <gree...@candelatech.com> writes:
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 som
On 01/27/2018 05:29 AM, Toke Høiland-Jørgensen wrote:
gree...@candelatech.com writes:
From: Ben Greear <gree...@candelatech.com>
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
as to whether this might be a real issue or not? I'll
go
digging in the meantime
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
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
1 - 100 of 571 matches
Mail list logo
