[OpenWrt-Devel] ath10k-ct 4.19 and IBSS

[Koen Vandeputte]

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;
                 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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel