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, &def))) {
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 reproduce
some packet transmit
issue, preferably:
2 peers
slow speed traffic
no encryption
no funny routing (OLSR, batman, etc)
Please let me know.
And, if you cannot reproduce in this simple setup, then what
is the thing closest to this that does show the issue? I can build
firmware with
verbose tx-path (and rx-path, for that matter) debugging and let you
run it if you can
find a good test case, but it cannot gather useful logs at high
packet transmission rates.
Thanks,
Ben
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
Kind regards,
Koen
(Re-Send due to large size)
Hi Ben,
Enabling debug shed some light:
ath10k-4.19/wmi.c:
spin_lock_bh(&ar->data_lock);
bcn = arvif->beacon;
if (!bcn)
goto unlock;
cb = ATH10K_SKB_CB(bcn);
switch (arvif->beacon_state) {
case ATH10K_BEACON_SENDING:
case ATH10K_BEACON_SENT:
break;
case ATH10K_BEACON_SCHEDULED:
arvif->beacon_state = ATH10K_BEACON_SENDING;
spin_unlock_bh(&ar->data_lock);
dtim_zero = !!(cb->flags & ATH10K_SKB_F_DTIM_ZERO);
deliver_cab = !!(cb->flags & ATH10K_SKB_F_DELIVER_CAB);
ret = ath10k_wmi_beacon_send_ref_nowait(arvif,
bcn->data, bcn->len,
cb->paddr,
dtim_zero,
deliver_cab);
ath10k_dbg(ar, ATH10K_DBG_BEACON,
"wmi event beacon send, vdev-id: %u rv: %d\n",
arvif->vdev_id, ret);
spin_lock_bh(&ar->data_lock);
if (ret == 0)
arvif->beacon_state = ATH10K_BEACON_SENT;
else
arvif->beacon_state = ATH10K_BEACON_SCHEDULED;
}
unlock:
spin_unlock_bh(&ar->data_lock);
}
-----------
dmesg:
[ 1758.739939] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: 0
[ 1758.750522] ath10k_pci 0000:01:00.0: wmi event beacon-tx-complete,
vdev-id: 0 completion-status: 0x0 (OK) tried: 1 failed: 0 ratecode: 0x3
rateflags: 0x0 tsFlags: 0x0
[ 1758.772647] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 1758.842348] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: 0
[ 1758.853062] ath10k_pci 0000:01:00.0: wmi event beacon-tx-complete,
vdev-id: 0 completion-status: 0x0 (OK) tried: 1 failed: 0 ratecode: 0x3
rateflags: 0x0 tsFlags: 0x0
[ 1758.944759] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: 0
[ 1758.955501] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: 0
[ 1758.955526] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: 0
[ 1758.955546] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: -11
[ 1758.955559] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped
old beacon
[ 1758.963032] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: -11
[ 1758.963048] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped
old beacon
[ 1758.970468] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: -11
[ 1758.970481] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped
old beacon
[ 1758.977918] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: -11
[ 1758.977933] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped
old beacon
[ 1758.985370] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: -11
[ 1758.987837] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: 0
[ 1758.987971] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: -11
[ 1758.987986] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped
old beacon
[ 1758.995459] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: -11
[ 1758.995475] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped
old beacon
[ 1759.002910] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: -11
[ 1759.002926] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped
old beacon
[ 1759.010342] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: -11
[ 1759.010360] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: 0
[ 1759.010378] ath10k_pci 0000:01:00.0: wmi event beacon send, vdev-id:
0 rv: -11
[ 1759.010391] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped
old beacon
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
