On 7/1/21 4:55 PM, Shane Synan wrote: > On 6/28/21 2:10 AM, Shane Synan wrote: > [...] > > Given these commits work just fine on the "master" branch, and on > "21.02" it worked to change the CPU governor *without* the DTSI > backports and cache (i.e. only the first commit), I strongly suspect I > goofed up and missed backporting something important.
After further attempts, I still encounter the issue on OpenWRT "master" with Linux kernel 5.4 as well, I just didn't try enough iterations of SFTP upload testing. Disabling 1.4 GHz L2 cache by removing that "opp_table_l2" entry from the .dtsi (git revert'ng "ipq806x: fix missing 1.4ghz cache freq for ipq8065 SoC") *so far* seems more stable. This applies to OpenWRT 21.02 as well if I try backporting the changes: https://github.com/openwrt/openwrt/compare/openwrt-21.02...digitalcircuit:openwrt-21.02-cpufreq-dtsivolt-cache ...versus... https://github.com/openwrt/openwrt/compare/openwrt-21.02...digitalcircuit:openwrt-21.02-cpufreq-dtsivolt-cache-no-1.4ghz (stress-ng currently fails to build from source on the "master" branch, hence trying to narrow it down on 21.02 as well) Unfortunately, I still haven't managed to recreate this issue in a simple manner. I'm continuing to experiment with stress-ng parameters in various loops, scripting GNOME's GIO backend via Python for repeated SFTP uploads, etc, but haven't succeeded yet. I'll continue to explore my options. Would you have any suggestions for how to diagnose this issue at a lower level? I've not gotten any cpufreq-related error messages from the serial console. I've noticed that the cpufreq driver mentions transitions to/from 384 MHz as well, despite having the /etc/init.d/cpufreq changes applied raising scaling_min_freq to 600 MHz - perhaps I'm somehow bypassing the check that tries to avoid the hardware constraint? From : To : 384000 600000 800000 1000000 1400000 1725000 384000: 0 14 3 6 11 9 600000: 15 0 49834 23113 7 106477 800000: 7 64708 0 14301 34 28653 1000000: 10 32739 13774 0 37 24203 1400000: 6 8 21 62 0 17 1725000: 5 81977 44070 33281 25 0 (Source: /sys/devices/system/cpu/cpufreq/policy[0..1]/stats/trans_table) Alternatively, is it possible to adjust the maximum L2 cache frequency at runtime, similar to setting the CPU governor min/max? To be clear, I appreciate your efforts to keep ipq806x alive, especially after Qualcomm had abandoned the platform (I hadn't realize this until someone on #openwrt-devel pointed this out). I don't intend to seem ungrateful. If you'd prefer to consider this bizarrely hard-to-simplify test case unsolvable, that's okay! I can continue to run custom builds with 1.4 GHz L2 cache frequency disabled, and the majority of others without my bizarrely-nondeterministic issues can enjoy the higher speed. Regardless, thank you for your time spent looking into this! I hope my attempts to diagnose this has not caused you any trouble. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
