Coder Social home page Coder Social logo

Comments (16)

greearb avatar greearb commented on September 27, 2024

from ath10k-ct.

master8282 avatar master8282 commented on September 27, 2024

Hello Ben,

"Does LEDE work on non-DFS channels?" On lede unfortunately I'm not able to start the device as DFS as without DFS, before I start hostapd daemon, I see the traces and when load ath10k_pci module.

[ 1603.538238] Call Trace:
[ 1603.538453]
[ 1603.538566] [] ? dump_stack+0x5d/0x79
[ 1603.538985] [] ? __warn+0xb2/0xcb
[ 1603.539313] [] ? ath10k_htt_t2h_msg_handler+0xb80/0x1861 [ath10k_core]
[ 1603.539798] [] ? ath10k_htt_t2h_msg_handler+0xcfe/0x1861 [ath10k_core]
[ 1603.540282] [] ? ath10k_htt_txrx_compl_task+0x8b4/0xfde [ath10k_core]
[ 1603.540760] [] ? ath10k_pci_hif_exchange_bmi_msg+0x10ee/0x110c [ath10k_pci]
[ 1603.541255] [] ? ath10k_ce_per_engine_service+0xba/0xcc [ath10k_pci]
[ 1603.541730] [] ? ath10k_pci_enable_legacy_irq+0x8e/0x107 [ath10k_pci]
[ 1603.542210] [] ? net_rx_action+0xeb/0x25a
[ 1603.542560] [] ? __do_softirq+0xb8/0x1a1
[ 1603.542906] [] ? irq_exit+0x4f/0x5b
[ 1603.543238] [] ? do_IRQ+0xa4/0xba
[ 1603.543566] [] ? common_interrupt+0x93/0x93
[ 1603.543917]
[ 1603.544026] [] ? native_safe_halt+0x2/0x3
[ 1603.544451] [] ? default_idle+0x5/0x8
[ 1603.544790] [] ? cpu_startup_entry+0x11c/0x1ce
[ 1603.545154] [] ? start_secondary+0x12b/0x12e
[ 1603.545448] ---[ end trace 8d4d257a180fa625 ]---

And after that hostapd can not connect with wlan interface.

About Ubuntu:
"And, on DFS channels, it will not work because your radio detects
RADAR, which will then properly disable DFS channels."
I would imagine if I could have wrong hostaptd config or requested frequencies are occupied.
But I have one more wifi card - Compex WLE900V5-27 and I use almost same configs (only without 160 MHz setting), and no any problem with working the second wifi card. And wifi spectrum analyzer shows many vacant frequencies.

I already thinking about I got factory defective wle1216v5-20 and maybe send it back to seller for checking. Unfortunately I don't know about any another firmwares except candelatech to check the card with alternative firmware and be 100% sure about hardware issue.

Thank you.

from ath10k-ct.

greearb avatar greearb commented on September 27, 2024

I have recently posted patches that were accepted into LEDE. These enable my latest driver and firmware. Maybe re-test with those and see if the problem is improved? Please post more dmesg logs if errors are seen with the latest...

from ath10k-ct.

master8282 avatar master8282 commented on September 27, 2024

Dear Ben,

After much suffering and tries I could build working configuration.
I found out that mainboard makes sense.
Now I use the intel NUC mainboard with UEFI and embedded core i3 inside.

I made some tests using different drivers, here is my report:

I didn't get any issues even using standard linux drivers to make it working under 80 Mhz, only boars-2.bin I had to take at compex drivers.

But for 160MHz native linux ath10k drivers don't work for 160Mhz I see the following errors:

nl80211: Start radar detection (CAC) 5500 MHz (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz, cf2=0 MHz)
* freq=5500
* vht_enabled=1
* ht_enabled=1
* bandwidth=160
* channel_width=5
* center_freq1=5570
* center_freq2=0
nl80211: Failed to start radar detection: -16 (Device or resource busy)
DFS start_dfs_cac() failed, -1
Interface initialization failed

I used kernel (stable: 4.16.15) and built your ath10k-ct, got four ko modules, and just changed them with native from linux.
And the wonderful has happened, using new modules and candella tech firmware (only firmware-5-ct-non-commercial.bin - it is important), I made working configuration.
If I use any another CT firmware, it works fine for 80MHz, but for 160MHz I see the following error:

