I believe it's not the cause of your issue, I believe those clocks are running at nominal rate of 400mhz when are not scaled by any driver and that should be enough for normal operation.
Have you tried limiting krait minimal freq to 800 MHz, so at least l2 cache wouldn't fail?
Anyway I think it's more like a bug that triggers your hangs that maybe caused by race condition that is not being taken care of?
Yes, I did that. It didn't help. The router still randomly reboots when the NSS core clocks are scaled. The only way to make the router stable is to force the scaling to stop, i.e. make the NSS core run at a fixed core frequency. My R7800 has been up more than a week without any apparent issue 
with the NSS cores accelerating routing tasks.
1 Like
Well, it worked this time: https://gist.github.com/fantom-x/379d158f5395dacf78e07955f593192c. I only had to change three lines in @dissent1'1 patch, but I remember that I had way more issues trying this before; very weird.
There are four patches in there that need to be applied in order to 19.07. When the build applies the changes, it is not 100% clean but it works. The router booted fine just a few minutes ago.
krait_l2_pri_mux/clk_rate == 1200000000 did not change, but maybe because the router was already running with the performance governor. regulator_summary values did change as per Netgear R7800 exploration (IPQ8065, QCA9984).
regulator_summary (before)
cat /sys/kernel/debug/regulator/regulator_summary
regulator use open bypass voltage current min max
-------------------------------------------------------------------------------
regulator-dummy 0 10 0 0mV 0mA 0mV 0mV
1b700000.pci 0mV 0mV
1b700000.pci 0mV 0mV
1b700000.pci 0mV 0mV
1b500000.pci 0mV 0mV
1b500000.pci 0mV 0mV
1b500000.pci 0mV 0mV
s1a 0 0 0 1050mV 0mA 1050mV 1150mV
s1b 0 0 0 1050mV 0mA 1050mV 1150mV
s2a 0 1 0 1150mV 0mA 775mV 1275mV
cpu0 1150mV 1207mV
s2b 0 1 0 1150mV 0mA 775mV 1275mV
cpu1 1150mV 1207mV
SDCC Power 0 0 0 3300mV 0mA 3300mV 3300mV
regulator_summary (after)
cat /sys/kernel/debug/regulator/regulator_summary
regulator use open bypass voltage current min max
-------------------------------------------------------------------------------
regulator-dummy 0 10 0 0mV 0mA 0mV 0mV
1b700000.pci 0mV 0mV
1b700000.pci 0mV 0mV
1b700000.pci 0mV 0mV
1b500000.pci 0mV 0mV
1b500000.pci 0mV 0mV
1b500000.pci 0mV 0mV
s1a 0 2 0 1150mV 0mA 1050mV 1150mV
cpu1 1150mV 1150mV
cpu0 1150mV 1150mV
s1b 0 0 0 1050mV 0mA 1050mV 1150mV
s2a 0 1 0 1150mV 0mA 775mV 1275mV
cpu0 1150mV 1207mV
s2b 0 1 0 1150mV 0mA 775mV 1275mV
cpu1 1150mV 1207mV
SDCC Power 0 0 0 3300mV 0mA 3300mV 3300mV
2 Likes
If krait_l2_pri_mux is the L2 cache then what is krait_l2_sec_mux ?
Has anybody else noticed recently stability problem with master?
Possibly only with the ath10k driver (not -ct)...
I did yesterday a build and the router crashed quickly if wifi was active. I reverted quickly to a week-old -ct build, which is stable. (r10506-cbae306)
I did not have time to do further test builds, but I wonder if there have been generic changes (like the mac80211 version bump 4 days ago) that might play havoc with regular ath10k. There aren't that many relevant looking commits since the week-old state.
I've seen a similar behaviour with the mac80211 bump and ath10k (firmware ver 10.4-3.10-00047) on my nbg6817, but I was testing kernel 4.19 with USB patches and several other relatively experimental changes:
daemon.info hostapd: wlan1: STA 84:38:38:xx:xx:xx IEEE 802.11: authenticated
daemon.info hostapd: wlan1: STA 84:38:38:xx:xx:xx IEEE 802.11: associated (aid 1)
kern.alert kernel: [ 692.349965] Unable to handle kernel paging request at virtual address fffff9e8
kern.alert kernel: [ 692.349997] pgd = 6552583d
kern.alert kernel: [ 692.356160] [fffff9e8] *pgd=5fffd861, *pte=00000000, *ppte=00000000
kern.emerg kernel: [ 692.358863] Internal error: Oops: 37 [#1] SMP ARM
kern.warn kernel: [ 692.364928] Modules linked in: pppoe ppp_async iptable_nat ipt_MASQUERADE ath10k_pci ath10k_core ath xt_state xt_nat xt_conntrack xt_REDIRECT xt_FLOWOFFLOAD xt_CT pppox ppp_generic nf_nat_ipv4 nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack_netlink nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_policy xt_multiport xt_mark xt_mac xt_limit xt_esp xt_comment xt_TCPMSS xt_LOG usblp slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ipt_ah ip_tables crc_ccitt compat configs xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port
kern.warn kernel: [ 692.417868] ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 sit xfrm6_mode_tunnel xfrm6_mode_transport xfrm6_mode_beet ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet ipcomp esp4 ah4 tunnel6 tunnel4 ip_tunnel xfrm_user xfrm_ipcomp af_key xfrm_algo vfat fat autofs4 nls_utf8 nls_iso8859_1 nls_cp437 sha1_generic md5 echainiv authenc uas usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom ohci_platform ohci_hcd ahci ehci_platform sd_mod ahci_platform libahci_platform libahci libata scsi_mod ehci_hcd gpio_button_hotplug f2fs ext4 mbcache jbd2 crc32c_generic crc32_generic
kern.warn kernel: [ 692.483498] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.59 #0
kern.warn kernel: [ 692.505727] Hardware name: Generic DT based system
kern.warn kernel: [ 692.512079] PC is at ieee80211_sta_register_airtime+0x24/0x148 [mac80211]
kern.warn kernel: [ 692.516646] LR is at ath10k_htt_t2h_msg_handler+0x668/0x1114 [ath10k_core]
kern.warn kernel: [ 692.523437] pc : [<bf58804c>] lr : [<bf6d3844>] psr: a0000113
kern.warn kernel: [ 692.530207] sp : c0b01d44 ip : 00000002 fp : bf6fed54
kern.warn kernel: [ 692.536369] r10: 00000034 r9 : d876a180 r8 : 00060002
kern.warn kernel: [ 692.541577] r7 : 00000000 r6 : d737d650 r5 : 00000000 r4 : d8769600
kern.warn kernel: [ 692.546788] r3 : 00000000 r2 : 00060002 r1 : 00000000 r0 : 00000000
kern.warn kernel: [ 692.553387] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
kern.warn kernel: [ 692.559896] Control: 10c5787d Table: 579bc06a DAC: 00000051
kern.emerg kernel: [ 692.567100] Process swapper/0 (pid: 0, stack limit = 0xa4e93fc3)
kern.emerg kernel: [ 692.572831] Stack: (0xc0b01d44 to 0xc0b02000)
kern.emerg kernel: [ 692.578916] 1d40: d8769600 00000000 d737d650 00000001 d737d650 d876a180 00000034
kern.emerg kernel: [ 692.583176] 1d60: bf6fed54 bf6d3844 00000002 c0314b50 d8769cb0 00000001 00000001 d737d64c
kern.emerg kernel: [ 692.591335] 1d80: 00010000 00000000 d876d7fc bf724430 c0310d84 d9d48300 d8769600 00000000
kern.emerg kernel: [ 692.599496] 1da0: c0b01dc0 c08454c4 d876d7fc 00000001 00000022 bf720368 d9d48300 00000022
In other words, the first connecting wireless client resulted in that Oops and triggered a reboot.
The same (experimental) patch set has been working with the previous v4.19 based mac80211 backports for the last 4 days.
@hauke
Any idea why the new mac80211 version might trigger oops with the old regular ath10k (not -ct) ?
I think the following belongs in this thread, if not I can split it elsewhere. This may be of interest to some users.
Enabling VHT80P80 on the R7800.
Apply the following patch (note that this patch is handwritten from my own notes, so may not apply cleanly. i'm still formalising a patch to incorporate into my build environment):
--- a/lib/netifd/wireless/mac80211.sh
+++ b/lib/netifd/wireless/mac80211.sh
@@ -49,6 +49,7 @@ drv_mac80211_init_device_config() {
short_gi_40 \
max_amsdu \
dsss_cck_40
+ config_add_string channel2
}
drv_mac80211_init_iface_config() {
@@ -96,7 +97,7 @@ mac80211_hostapd_setup_base() {
[ "$auto_channel" -gt 0 ] && channel=acs_survey
[ "$auto_channel" -gt 0 ] && json_get_values channel_list channels
- json_get_vars noscan ht_coex
+ json_get_vars noscan ht_coex channel2
json_get_values ht_capab_list ht_capab
ieee80211n=1
ht_capab=
case "$htmode" in
VHT20|HT20) ;;
- HT40*|VHT40|VHT80|VHT160)
+ HT40*|VHT40|VHT80|VHT160|VHT80P80)
case "$hwmode" in
a)
case "$(( ($channel / 4) % 2 ))" in
@@ -174,6 +175,7 @@
# 802.11ac
enable_ac=0
idx="$channel"
+ idx2="$channel2"
case "$htmode" in
VHT20) enable_ac=1;;
VHT40)
@@ -204,6 +206,24 @@
append base_cfg "vht_oper_chwidth=2" "$N"
append base_cfg "vht_oper_centr_freq_seg0_idx=$idx" "$N"
;;
+ VHT80P80)
+ case "$(( ($channel / 4) % 4 ))" in
+ 1) idx=$(($channel + 6));;
+ 2) idx=$(($channel + 2));;
+ 3) idx=$(($channel - 2));;
+ 0) idx=$(($channel - 6));;
+ esac
+ case "$(( ($channel2 / 4) % 4 ))" in
+ 1) idx2=$(($channel2 + 6));;
+ 2) idx2=$(($channel2 + 2));;
+ 3) idx2=$(($channel2 - 2));;
+ 0) idx2=$(($channel2 - 6));;
+ esac
+ enable_ac=1
+ append base_cfg "vht_oper_chwidth=3" "$N"
+ append base_cfg "vht_oper_centr_freq_seg0_idx=$idx" "$N"
+ append base_cfg "vht_oper_centr_freq_seg1_idx=$idx2" "$N"
+ ;;
esac
if [ "$enable_ac" != "0" ]; then
Apply the following (or similar) settings in /etc/config/wireless/:
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11a'
option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option channel '36'
option channel2 '149'
option htmode 'VHT80P80'
Fully restart netifd so it picks up the new config items /etc/init.d/network restart, and it should fire up.
Not many channel scanners understand VHT80P80 so i had to rely on my own.
This patch would need to be cleaned up and thought through a bit more carefully to be included upstream, but will become more useful when we have HE80P80 capability in future routers (probably ath11k).
I've only tried this with kmod-ath10k-ct and the associated ct firmware so far.
3 Likes
What is 80p80
160MHz bandwidth on two noncontiguous 80MHz channels.
80P80 means 80+80
80 Padding 80
So this will permit 160 MHz on more channel?
Does anyone know how to completely remove the wifi blinking LED code from r7800 build?
ath10k-4.19/mac.c +/blink
include/mac80211/led.h
Do I just delete those two files?
Does this work with DFS? Otherwise it will not be legal to use 80+80 channels in the EU, as you have to use spectrum above channel 48 (DFS only) to create the second 80 MHz channel.
whooooa! hold your horses cowboy 
i don't know much but.......
remove this near the bottom of mac.c ( build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x/ath10k-ct-XYZ-ish )
#ifdef CPTCFG_MAC80211_LEDS
ar->led_default_trigger = ieee80211_create_tpt_led_trigger(ar->hw,
IEEE80211_TPT_LEDTRIG_FL_RADIO, ath10k_tpt_blink,
ARRAY_SIZE(ath10k_tpt_blink));
#endif
or find where to set CPTCFG_MAC80211_LEDS 0
just a guess... tho...
or set .blink_time to 0 in mac.c;
static const struct ieee80211_tpt_blink ath10k_tpt_blink[] = {
{ .throughput = 0 * 1024, .blink_time = 0 },
{ .throughput = 1 * 1024, .blink_time = 0 },
{ .throughput = 2 * 1024, .blink_time = 0 },
{ .throughput = 5 * 1024, .blink_time = 0 },
{ .throughput = 10 * 1024, .blink_time = 0 },
{ .throughput = 25 * 1024, .blink_time = 0 },
{ .throughput = 54 * 1024, .blink_time = 0 },
{ .throughput = 120 * 1024, .blink_time = 0 },
{ .throughput = 265 * 1024, .blink_time = 0 },
{ .throughput = 586 * 1024, .blink_time = 0 },
};
or just disable led support from config menu o.o
2 Likes
I have collapsed @dissent1's PR into a single patch file and have a couple of questions.
-
Multiple CPU frequencies can map to the same l2 frequency, so it makes sense to cache it and avoid calling into
clk_set_rate, which is using locking. The same applies to l2 voltage. What is the right way to cache those variables in this driver: do I need to useper_cpuapproach? -
There was a suggestion above in the thread to set min frequency to 800MHz: is that done in the dts entries like this? I could then remove the last two rows from each entry in qcom-ipq8065.dtsi.
qcom,speed0-pvs0-bin-v0 =
< 1725000000 1262500 >,
< 1400000000 1175000 >,
< 1000000000 1100000 >,
< 800000000 1050000 >,
< 600000000 1000000 >,
< 384000000 975000 >;
- The original PR was not merged with the explanation below. Can anyone provide some hints about what is expected? I read it as I just need to copy the current cpufreq-dt.h/c into cpufreq-dt-ipq806x.h/c an make it a part of the patch. Is that correct?
I noticed that you're hacking a lot of ipq806x specific code into the generic cpufreq-dt driver. I think it would be a lot less messy if you just fork that driver and create an ipq806x specific one instead.
2 Likes
About point 3
You need to create a separate driver and set a dedicated compatible in dts
Can you point me to a sample drive that is done this way?