Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 8/9/19 7:14 AM, Koen Vandeputte wrote: On 09.08.19 15:31, Koen Vandeputte wrote: On 09.08.19 14:48, Ben Greear wrote: On 8/6/19 2:26 AM, Koen Vandeputte wrote: Hi Ben, I finally managed to get to some time to properly take a look using a simple setup. Attached all required files to simulate the issue. I compiled the latest OpenWrt master state, (included a full wpa_supplicant and iperf tools) and ran the 2 starts. Attached also logs as seen from both boards simultaneously. basically: - If the boards finally do link after lots of tries, it will have a >200ms latency and max speed of about 3Mbit. - The wpa_sup config file is the most basic RSN enabled config. - I also tried the current Master state with/without all custom pathes, but the result is the same. - wpa_supp also nags about some missing IE's Hw used: - 2x RB-922UAGS containing a on-board ar988x, capable of 30dBm. - 2x standard 5GHz omni antennae - board seperation distance ca 6ft Can you reproduce without encryption enabled? That makes it easier to debug packet sniffs. If you just run ping traffic (or very slow speed tcp/udp), do you still see the issues (like high latency, packet loss, poor on-air encoding rates, etc)? currently rebuilding the setup. will get back on this asap. If I build you a debugging firmware, are you able and willing to reproduce the problem and send me dmesg output as well as on-air packet sniff? Very sure! Preferably, with generated traffic with unique packet sizes (ie, ever increasing, random, or something like that, so I can more easily match up on-air frames with the debugging output. I believe that the beacon issues are probably a symptom of some other failure in the transmit and/or receive path. Thanks, Ben Lets get this fixed! :-) Koen Just tested with encryption disabled: summary: - speed is looking good. (~130Mbit/s) also link speed is 866Mbit (2x2 radio) - iw wlan0 confirms 80MHz channel - Only a single splat seen, no beacon errors - non-htt firmware Please see this bug I opened to track this. It has a firmware debugging image. In case it crashes on FW load, we will have to create and tweak a fwcfg file to decrease number of vdevs, peers, etc since the debugging code uses a lot of instruction space. https://github.com/greearb/ath10k-ct/issues/88 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 09.08.19 15:31, Koen Vandeputte wrote:
On 09.08.19 14:48, Ben Greear wrote:
On 8/6/19 2:26 AM, Koen Vandeputte wrote:
Hi Ben,
I finally managed to get to some time to properly take a look
using a simple setup.
Attached all required files to simulate the issue.
I compiled the latest OpenWrt master state, (included a full
wpa_supplicant and iperf tools) and ran the 2 starts.
Attached also logs as seen from both boards simultaneously.
basically:
- If the boards finally do link after lots of tries, it will have
a >200ms latency and max speed of about 3Mbit.
- The wpa_sup config file is the most basic RSN enabled config.
- I also tried the current Master state with/without all custom
pathes, but the result is the same.
- wpa_supp also nags about some missing IE's
Hw used:
- 2x RB-922UAGS containing a on-board ar988x, capable of 30dBm.
- 2x standard 5GHz omni antennae
- board seperation distance ca 6ft
Can you reproduce without encryption enabled? That makes it easier
to debug
packet sniffs.
If you just run ping traffic (or very slow speed tcp/udp), do you
still see the issues (like high
latency, packet loss, poor on-air encoding rates, etc)?
currently rebuilding the setup. will get back on this asap.
If I build you a debugging firmware, are you able and willing to
reproduce the problem and
send me dmesg output as well as on-air packet sniff?
Very sure!
Preferably, with generated traffic with unique packet sizes (ie, ever
increasing, random, or something like
that, so I can more easily match up on-air frames with the debugging
output.
I believe that the beacon issues are probably a symptom of some other
failure in the transmit and/or
receive path.
Thanks,
Ben
Lets get this fixed! :-)
Koen
Just tested with encryption disabled:
summary:
- speed is looking good. (~130Mbit/s) also link speed is 866Mbit (2x2 radio)
- iw wlan0 confirms 80MHz channel
- Only a single splat seen, no beacon errors
- non-htt firmware
dmesg: https://pastebin.com/YLbJCDJc
configs:
network={
ssid="ibsskoen"
key_mgmt=NONE
mode=1
frequency=5745
}
iwinfo:
wlan0 ESSID: "ibsskoen"
Access Point: B8:69:F4:CF:C6:05
Mode: Ad-Hoc Channel: 149 (5.745 GHz)
Tx-Power: 30 dBm Link Quality: 70/70
Signal: -5 dBm Noise: -102 dBm
Bit Rate: 866.7 MBit/s
Encryption: unknown
Type: nl80211 HW Mode(s): 802.11nac
Hardware: 168C:003C 19B6:D042 [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 09.08.19 14:48, Ben Greear wrote: On 8/6/19 2:26 AM, Koen Vandeputte wrote: Hi Ben, I finally managed to get to some time to properly take a look using a simple setup. Attached all required files to simulate the issue. I compiled the latest OpenWrt master state, (included a full wpa_supplicant and iperf tools) and ran the 2 starts. Attached also logs as seen from both boards simultaneously. basically: - If the boards finally do link after lots of tries, it will have a >200ms latency and max speed of about 3Mbit. - The wpa_sup config file is the most basic RSN enabled config. - I also tried the current Master state with/without all custom pathes, but the result is the same. - wpa_supp also nags about some missing IE's Hw used: - 2x RB-922UAGS containing a on-board ar988x, capable of 30dBm. - 2x standard 5GHz omni antennae - board seperation distance ca 6ft Can you reproduce without encryption enabled? That makes it easier to debug packet sniffs. If you just run ping traffic (or very slow speed tcp/udp), do you still see the issues (like high latency, packet loss, poor on-air encoding rates, etc)? currently rebuilding the setup. will get back on this asap. If I build you a debugging firmware, are you able and willing to reproduce the problem and send me dmesg output as well as on-air packet sniff? Very sure! Preferably, with generated traffic with unique packet sizes (ie, ever increasing, random, or something like that, so I can more easily match up on-air frames with the debugging output. I believe that the beacon issues are probably a symptom of some other failure in the transmit and/or receive path. Thanks, Ben Lets get this fixed! :-) Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 8/6/19 2:26 AM, Koen Vandeputte wrote: Hi Ben, I finally managed to get to some time to properly take a look using a simple setup. Attached all required files to simulate the issue. I compiled the latest OpenWrt master state, (included a full wpa_supplicant and iperf tools) and ran the 2 starts. Attached also logs as seen from both boards simultaneously. basically: - If the boards finally do link after lots of tries, it will have a >200ms latency and max speed of about 3Mbit. - The wpa_sup config file is the most basic RSN enabled config. - I also tried the current Master state with/without all custom pathes, but the result is the same. - wpa_supp also nags about some missing IE's Hw used: - 2x RB-922UAGS containing a on-board ar988x, capable of 30dBm. - 2x standard 5GHz omni antennae - board seperation distance ca 6ft Can you reproduce without encryption enabled? That makes it easier to debug packet sniffs. If you just run ping traffic (or very slow speed tcp/udp), do you still see the issues (like high latency, packet loss, poor on-air encoding rates, etc)? If I build you a debugging firmware, are you able and willing to reproduce the problem and send me dmesg output as well as on-air packet sniff? Preferably, with generated traffic with unique packet sizes (ie, ever increasing, random, or something like that, so I can more easily match up on-air frames with the debugging output. I believe that the beacon issues are probably a symptom of some other failure in the transmit and/or receive path. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 05.08.19 18:17, Koen Vandeputte wrote:
On 05.08.19 17:47, Koen Vandeputte wrote:
On 27.06.19 16:24, Ben Greear wrote:
On 6/27/19 7:17 AM, Koen Vandeputte wrote:
On 26.06.19 18:39, Ben Greear wrote:
On 6/26/19 9:28 AM, Koen Vandeputte wrote:
On 26.06.19 18:16, Ben Greear wrote:
On 6/26/19 2:02 AM, Koen Vandeputte wrote:
On 25.06.19 15:54, Ben Greear wrote:
On 06/25/2019 02:53 AM, Koen Vandeputte wrote:
On 24.06.19 22:04, Ben Greear wrote:
On 6/24/19 8:32 AM, Koen Vandeputte wrote:
Hi Ben,
Hi All,
So I'm going to give this another try ..
As the IBSS functionality is heavily advertised as a delta
to mainline, it would be very nice to get it working also :)
Testing the latest ath10k-ct driver and firmware seems to
be a step back compared to roughly a month ago.
I'm currently seeing the firmware crashing, which was not
the case before:
ath10k-ct + htt-fw:
https://pastebin.com/raw/7Sy9yx6s
Looks like firmware ran out of some WMI event buffers and
crashed instead of handling
it more gracefully.
Please try the attached (untested) firmware and see if it
behaves better.
Hi Ben,
1 step forward here.
I'm not seeing crashes anymore using the test-firmware.
https://pastebin.com/raw/4ZeXu7iw
I've linked up 2 IBSS devices (wave 1, VHT80)
OLSR traffic (UDP) works and packets here are nicely going
back & forth.
Simply pinging (ICMP) between the 2 devices does not work.
When sending 100 pings, (64 byte large) sometimes 1 gets
through .. but with a latency of > 500ms
I think if the splat and the beacon spam below could be fixed
.. this would be a major step forward:
[ 30.328423] [ cut here ]
[ 30.333251] WARNING: CPU: 0 PID: 1578 at
/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563
ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core]
[ 30.355636] Modules linked in: mbt ath9k ath9k_common
qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci
ath10k_core ath usb_wwan sierra_net sierra rndis_host
qmi_wwan pppox ppp_generic mac80211 iptable_nat
iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE
ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm
cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport
xt_mark xt_mac xt_limt
[ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc
ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug
ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core
mii aead crypto_null cryptomgr crc32c_generic crypto_hash
[ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not
tainted 4.14.129 #0
Please look in your code and let me know the source around the
line in mac.c (6563) that is splatting.
Also, you might grab the latest ath10k-ct repo, it has a tweak
that might fix the SWBA overrun
messages.
https://github.com/greearb/ath10k-ct
Thanks,
Ben
Hi Ben,
Here is the output based on the latest git HEAD of your ct
tree, combined with the test firmware:
https://pastebin.com/raw/kwC6c18J
Hello,
The splat decode does not match the source code, so I'm not
which is correct.
OpenWrt seems to add custom patches to your source.
Please find the complete source in subsequent mail as being build.
I did look in that code, and that is where I saw the mismatch.
Please check your own local system
and see if the splat matches your code? Maybe I made some mistake
of course...
You can paste ~20 lines of code around the proper splat line and
then I can find it in my
source...
Thanks,
Ben
Hi Ben,
Just retried again on a slightly older commit (2019-05-08) and the
splat points to another location now.
When looking it up, it again points to the WARN_ON pointed below ..
Checking shows that all calls to ath10k_mac_vif_beacon_free() calls
are way above this line (highest line nr is around line1970)
I currently can't explain where the mismatch comes from ..
Current build below is just the git HEAD of openwrt 19.07 branch,
cloned, build and flashed without any modification.
[ 31.956774] WARNING: CPU: 0 PID: 1725 at
/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563
ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core]
ret = ath10k_config_ps(ar);
if (ret)
ath10k_warn(ar, "failed to setup ps on
vdev %i: %d\n",
arvif->vdev_id, ret);
}
if (changed & BSS_CHANGED_MCAST_RATE &&
---> !WARN_ON(ath10k_mac_vif_chan(arvif->vif, ))) {
band = def.chan->band;
I think this might not be to serious of a bug, and probably does not
cause any real
trouble.
It is also probably a bug in mac80211 or similar, but not certain
about that.
The general set of bugs related to IBSS seem to be inability to
transmit frames
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
> On 27 Jun 2019, at 15:49, Koen Vandeputte > wrote: > > >> On 6/27/19 7:17 AM, Koen Vandeputte wrote: > > I'm really wondering if the additional openwrt patches on top come in play > here .. > I'm not able to even send a simple ping across the link. Agreed. The ath10k-ct patches in package/kernel/ath10k-ct/patches make for disturbing reading although they apply cleanly. Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 27.06.19 16:24, Ben Greear wrote:
On 6/27/19 7:17 AM, Koen Vandeputte wrote:
On 26.06.19 18:39, Ben Greear wrote:
On 6/26/19 9:28 AM, Koen Vandeputte wrote:
On 26.06.19 18:16, Ben Greear wrote:
On 6/26/19 2:02 AM, Koen Vandeputte wrote:
On 25.06.19 15:54, Ben Greear wrote:
On 06/25/2019 02:53 AM, Koen Vandeputte wrote:
On 24.06.19 22:04, Ben Greear wrote:
On 6/24/19 8:32 AM, Koen Vandeputte wrote:
Hi Ben,
Hi All,
So I'm going to give this another try ..
As the IBSS functionality is heavily advertised as a delta to
mainline, it would be very nice to get it working also :)
Testing the latest ath10k-ct driver and firmware seems to be
a step back compared to roughly a month ago.
I'm currently seeing the firmware crashing, which was not the
case before:
ath10k-ct + htt-fw:
https://pastebin.com/raw/7Sy9yx6s
Looks like firmware ran out of some WMI event buffers and
crashed instead of handling
it more gracefully.
Please try the attached (untested) firmware and see if it
behaves better.
Hi Ben,
1 step forward here.
I'm not seeing crashes anymore using the test-firmware.
https://pastebin.com/raw/4ZeXu7iw
I've linked up 2 IBSS devices (wave 1, VHT80)
OLSR traffic (UDP) works and packets here are nicely going back
& forth.
Simply pinging (ICMP) between the 2 devices does not work.
When sending 100 pings, (64 byte large) sometimes 1 gets
through .. but with a latency of > 500ms
I think if the splat and the beacon spam below could be fixed
.. this would be a major step forward:
[ 30.328423] [ cut here ]
[ 30.333251] WARNING: CPU: 0 PID: 1578 at
/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563
ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core]
[ 30.355636] Modules linked in: mbt ath9k ath9k_common
qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci
ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan
pppox ppp_generic mac80211 iptable_nat iptable_mangle
iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables
huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether
xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac
xt_limt
[ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc
ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4
mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead
crypto_null cryptomgr crc32c_generic crypto_hash
[ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not
tainted 4.14.129 #0
Please look in your code and let me know the source around the
line in mac.c (6563) that is splatting.
Also, you might grab the latest ath10k-ct repo, it has a tweak
that might fix the SWBA overrun
messages.
https://github.com/greearb/ath10k-ct
Thanks,
Ben
Hi Ben,
Here is the output based on the latest git HEAD of your ct tree,
combined with the test firmware:
https://pastebin.com/raw/kwC6c18J
Hello,
The splat decode does not match the source code, so I'm not which
is correct.
OpenWrt seems to add custom patches to your source.
Please find the complete source in subsequent mail as being build.
I did look in that code, and that is where I saw the mismatch.
Please check your own local system
and see if the splat matches your code? Maybe I made some mistake
of course...
You can paste ~20 lines of code around the proper splat line and
then I can find it in my
source...
Thanks,
Ben
Hi Ben,
Just retried again on a slightly older commit (2019-05-08) and the
splat points to another location now.
When looking it up, it again points to the WARN_ON pointed below ..
Checking shows that all calls to ath10k_mac_vif_beacon_free() calls
are way above this line (highest line nr is around line1970)
I currently can't explain where the mismatch comes from ..
Current build below is just the git HEAD of openwrt 19.07 branch,
cloned, build and flashed without any modification.
[ 31.956774] WARNING: CPU: 0 PID: 1725 at
/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563
ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core]
ret = ath10k_config_ps(ar);
if (ret)
ath10k_warn(ar, "failed to setup ps on vdev
%i: %d\n",
arvif->vdev_id, ret);
}
if (changed & BSS_CHANGED_MCAST_RATE &&
---> !WARN_ON(ath10k_mac_vif_chan(arvif->vif, ))) {
band = def.chan->band;
I think this might not be to serious of a bug, and probably does not
cause any real
trouble.
It is also probably a bug in mac80211 or similar, but not certain
about that.
The general set of bugs related to IBSS seem to be inability to
transmit frames
sometimes (though it usually works well in my lab, so I have not been
able to really
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 6/27/19 7:17 AM, Koen Vandeputte wrote:
On 26.06.19 18:39, Ben Greear wrote:
On 6/26/19 9:28 AM, Koen Vandeputte wrote:
On 26.06.19 18:16, Ben Greear wrote:
On 6/26/19 2:02 AM, Koen Vandeputte wrote:
On 25.06.19 15:54, Ben Greear wrote:
On 06/25/2019 02:53 AM, Koen Vandeputte wrote:
On 24.06.19 22:04, Ben Greear wrote:
On 6/24/19 8:32 AM, Koen Vandeputte wrote:
Hi Ben,
Hi All,
So I'm going to give this another try ..
As the IBSS functionality is heavily advertised as a delta to mainline, it
would be very nice to get it working also :)
Testing the latest ath10k-ct driver and firmware seems to be a step back
compared to roughly a month ago.
I'm currently seeing the firmware crashing, which was not the case before:
ath10k-ct + htt-fw:
https://pastebin.com/raw/7Sy9yx6s
Looks like firmware ran out of some WMI event buffers and crashed instead of
handling
it more gracefully.
Please try the attached (untested) firmware and see if it behaves better.
Hi Ben,
1 step forward here.
I'm not seeing crashes anymore using the test-firmware.
https://pastebin.com/raw/4ZeXu7iw
I've linked up 2 IBSS devices (wave 1, VHT80)
OLSR traffic (UDP) works and packets here are nicely going back & forth.
Simply pinging (ICMP) between the 2 devices does not work.
When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a
latency of > 500ms
I think if the splat and the beacon spam below could be fixed .. this would be
a major step forward:
[ 30.328423] [ cut here ]
[ 30.333251] WARNING: CPU: 0 PID: 1578 at
/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c
[ath10k_core]
[ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net
sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm
ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt
[ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base
usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash
[ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0
Please look in your code and let me know the source around the line in mac.c
(6563) that is splatting.
Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix
the SWBA overrun
messages.
https://github.com/greearb/ath10k-ct
Thanks,
Ben
Hi Ben,
Here is the output based on the latest git HEAD of your ct tree, combined with
the test firmware:
https://pastebin.com/raw/kwC6c18J
Hello,
The splat decode does not match the source code, so I'm not which is correct.
OpenWrt seems to add custom patches to your source.
Please find the complete source in subsequent mail as being build.
I did look in that code, and that is where I saw the mismatch. Please check
your own local system
and see if the splat matches your code? Maybe I made some mistake of course...
You can paste ~20 lines of code around the proper splat line and then I can
find it in my
source...
Thanks,
Ben
Hi Ben,
Just retried again on a slightly older commit (2019-05-08) and the splat points
to another location now.
When looking it up, it again points to the WARN_ON pointed below ..
Checking shows that all calls to ath10k_mac_vif_beacon_free() calls are way
above this line (highest line nr is around line1970)
I currently can't explain where the mismatch comes from ..
Current build below is just the git HEAD of openwrt 19.07 branch, cloned, build
and flashed without any modification.
[ 31.956774] WARNING: CPU: 0 PID: 1725 at
/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563
ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core]
ret = ath10k_config_ps(ar);
if (ret)
ath10k_warn(ar, "failed to setup ps on vdev %i: %d\n",
arvif->vdev_id, ret);
}
if (changed & BSS_CHANGED_MCAST_RATE &&
---> !WARN_ON(ath10k_mac_vif_chan(arvif->vif, ))) {
band = def.chan->band;
I think this might not be to serious of a bug, and probably does not cause any
real
trouble.
It is also probably a bug in mac80211 or similar, but not certain about that.
The general set of bugs related to IBSS seem to be inability to transmit frames
sometimes (though it usually works well in my lab, so I have not been able to
really
debug it).
The simpler the test case, the better. So, if you can
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 26.06.19 18:39, Ben Greear wrote:
On 6/26/19 9:28 AM, Koen Vandeputte wrote:
On 26.06.19 18:16, Ben Greear wrote:
On 6/26/19 2:02 AM, Koen Vandeputte wrote:
On 25.06.19 15:54, Ben Greear wrote:
On 06/25/2019 02:53 AM, Koen Vandeputte wrote:
On 24.06.19 22:04, Ben Greear wrote:
On 6/24/19 8:32 AM, Koen Vandeputte wrote:
Hi Ben,
Hi All,
So I'm going to give this another try ..
As the IBSS functionality is heavily advertised as a delta to
mainline, it would be very nice to get it working also :)
Testing the latest ath10k-ct driver and firmware seems to be a
step back compared to roughly a month ago.
I'm currently seeing the firmware crashing, which was not the
case before:
ath10k-ct + htt-fw:
https://pastebin.com/raw/7Sy9yx6s
Looks like firmware ran out of some WMI event buffers and
crashed instead of handling
it more gracefully.
Please try the attached (untested) firmware and see if it
behaves better.
Hi Ben,
1 step forward here.
I'm not seeing crashes anymore using the test-firmware.
https://pastebin.com/raw/4ZeXu7iw
I've linked up 2 IBSS devices (wave 1, VHT80)
OLSR traffic (UDP) works and packets here are nicely going back &
forth.
Simply pinging (ICMP) between the 2 devices does not work.
When sending 100 pings, (64 byte large) sometimes 1 gets through
.. but with a latency of > 500ms
I think if the splat and the beacon spam below could be fixed ..
this would be a major step forward:
[ 30.328423] [ cut here ]
[ 30.333251] WARNING: CPU: 0 PID: 1578 at
/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563
ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core]
[ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial
pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core
ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox
ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter
ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio
cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state
xt_nat xt_multiport xt_mark xt_mac xt_limt
[ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc
ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4
mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead
crypto_null cryptomgr crc32c_generic crypto_hash
[ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted
4.14.129 #0
Please look in your code and let me know the source around the
line in mac.c (6563) that is splatting.
Also, you might grab the latest ath10k-ct repo, it has a tweak
that might fix the SWBA overrun
messages.
https://github.com/greearb/ath10k-ct
Thanks,
Ben
Hi Ben,
Here is the output based on the latest git HEAD of your ct tree,
combined with the test firmware:
https://pastebin.com/raw/kwC6c18J
Hello,
The splat decode does not match the source code, so I'm not which is
correct.
OpenWrt seems to add custom patches to your source.
Please find the complete source in subsequent mail as being build.
I did look in that code, and that is where I saw the mismatch. Please
check your own local system
and see if the splat matches your code? Maybe I made some mistake of
course...
You can paste ~20 lines of code around the proper splat line and then
I can find it in my
source...
Thanks,
Ben
Hi Ben,
Just retried again on a slightly older commit (2019-05-08) and the splat
points to another location now.
When looking it up, it again points to the WARN_ON pointed below ..
Checking shows that all calls to ath10k_mac_vif_beacon_free() calls are
way above this line (highest line nr is around line1970)
I currently can't explain where the mismatch comes from ..
Current build below is just the git HEAD of openwrt 19.07 branch,
cloned, build and flashed without any modification.
[ 31.956774] WARNING: CPU: 0 PID: 1725 at
/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563
ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core]
ret = ath10k_config_ps(ar);
if (ret)
ath10k_warn(ar, "failed to setup ps on vdev %i:
%d\n",
arvif->vdev_id, ret);
}
if (changed & BSS_CHANGED_MCAST_RATE &&
---> !WARN_ON(ath10k_mac_vif_chan(arvif->vif, ))) {
band = def.chan->band;
mcast_rate = vif->bss_conf.mcast_rate[band];
if (mcast_rate > 0)
rateidx = mcast_rate - 1;
else
rateidx = ffs(vif->bss_conf.basic_rates) - 1;
if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
Regards,
Koen
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 6/26/19 9:28 AM, Koen Vandeputte wrote: On 26.06.19 18:16, Ben Greear wrote: On 6/26/19 2:02 AM, Koen Vandeputte wrote: On 25.06.19 15:54, Ben Greear wrote: On 06/25/2019 02:53 AM, Koen Vandeputte wrote: On 24.06.19 22:04, Ben Greear wrote: On 6/24/19 8:32 AM, Koen Vandeputte wrote: Hi Ben, Hi All, So I'm going to give this another try .. As the IBSS functionality is heavily advertised as a delta to mainline, it would be very nice to get it working also :) Testing the latest ath10k-ct driver and firmware seems to be a step back compared to roughly a month ago. I'm currently seeing the firmware crashing, which was not the case before: ath10k-ct + htt-fw: https://pastebin.com/raw/7Sy9yx6s Looks like firmware ran out of some WMI event buffers and crashed instead of handling it more gracefully. Please try the attached (untested) firmware and see if it behaves better. Hi Ben, 1 step forward here. I'm not seeing crashes anymore using the test-firmware. https://pastebin.com/raw/4ZeXu7iw I've linked up 2 IBSS devices (wave 1, VHT80) OLSR traffic (UDP) works and packets here are nicely going back & forth. Simply pinging (ICMP) between the 2 devices does not work. When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a latency of > 500ms I think if the splat and the beacon spam below could be fixed .. this would be a major step forward: [ 30.328423] [ cut here ] [ 30.333251] WARNING: CPU: 0 PID: 1578 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt [ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash [ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0 Please look in your code and let me know the source around the line in mac.c (6563) that is splatting. Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix the SWBA overrun messages. https://github.com/greearb/ath10k-ct Thanks, Ben Hi Ben, Here is the output based on the latest git HEAD of your ct tree, combined with the test firmware: https://pastebin.com/raw/kwC6c18J Hello, The splat decode does not match the source code, so I'm not which is correct. OpenWrt seems to add custom patches to your source. Please find the complete source in subsequent mail as being build. I did look in that code, and that is where I saw the mismatch. Please check your own local system and see if the splat matches your code? Maybe I made some mistake of course... You can paste ~20 lines of code around the proper splat line and then I can find it in my source... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 26.06.19 18:16, Ben Greear wrote: On 6/26/19 2:02 AM, Koen Vandeputte wrote: On 25.06.19 15:54, Ben Greear wrote: On 06/25/2019 02:53 AM, Koen Vandeputte wrote: On 24.06.19 22:04, Ben Greear wrote: On 6/24/19 8:32 AM, Koen Vandeputte wrote: Hi Ben, Hi All, So I'm going to give this another try .. As the IBSS functionality is heavily advertised as a delta to mainline, it would be very nice to get it working also :) Testing the latest ath10k-ct driver and firmware seems to be a step back compared to roughly a month ago. I'm currently seeing the firmware crashing, which was not the case before: ath10k-ct + htt-fw: https://pastebin.com/raw/7Sy9yx6s Looks like firmware ran out of some WMI event buffers and crashed instead of handling it more gracefully. Please try the attached (untested) firmware and see if it behaves better. Hi Ben, 1 step forward here. I'm not seeing crashes anymore using the test-firmware. https://pastebin.com/raw/4ZeXu7iw I've linked up 2 IBSS devices (wave 1, VHT80) OLSR traffic (UDP) works and packets here are nicely going back & forth. Simply pinging (ICMP) between the 2 devices does not work. When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a latency of > 500ms I think if the splat and the beacon spam below could be fixed .. this would be a major step forward: [ 30.328423] [ cut here ] [ 30.333251] WARNING: CPU: 0 PID: 1578 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt [ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash [ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0 Please look in your code and let me know the source around the line in mac.c (6563) that is splatting. Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix the SWBA overrun messages. https://github.com/greearb/ath10k-ct Thanks, Ben Hi Ben, Here is the output based on the latest git HEAD of your ct tree, combined with the test firmware: https://pastebin.com/raw/kwC6c18J Hello, The splat decode does not match the source code, so I'm not which is correct. OpenWrt seems to add custom patches to your source. Please find the complete source in subsequent mail as being build. Regards, Koen [ 32.341077] [ cut here ] [ 32.345898] WARNING: CPU: 0 PID: 1470 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-06-13-f0aa8130/ath10k-4.19/mac.c:6581 ath10k_mac_vif_beacon_free+0xc54/0x112c [ath10k_core] (line 6581 is not in the mac_vif_beacon_free method). Also, please enable the firmware DBGLOG logging per instructions here: http://www.candelatech.com/ath10k-bugs.php This is the suggested level to debug at: 0xc032 Will do and will get back on this. Thanks Thanks, Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 26.06.19 11:02, Koen Vandeputte wrote: On 25.06.19 15:54, Ben Greear wrote: On 06/25/2019 02:53 AM, Koen Vandeputte wrote: On 24.06.19 22:04, Ben Greear wrote: On 6/24/19 8:32 AM, Koen Vandeputte wrote: Hi Ben, Hi All, So I'm going to give this another try .. As the IBSS functionality is heavily advertised as a delta to mainline, it would be very nice to get it working also :) Testing the latest ath10k-ct driver and firmware seems to be a step back compared to roughly a month ago. I'm currently seeing the firmware crashing, which was not the case before: ath10k-ct + htt-fw: https://pastebin.com/raw/7Sy9yx6s Looks like firmware ran out of some WMI event buffers and crashed instead of handling it more gracefully. Please try the attached (untested) firmware and see if it behaves better. Hi Ben, 1 step forward here. I'm not seeing crashes anymore using the test-firmware. https://pastebin.com/raw/4ZeXu7iw I've linked up 2 IBSS devices (wave 1, VHT80) OLSR traffic (UDP) works and packets here are nicely going back & forth. Simply pinging (ICMP) between the 2 devices does not work. When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a latency of > 500ms I think if the splat and the beacon spam below could be fixed .. this would be a major step forward: [ 30.328423] [ cut here ] [ 30.333251] WARNING: CPU: 0 PID: 1578 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt [ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash [ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0 Please look in your code and let me know the source around the line in mac.c (6563) that is splatting. Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix the SWBA overrun messages. https://github.com/greearb/ath10k-ct Thanks, Ben Hi Ben, Here is the output based on the latest git HEAD of your ct tree, combined with the test firmware: https://pastebin.com/raw/kwC6c18J Regards, Koen Here is the source as compiled in openwrt: http://www.xback.be/ath10k-419.tar.xz Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 25.06.19 15:54, Ben Greear wrote: On 06/25/2019 02:53 AM, Koen Vandeputte wrote: On 24.06.19 22:04, Ben Greear wrote: On 6/24/19 8:32 AM, Koen Vandeputte wrote: Hi Ben, Hi All, So I'm going to give this another try .. As the IBSS functionality is heavily advertised as a delta to mainline, it would be very nice to get it working also :) Testing the latest ath10k-ct driver and firmware seems to be a step back compared to roughly a month ago. I'm currently seeing the firmware crashing, which was not the case before: ath10k-ct + htt-fw: https://pastebin.com/raw/7Sy9yx6s Looks like firmware ran out of some WMI event buffers and crashed instead of handling it more gracefully. Please try the attached (untested) firmware and see if it behaves better. Hi Ben, 1 step forward here. I'm not seeing crashes anymore using the test-firmware. https://pastebin.com/raw/4ZeXu7iw I've linked up 2 IBSS devices (wave 1, VHT80) OLSR traffic (UDP) works and packets here are nicely going back & forth. Simply pinging (ICMP) between the 2 devices does not work. When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a latency of > 500ms I think if the splat and the beacon spam below could be fixed .. this would be a major step forward: [ 30.328423] [ cut here ] [ 30.333251] WARNING: CPU: 0 PID: 1578 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt [ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash [ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0 Please look in your code and let me know the source around the line in mac.c (6563) that is splatting. Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix the SWBA overrun messages. https://github.com/greearb/ath10k-ct Thanks, Ben Hi Ben, Here is the output based on the latest git HEAD of your ct tree, combined with the test firmware: https://pastebin.com/raw/kwC6c18J Regards, Koen [ 30.454906] Stack : 8050 804c0870 80495404 86fc5a24 8606485c 804e7307 [ 30.463402] 804915c8 062a 805437d0 19a3 87d1ed28 0001 86fc59d8 ebb059e8 [ 30.471880] 8054 68e8 0007 [ 30.480373] 0123 f55b2536 0122 8000 87152504 8710ccc4 [ 30.488863] 0009 19a3 87d1ed28 876fd000 802a3964 8054 [ 30.497355] ... [ 30.499839] Call Trace: [ 30.502320] [<8006c7ac>] show_stack+0x58/0x100 [ 30.506838] [<80086de0>] __warn+0xe4/0x118 [ 30.510994] [<80086ea4>] warn_slowpath_null+0x1c/0x28 [ 30.516158] [<8710ccc4>] ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.523505] ---[ end trace 83fd3571e310245a ]--- [ 33.172852] wlan0: Trigger new scan to find an IBSS to join [ 33.237416] wlan0: Trigger new scan to find an IBSS to join [ 33.243317] wlan0: Trigger new scan to find an IBSS to join [ 33.249205] wlan0: Trigger new scan to find an IBSS to join [ 33.305210] wlan0: Trigger new scan to find an IBSS to join [ 34.049614] wlan0: Trigger new scan to find an IBSS to join [ 34.115369] wlan0: Trigger new scan to find an IBSS to join [ 34.189823] wlan0: Selected IBSS BSSID fa:77:78:55:af:7b based on configured SSID [ 34.280540] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.288002] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.295924] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.303406] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.310839] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.318280] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.325714] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.333148] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.340567] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.348003] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon ... ... Thanks for your swift
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 06/25/2019 02:53 AM, Koen Vandeputte wrote: On 24.06.19 22:04, Ben Greear wrote: On 6/24/19 8:32 AM, Koen Vandeputte wrote: Hi Ben, Hi All, So I'm going to give this another try .. As the IBSS functionality is heavily advertised as a delta to mainline, it would be very nice to get it working also :) Testing the latest ath10k-ct driver and firmware seems to be a step back compared to roughly a month ago. I'm currently seeing the firmware crashing, which was not the case before: ath10k-ct + htt-fw: https://pastebin.com/raw/7Sy9yx6s Looks like firmware ran out of some WMI event buffers and crashed instead of handling it more gracefully. Please try the attached (untested) firmware and see if it behaves better. Hi Ben, 1 step forward here. I'm not seeing crashes anymore using the test-firmware. https://pastebin.com/raw/4ZeXu7iw I've linked up 2 IBSS devices (wave 1, VHT80) OLSR traffic (UDP) works and packets here are nicely going back & forth. Simply pinging (ICMP) between the 2 devices does not work. When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a latency of > 500ms I think if the splat and the beacon spam below could be fixed .. this would be a major step forward: [ 30.328423] [ cut here ] [ 30.333251] WARNING: CPU: 0 PID: 1578 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt [ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash [ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0 Please look in your code and let me know the source around the line in mac.c (6563) that is splatting. Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix the SWBA overrun messages. https://github.com/greearb/ath10k-ct Thanks, Ben [ 30.454906] Stack : 8050 804c0870 80495404 86fc5a24 8606485c 804e7307 [ 30.463402] 804915c8 062a 805437d0 19a3 87d1ed28 0001 86fc59d8 ebb059e8 [ 30.471880] 8054 68e8 0007 [ 30.480373] 0123 f55b2536 0122 8000 87152504 8710ccc4 [ 30.488863] 0009 19a3 87d1ed28 876fd000 802a3964 8054 [ 30.497355] ... [ 30.499839] Call Trace: [ 30.502320] [<8006c7ac>] show_stack+0x58/0x100 [ 30.506838] [<80086de0>] __warn+0xe4/0x118 [ 30.510994] [<80086ea4>] warn_slowpath_null+0x1c/0x28 [ 30.516158] [<8710ccc4>] ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.523505] ---[ end trace 83fd3571e310245a ]--- [ 33.172852] wlan0: Trigger new scan to find an IBSS to join [ 33.237416] wlan0: Trigger new scan to find an IBSS to join [ 33.243317] wlan0: Trigger new scan to find an IBSS to join [ 33.249205] wlan0: Trigger new scan to find an IBSS to join [ 33.305210] wlan0: Trigger new scan to find an IBSS to join [ 34.049614] wlan0: Trigger new scan to find an IBSS to join [ 34.115369] wlan0: Trigger new scan to find an IBSS to join [ 34.189823] wlan0: Selected IBSS BSSID fa:77:78:55:af:7b based on configured SSID [ 34.280540] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.288002] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.295924] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.303406] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.310839] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.318280] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.325714] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.333148] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.340567] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.348003] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon ... ... Thanks for your swift reply so far and the test-firmware. Regards, Koen ath10k-ct + non-htt-fw: https://pastebin.com/raw/bqVqQmXq Mixing upstream ath10k driver with the non-htt CT fw does not work. Errors are seen here regarding