nl80211: Start radar detection (CAC) 5500 MHz (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz, cf2=0 MHz)
* freq=5500
* vht_enabled=1
* ht_enabled=1
* bandwidth=160
* channel_width=5
* center_freq1=5570
* center_freq2=0
nl80211: Failed to start radar detection: -110 (Connection timed out)
DFS start_dfs_cac() failed, -1
Interface initialization failed

Here is my workable hostapd.conf if someone needs:

interface=<your_wlan>
driver=nl80211

### IEEE 802.11
ssid=<your_ssid>
hw_mode=a
channel=100
auth_algs=1

### DFS
ieee80211h=1
ieee80211d=1
country_code=AU

### IEEE 802.11n
ieee80211n=1
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40]

### IEEE 802.11ac
ieee80211ac=1
vht_oper_chwidth=2
vht_oper_centr_freq_seg0_idx=114
vht_capab=[RXLDPC][SHORT-GI-80][SHORT-GI-160][TX-STBC-2BY1][SU-BEAMFORMER][SU-BEAMFORMEE][MU-BEAMFORMER][MU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC-1][VHT160-80PLUS80][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7]

### WPA/IEEE 802.11i
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_passphrase=<your_password>
wpa_pairwise=CCMP

Channels can be set in 36 and 50, then also works fine.

Ben I have only one question - why 160 Mhz mode work only under firmware-5-ct-non-commercial.bin ?

And Ben thank you so much for you work and your drivers, I very appreciate it, it helped me much.
I will continue testing my configuration under load and let you know if get any new issues.

Thank you,
Alex.

from ath10k-ct.

greearb avatar greearb commented on September 27, 2024

I am not sure why just the non-commercial one works. The special features that it enables will not even be turned on unless you have special driver configuration enabled.

Can you send me 'dmesg' output of the successful 160Mhz and of the failed attempt with one of the other firmware flavors?

from ath10k-ct.

master8282 avatar master8282 commented on September 27, 2024

Hi Ben,

The requested dmesgs here:

  1. for "http://www.candelatech.com/downloads/ath10k-9984-10-4/firmware-5-ct-non-commercial.bin"
    dmesg_non_com.txt

  2. for "http://www.candelatech.com/downloads/ath10k-9984-10-4/firmware-5-ct-full-community.bin"
    dmesg_com.txt

from ath10k-ct.

master8282 avatar master8282 commented on September 27, 2024

Hello Ben,

Next issue is very high ping to clients side (ping of the gateway from clients is ok).

root@ubuntu1804:~# ping 192.168.111.61
PING 192.168.111.61 (192.168.111.61) 56(84) bytes of data.
64 bytes from 192.168.111.61: icmp_seq=1 ttl=64 time=1.52 ms
64 bytes from 192.168.111.61: icmp_seq=9 ttl=64 time=988 ms
64 bytes from 192.168.111.61: icmp_seq=10 ttl=64 time=1.84 ms
64 bytes from 192.168.111.61: icmp_seq=11 ttl=64 time=4003 ms
64 bytes from 192.168.111.61: icmp_seq=12 ttl=64 time=2996 ms
64 bytes from 192.168.111.61: icmp_seq=13 ttl=64 time=1972 ms
64 bytes from 192.168.111.61: icmp_seq=14 ttl=64 time=948 ms
64 bytes from 192.168.111.61: icmp_seq=15 ttl=64 time=1.58 ms
64 bytes from 192.168.111.61: icmp_seq=16 ttl=64 time=3052 ms
64 bytes from 192.168.111.61: icmp_seq=17 ttl=64 time=2046 ms
64 bytes from 192.168.111.61: icmp_seq=18 ttl=64 time=1022 ms
64 bytes from 192.168.111.61: icmp_seq=19 ttl=64 time=0.960 ms

root@ubuntu1804:~# ping 192.168.111.54
PING 192.168.111.54 (192.168.111.54) 56(84) bytes of data.
64 bytes from 192.168.111.54: icmp_seq=1 ttl=64 time=3999 ms
64 bytes from 192.168.111.54: icmp_seq=2 ttl=64 time=2968 ms
64 bytes from 192.168.111.54: icmp_seq=3 ttl=64 time=1944 ms
64 bytes from 192.168.111.54: icmp_seq=4 ttl=64 time=920 ms
64 bytes from 192.168.111.54: icmp_seq=5 ttl=64 time=2.24 ms
64 bytes from 192.168.111.54: icmp_seq=30 ttl=64 time=1.94 ms
64 bytes from 192.168.111.54: icmp_seq=31 ttl=64 time=1229 ms
64 bytes from 192.168.111.54: icmp_seq=32 ttl=64 time=214 ms
^C
--- 192.168.111.54 ping statistics ---
34 packets transmitted, 8 received, 76% packet loss, time 33671ms

root@ubuntu1804:~# tracepath 192.168.111.61
1?: [LOCALHOST] pmtu 1500
1: 192.168.111.61 1.858ms reached
1: 192.168.111.61 3.771ms reached
Resume: pmtu 1500 hops 1 back 1

root@ubuntu1804:~# tcpdump -lei wlp2s0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:03:29.704776 04:f0:21:38:98:ae (oui Unknown) > f4:5c:89:c4:7e:2b (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.111.1 > 192.168.111.61: ICMP echo request, id 1991, seq 159, length 64
13:03:30.719582 04:f0:21:38:98:ae (oui Unknown) > f4:5c:89:c4:7e:2b (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.111.1 > 192.168.111.61: ICMP echo request, id 1991, seq 160, length 64
13:03:31.743561 04:f0:21:38:98:ae (oui Unknown) > f4:5c:89:c4:7e:2b (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.111.1 > 192.168.111.61: ICMP echo request, id 1991, seq 161, length 64
13:03:32.140034 f4:5c:89:c4:7e:2b (oui Unknown) > 04:f0:21:38:98:ae (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.111.61 > 192.168.111.1: ICMP echo reply, id 1991, seq 159, length 64
13:03:32.140315 f4:5c:89:c4:7e:2b (oui Unknown) > 04:f0:21:38:98:ae (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.111.61 > 192.168.111.1: ICMP echo reply, id 1991, seq 160, length 64
13:03:32.140438 f4:5c:89:c4:7e:2b (oui Unknown) > 04:f0:21:38:98:ae (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.111.61 > 192.168.111.1: ICMP echo reply, id 1991, seq 161, length 64
13:03:32.744242 04:f0:21:38:98:ae (oui Unknown) > f4:5c:89:c4:7e:2b (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.111.1 > 192.168.111.61: ICMP echo request, id 1991, seq 162, length 64
13:03:33.759559 04:f0:21:38:98:ae (oui Unknown) > f4:5c:89:c4:7e:2b (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.111.1 > 192.168.111.61: ICMP echo request, id 1991, seq 163, length 64
13:03:33.759566 f4:5c:89:c4:7e:2b (oui Unknown) > 04:f0:21:38:98:ae (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.111.61 > 192.168.111.1: ICMP echo reply, id 1991, seq 162, length 64
13:03:33.761992 f4:5c:89:c4:7e:2b (oui Unknown) > 04:f0:21:38:98:ae (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.111.61 > 192.168.111.1: ICMP echo reply, id 1991, seq 163, length 64
13:03:34.761298 04:f0:21:38:98:ae (oui Unknown) > f4:5c:89:c4:7e:2b (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.111.1 > 192.168.111.61: ICMP echo request, id 1991, seq 164, length 64
13:03:35.775549 04:f0:21:38:98:ae (oui Unknown) > f4:5c:89:c4:7e:2b (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.111.1 > 192.168.111.61: ICMP echo request, id 1991, seq 165, length 64

root@ubuntu1804:~# ip r
default via 172.16.0.1 dev eno1
172.16.0.0/24 dev eno1 proto kernel scope link src 172.16.0.18
192.168.111.0/24 dev br0 proto kernel scope link src 192.168.111.1

root@ubuntu1804:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether c0:3f:d5:6f:aa:5f brd ff:ff:ff:ff:ff:ff
inet 172.16.0.18/24 brd 172.16.0.255 scope global eno1
valid_lft forever preferred_lft forever
inet6 fe80::c23f:d5ff:fe6f:aa5f/64 scope link
valid_lft forever preferred_lft forever
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
link/ether 04:f0:21:38:98:ae brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 04:f0:21:38:98:ae brd ff:ff:ff:ff:ff:ff
inet 192.168.111.1/24 brd 192.168.111.254 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::ccd0:9aff:fe0f:7e4/64 scope link
valid_lft forever preferred_lft forever

root@ubuntu1804:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.04f0213898ae no wlp2s0

the outputs were taken when hostapd.conf has only necessary params for starting the daemon, no any additional tuning.
Also I tried many tunings but unfortunately no result and I still have the issue.

from ath10k-ct.

master8282 avatar master8282 commented on September 27, 2024

Ben,
Today I tried default firmware-5.bin and default ath10k drivers on 80Mhz and the worst ping was about 550ms,
ant@ubuntu1804:~$ ping 192.168.111.54
PING 192.168.111.54 (192.168.111.54) 56(84) bytes of data.
64 bytes from 192.168.111.54: icmp_seq=1 ttl=64 time=164 ms
64 bytes from 192.168.111.54: icmp_seq=2 ttl=64 time=186 ms
64 bytes from 192.168.111.54: icmp_seq=3 ttl=64 time=3.60 ms
64 bytes from 192.168.111.54: icmp_seq=4 ttl=64 time=27.5 ms
64 bytes from 192.168.111.54: icmp_seq=5 ttl=64 time=47.3 ms
64 bytes from 192.168.111.54: icmp_seq=6 ttl=64 time=72.3 ms
64 bytes from 192.168.111.54: icmp_seq=7 ttl=64 time=93.2 ms
64 bytes from 192.168.111.54: icmp_seq=8 ttl=64 time=114 ms
64 bytes from 192.168.111.54: icmp_seq=9 ttl=64 time=138 ms
64 bytes from 192.168.111.54: icmp_seq=10 ttl=64 time=161 ms
64 bytes from 192.168.111.54: icmp_seq=11 ttl=64 time=184 ms
64 bytes from 192.168.111.54: icmp_seq=12 ttl=64 time=207 ms
64 bytes from 192.168.111.54: icmp_seq=13 ttl=64 time=25.1 ms
64 bytes from 192.168.111.54: icmp_seq=14 ttl=64 time=46.8 ms
64 bytes from 192.168.111.54: icmp_seq=15 ttl=64 time=116 ms
64 bytes from 192.168.111.54: icmp_seq=16 ttl=64 time=2.25 ms
64 bytes from 192.168.111.54: icmp_seq=17 ttl=64 time=114 ms
64 bytes from 192.168.111.54: icmp_seq=18 ttl=64 time=341 ms
64 bytes from 192.168.111.54: icmp_seq=19 ttl=64 time=364 ms
64 bytes from 192.168.111.54: icmp_seq=20 ttl=64 time=386 ms
64 bytes from 192.168.111.54: icmp_seq=21 ttl=64 time=518 ms
64 bytes from 192.168.111.54: icmp_seq=22 ttl=64 time=25.1 ms
64 bytes from 192.168.111.54: icmp_seq=23 ttl=64 time=359 ms
64 bytes from 192.168.111.54: icmp_seq=24 ttl=64 time=378 ms
64 bytes from 192.168.111.54: icmp_seq=25 ttl=64 time=94.1 ms
64 bytes from 192.168.111.54: icmp_seq=26 ttl=64 time=420 ms
64 bytes from 192.168.111.54: icmp_seq=27 ttl=64 time=447 ms
64 bytes from 192.168.111.54: icmp_seq=28 ttl=64 time=469 ms
64 bytes from 192.168.111.54: icmp_seq=29 ttl=64 time=495 ms
64 bytes from 192.168.111.54: icmp_seq=30 ttl=64 time=516 ms
64 bytes from 192.168.111.54: icmp_seq=31 ttl=64 time=24.5 ms
64 bytes from 192.168.111.54: icmp_seq=32 ttl=64 time=355 ms
^C
--- 192.168.111.54 ping statistics ---
81 packets transmitted, 81 received, 0% packet loss, time 80098ms

After switched back to http://www.candelatech.com/downloads/ath10k-9984-10-4/firmware-5-ct-non-commercial.bin" (ath10k were default) and got up to 4500ms and many lost packets.

ant@ubuntu1804:~$ ping 192.168.111.54
64 bytes from 192.168.111.54: icmp_seq=6 ttl=64 time=62.5 ms
64 bytes from 192.168.111.54: icmp_seq=7 ttl=64 time=1.20 ms
64 bytes from 192.168.111.54: icmp_seq=8 ttl=64 time=2.03 ms
64 bytes from 192.168.111.54: icmp_seq=9 ttl=64 time=30.3 ms
64 bytes from 192.168.111.54: icmp_seq=10 ttl=64 time=1456 ms
64 bytes from 192.168.111.54: icmp_seq=11 ttl=64 time=437 ms
64 bytes from 192.168.111.54: icmp_seq=12 ttl=64 time=182 ms
64 bytes from 192.168.111.54: icmp_seq=13 ttl=64 time=2449 ms
64 bytes from 192.168.111.54: icmp_seq=14 ttl=64 time=1441 ms
64 bytes from 192.168.111.54: icmp_seq=15 ttl=64 time=418 ms
64 bytes from 192.168.111.54: icmp_seq=22 ttl=64 time=3460 ms
64 bytes from 192.168.111.54: icmp_seq=23 ttl=64 time=2437 ms
64 bytes from 192.168.111.54: icmp_seq=24 ttl=64 time=1413 ms
64 bytes from 192.168.111.54: icmp_seq=25 ttl=64 time=389 ms
64 bytes from 192.168.111.54: icmp_seq=26 ttl=64 time=22.9 ms
64 bytes from 192.168.111.54: icmp_seq=27 ttl=64 time=53.9 ms
64 bytes from 192.168.111.54: icmp_seq=34 ttl=64 time=2804 ms
64 bytes from 192.168.111.54: icmp_seq=35 ttl=64 time=1780 ms
64 bytes from 192.168.111.54: icmp_seq=36 ttl=64 time=756 ms
64 bytes from 192.168.111.54: icmp_seq=37 ttl=64 time=3.29 ms
64 bytes from 192.168.111.54: icmp_seq=41 ttl=64 time=4389 ms
64 bytes from 192.168.111.54: icmp_seq=42 ttl=64 time=3365 ms
64 bytes from 192.168.111.54: icmp_seq=43 ttl=64 time=2342 ms
64 bytes from 192.168.111.54: icmp_seq=44 ttl=64 time=1322 ms
64 bytes from 192.168.111.54: icmp_seq=45 ttl=64 time=298 ms
^C
--- 192.168.111.54 ping statistics ---
50 packets transmitted, 25 received, +3 errors, 50% packet loss, time 49822ms
rtt min/avg/max/mdev = 1.206/1252.958/4389.891/1279.999 ms, pipe 5

ant@ubuntu1804:~$ uname -a
Linux ubuntu1804 4.16.15 #1 SMP Thu Jun 14 14:21:36 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux

config.txt

from ath10k-ct.

greearb avatar greearb commented on September 27, 2024

Maybe try disabling power-save?

And, it sounds like this is different from the original bug you opened, so maybe you should open a new bug so the issue can be tracked properly?

from ath10k-ct.

master8282 avatar master8282 commented on September 27, 2024

Hello Ben,
Yes, I agree about creating the separated bug regarding high ping. But tell me please, where, in which place you develop CT firmware, if I understand correct, the current place for discussing ath10k-ct driver but not firmware, I suppose here is wrong place.
Btw "disabling power-save" doesn't help, I tried all CT non-commercial firmwares since the earliest ver supported QCA9984 hardware, and all of then have same issue for me, stock firmware diesn't.

from ath10k-ct.

greearb avatar greearb commented on September 27, 2024

The ath10k-ct github project tracks bugs for both the ath10k-ct driver and firmware. Please open a new bug to track the ping time issue.

from ath10k-ct.

greearb avatar greearb commented on September 27, 2024

With regard to the 'commercial' firmware having issues, the dmesg you attached has a kernel splat, but it seems to be missing a few lines that would tell why and where it crashed:

[ 87.947073] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready

Normally right here there would be some BUG or WARNING text.

intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc ath10k_pci(OE) ath10k_core(OE) snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic aesni_intel snd_hda_intel ath aes_x86_64 crypto_simd glue_helper cryptd mac80211 snd_hda_codec cfg80211 snd_hda_core intel_cstate snd_hwdep snd_pcm joydev nuvoton_cir intel_rapl_perf input_leds snd_timer rc_core mei_me mei shpchp lpc_ich mac_hid snd soundcore sch_fq_codel ip_tables x_tables autofs4 hid_logitech_hidpp i915 i2c_algo_bit drm_kms_helper hid_logitech_dj hid_generic syscopyarea sysfillrect sysimgblt ahci
[ 88.276460] usbhid libahci fb_sys_fops e1000e hid drm video
[ 88.276476] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G OE 4.16.15 #1
[ 88.276479] Hardware name: /D34010WYB, BIOS WYLPT10H.86A.0026.2014.0514.1714 05/14/2014
[ 88.276500] RIP: 0010:ath10k_wmi_event_vdev_start_resp+0x89/0xa0 [ath10k_core]
[ 88.276502] RSP: 0018:ffff974c1fb83cd0 EFLAGS: 00010202
....

Can you reproduce this and see if you can capture the BUG or WARNING part of this splat?
Maybe your kernel needs to be compiled with verbose BUG support, or something like that?

from ath10k-ct.

master8282 avatar master8282 commented on September 27, 2024

Sure, will try to do it tomorrow.

from ath10k-ct.

master8282 avatar master8282 commented on September 27, 2024

Hi Ben,

I added "debug=8" in the kernel boot params and made new dumps, looks like the outputs are still not enough detailed but I hope it will help you Ben.

# cat /proc/sys/kernel/printk
8 4 1 7

dmesg_dbg_full-com.txt
dmesg_dbg_noncom.txt

And one more dmesg:
root@ubuntu1804:~# cat /sys/kernel/debug/ieee80211/phy0/ath10k/debug_level | grep level
Current debug level: 0xc0000032
dmesg_c0000032.txt

Unfortunately I don't see any crash_dump:
root@ubuntu1804:~# ls -la /sys/kernel/debug/ieee80211/phy0/ath10k/
total 0
drwxr-xr-x 2 root root 0 Jun 20 20:13 .
drwxr-xr-x 6 root root 0 Jun 20 20:23 ..
-rw------- 1 root root 0 Jun 20 20:13 ani_enable
-r-------- 1 root root 0 Jun 20 20:13 cal_data
-r-------- 1 root root 0 Jun 20 20:13 chip_id
-rw-r--r-- 1 root root 0 Jun 20 20:13 ct_special
-rw------- 1 root root 0 Jun 20 20:16 debug_level
--w------- 1 root root 0 Jun 20 20:13 dfs_block_radar_events
--w------- 1 root root 0 Jun 20 20:13 dfs_simulate_radar
-r-------- 1 root root 0 Jun 20 20:13 dfs_stats
-r-------- 1 root root 0 Jun 20 20:13 firmware_info
-r-------- 1 root root 0 Jun 20 20:13 fw_checksums
-rw------- 1 root root 0 Jun 20 20:13 fw_dbglog
-r-------- 1 root root 0 Jun 20 20:13 fw_regs
-r-------- 1 root root 0 Jun 20 20:13 fw_reset_stats
-r-------- 1 root root 0 Jun 20 20:13 fw_stats
-rw------- 1 root root 0 Jun 20 20:13 htt_max_amsdu_ampdu
-rw------- 1 root root 0 Jun 20 20:13 htt_stats_mask
-rw------- 1 root root 0 Jun 20 20:13 mem_value
-r-------- 1 root root 0 Jun 20 20:13 misc
-rw------- 1 root root 0 Jun 20 20:13 nf_cal_period
-r-------- 1 root root 0 Jun 20 20:13 peers
-rw-r--r-- 1 root root 0 Jun 20 20:13 pktlog_filter
-rw-r--r-- 1 root root 0 Jun 20 20:13 quiet_period
-rw------- 1 root root 0 Jun 20 20:13 reg_addr
-rw------- 1 root root 0 Jun 20 20:13 reg_value
-r-------- 1 root root 0 Jun 20 20:13 rx_reorder_stats
-rw------- 1 root root 0 Jun 20 20:13 set_rates
-rw------- 1 root root 0 Jun 20 20:13 simulate_fw_crash
-rw------- 1 root root 0 Jun 20 20:13 spectral_bins
-rw------- 1 root root 0 Jun 20 20:13 spectral_count
-r-------- 1 root root 0 Jun 20 20:13 spectral_scan0
-rw------- 1 root root 0 Jun 20 20:13 spectral_scan_ctl
-rw-r--r-- 1 root root 0 Jun 20 20:13 thresh62_ext
-r-------- 1 root root 0 Jun 20 20:13 tpc_stats
-r-------- 1 root root 0 Jun 20 20:13 wmi_services

Thank you,
Alex

from ath10k-ct.

greearb avatar greearb commented on September 27, 2024

Sorry for the late response. That dmesg_c0000032.txt has good debugging. The kernel splat is because of a warning, vdev create didn't work properly for some reason. The firmware logs appear to be missing some vdev create logs I'd expect to see. I also fixed the driver to print out some better info in case the vdev create fails like it did in your case. Can you re-test this with recent firmware and driver and let me know if the problem still exists? Please generate logs how you did for the dmesg_c0000032.txt file.

from ath10k-ct.

greearb avatar greearb commented on September 27, 2024

Closing this bug, OpenWRT has newer firmware and driver in it now, please re-open a new bug if problems persist.

from ath10k-ct.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.