The serial headers pin is already flashed... You just need to open it
Just open the cover and attach the serial cable to pins, like I describe in the message 2 of this thread...
yeah, i don't want to pry it open :).
Opening five screws is no "hardware mod"...
2 Likes
If someone wants to help
This is the repo... All done except... it doesn't work (ah ah ah)
OPP for some reason doesn't register named operating point...
I have little time this 2 week so if anyone wants to take a look i would really appreciate it.
I'm using kernel 4.19 with my R7800 for 3 weeks now and it's rock solid. Actually, it seems more stable than previous versions.
I've got users reporting reproducible crashes on 18.06.5 builds when doing 1 of 2 things:
- use anydesk(http://www.anydesk.com) to remote control PCs. after enable the option "Search local network for other anydesk clients" and then use it to connect to another PC within local network, router reboot.
- when use Edge to browse this website: https://www.retailmenot.com/view/aliexpress.com,
and then click any link of "get deal" or "show coupon code", router reboot
Anyone else seeing this? 2 users exact same problem and 100% reproducible apparently.
These are very strange crash conditions...
PS. Not a spam post. Links are explanatory, not advertisement.
First guess here is the jumboframe bug, which possibly goes away with kernel 4.19
No idea about the other cause.
1 Like
I think I've seen my wifi go down during usage of NoMachine.
1 Like
Good news i actually made the upstream patch work...
ipq806x now set cpufreq based on opp table
This is result with new cpufreq implementation + fixed l2 cache scaling
root@No-Lag-Router:~# ./mbw 32
Long uses 4 bytes. Allocating 2*8388608 elements = 67108864 bytes of memory.
Using 262144 bytes as blocks for memcpy block copy test.
Getting down to business... Doing 10 runs per test.
0 Method: MEMCPY Elapsed: 0.04349 MiB: 32.00000 Copy: 735.801 MiB/s
1 Method: MEMCPY Elapsed: 0.04416 MiB: 32.00000 Copy: 724.588 MiB/s
2 Method: MEMCPY Elapsed: 0.04369 MiB: 32.00000 Copy: 732.500 MiB/s
3 Method: MEMCPY Elapsed: 0.04289 MiB: 32.00000 Copy: 746.129 MiB/s
4 Method: MEMCPY Elapsed: 0.07459 MiB: 32.00000 Copy: 429.023 MiB/s
5 Method: MEMCPY Elapsed: 0.04818 MiB: 32.00000 Copy: 664.162 MiB/s
6 Method: MEMCPY Elapsed: 0.04235 MiB: 32.00000 Copy: 755.537 MiB/s
7 Method: MEMCPY Elapsed: 0.04283 MiB: 32.00000 Copy: 747.122 MiB/s
8 Method: MEMCPY Elapsed: 0.04273 MiB: 32.00000 Copy: 748.818 MiB/s
9 Method: MEMCPY Elapsed: 0.04242 MiB: 32.00000 Copy: 754.361 MiB/s
AVG Method: MEMCPY Elapsed: 0.04673 MiB: 32.00000 Copy: 684.734 MiB/s
0 Method: DUMB Elapsed: 0.20119 MiB: 32.00000 Copy: 159.053 MiB/s
1 Method: DUMB Elapsed: 0.18564 MiB: 32.00000 Copy: 172.379 MiB/s
2 Method: DUMB Elapsed: 0.20574 MiB: 32.00000 Copy: 155.537 MiB/s
3 Method: DUMB Elapsed: 0.20623 MiB: 32.00000 Copy: 155.167 MiB/s
4 Method: DUMB Elapsed: 0.20143 MiB: 32.00000 Copy: 158.866 MiB/s
5 Method: DUMB Elapsed: 0.18646 MiB: 32.00000 Copy: 171.615 MiB/s
6 Method: DUMB Elapsed: 0.18629 MiB: 32.00000 Copy: 171.773 MiB/s
7 Method: DUMB Elapsed: 0.18545 MiB: 32.00000 Copy: 172.557 MiB/s
8 Method: DUMB Elapsed: 0.18772 MiB: 32.00000 Copy: 170.468 MiB/s
9 Method: DUMB Elapsed: 0.22590 MiB: 32.00000 Copy: 141.658 MiB/s
AVG Method: DUMB Elapsed: 0.19720 MiB: 32.00000 Copy: 162.269 MiB/s
0 Method: MCBLOCK Elapsed: 0.04279 MiB: 32.00000 Copy: 747.891 MiB/s
1 Method: MCBLOCK Elapsed: 0.07292 MiB: 32.00000 Copy: 438.813 MiB/s
2 Method: MCBLOCK Elapsed: 0.04952 MiB: 32.00000 Copy: 646.138 MiB/s
3 Method: MCBLOCK Elapsed: 0.04250 MiB: 32.00000 Copy: 752.994 MiB/s
4 Method: MCBLOCK Elapsed: 0.04339 MiB: 32.00000 Copy: 737.514 MiB/s
5 Method: MCBLOCK Elapsed: 0.04398 MiB: 32.00000 Copy: 727.570 MiB/s
6 Method: MCBLOCK Elapsed: 0.04353 MiB: 32.00000 Copy: 735.210 MiB/s
7 Method: MCBLOCK Elapsed: 0.04596 MiB: 32.00000 Copy: 696.273 MiB/s
8 Method: MCBLOCK Elapsed: 0.04529 MiB: 32.00000 Copy: 706.511 MiB/s
9 Method: MCBLOCK Elapsed: 0.04478 MiB: 32.00000 Copy: 714.525 MiB/s
AVG Method: MCBLOCK Elapsed: 0.04747 MiB: 32.00000 Copy: 674.158 MiB/s
Here the repo
Here difference
Here the patchset if someone wants to try (this is applied on kernel 4.19)
https://github.com/Ansuel/openwrt/compare/3bbe9263c5479aef97e67690a222cbe74ac8a78c...2f87b4aab95b8cde5b27d591cc3815cc750d7abe.patch
4 Likes
Your approach there with "compatible" seems to revert the opposite action in the 4.19 kernel bump thread ???
https://github.com/Ansuel/openwrt/commit/6e378caf187c1188d33dcf1cbd56cf9ecfbc86f6
practically reverts
https://github.com/openwrt/openwrt/pull/2472/commits/81c47935f2b1263b76aa08db9315e24c9681e2be
????
Yes... Extra compatible definition were useless as no driver needed that.
Now the cpufreq QCOM nvmen check if we are on ipq806x
I don't know if the compatible should be reintroduced or the check in the driver should be removed.
Then your (chunkeey's ?) old commit message is likely wrong, as it implies that it is enough to have them in the dtsi file. Apparently that is not true.
ipq806x: remove redundant compatible
Compatible proprieties are already included with the dtsi.
I feel that it would be better to have them there, like now (before the proposed removal).
2 Likes
Will drop that commit from the pr... Do you know any info about the kernel upgrade?
@Ansuel Hmm, no way to get these into ipx806x 4.19 PR? Do i have to checkout your whole branch to test it?
the patch is based on 4.19 pr (it has changed so i should rebase)
Tell me if you need it...
@shelterx Thx a lot if you test this
Rebased new patch (this can be applied on top of 4.19 pr)
And the diff
(also @hnyman one thing i notice in working on this... we have on every soc the tsense error about calibration not found... leaving out that it's present a memory leak in the driver, very easy to fix will post a patch eventually... I notice that by adding some more debug output, the real error is caused by the driver not finding the calib and calib_backup nvmem definition in the dts and not actually the non presence of the data... will check this but if you have any hint about this...)
Running iperf3 on lan gives me this results (consider i'm on dsa so i don't really know if it's good or bad... just trying to find a way to test the new scaling driver)
ETHERNET
Connecting to host 192.168.3.1, port 5201
[ 5] local 172.25.176.108 port 54242 connected to 192.168.3.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 82.2 MBytes 689 Mbits/sec 113 747 KBytes
[ 5] 1.00-2.00 sec 102 MBytes 860 Mbits/sec 0 837 KBytes
[ 5] 2.00-3.00 sec 88.8 MBytes 745 Mbits/sec 25 665 KBytes
[ 5] 3.00-4.00 sec 95.0 MBytes 797 Mbits/sec 0 766 KBytes
[ 5] 4.00-5.00 sec 87.5 MBytes 734 Mbits/sec 2 638 KBytes
[ 5] 5.00-6.00 sec 101 MBytes 849 Mbits/sec 0 748 KBytes
[ 5] 6.00-7.00 sec 91.2 MBytes 765 Mbits/sec 24 625 KBytes
[ 5] 7.00-8.00 sec 96.2 MBytes 807 Mbits/sec 0 735 KBytes
[ 5] 8.00-9.00 sec 96.2 MBytes 807 Mbits/sec 7 619 KBytes
[ 5] 9.00-10.00 sec 100 MBytes 839 Mbits/sec 0 731 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 941 MBytes 789 Mbits/sec 171 sender
[ 5] 0.00-10.03 sec 938 MBytes 784 Mbits/sec receiver
WIFI
Connecting to host 192.168.3.1, port 5201
[ 5] local 172.25.176.108 port 54246 connected to 192.168.3.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 62.7 MBytes 526 Mbits/sec 0 1.89 MBytes
[ 5] 1.00-2.00 sec 76.2 MBytes 640 Mbits/sec 0 1.89 MBytes
[ 5] 2.00-3.00 sec 76.2 MBytes 640 Mbits/sec 0 1.89 MBytes
[ 5] 3.00-4.00 sec 77.5 MBytes 650 Mbits/sec 0 1.89 MBytes
[ 5] 4.00-5.00 sec 68.8 MBytes 577 Mbits/sec 0 1.89 MBytes
[ 5] 5.00-6.00 sec 76.2 MBytes 640 Mbits/sec 0 1.89 MBytes
[ 5] 6.00-7.00 sec 78.8 MBytes 661 Mbits/sec 0 1.89 MBytes
[ 5] 7.00-8.00 sec 77.5 MBytes 648 Mbits/sec 0 1.89 MBytes
[ 5] 8.00-9.00 sec 71.2 MBytes 600 Mbits/sec 0 1.89 MBytes
[ 5] 9.00-10.00 sec 80.0 MBytes 671 Mbits/sec 0 1.89 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 745 MBytes 625 Mbits/sec 0 sender
[ 5] 0.00-10.04 sec 743 MBytes 621 Mbits/sec receiver
root@No-Lag-Router:~# hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 1038 MB in 2.00 seconds = 518.90 MB/sec
Timing buffered disk reads: 228 MB in 3.02 seconds = 75.58 MB/sec
root@No-Lag-Router:~# hdparm -Tt /dev/sdb
/dev/sdb:
Timing cached reads: 986 MB in 2.00 seconds = 492.82 MB/sec
Timing buffered disk reads: 250 MB in 3.04 seconds = 82.27 MB/sec
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
md5 28158.06k 74130.37k 140334.83k 185450.91k 201789.58k 202048.83k
sha1 30199.61k 82036.07k 164307.68k 228203.15k 252696.82k 248485.09k
des cbc 25516.76k 26036.89k 27572.78k 27337.64k 27249.47k 27317.70k
des ede3 9582.95k 9580.80k 9878.24k 9925.49k 9746.81k 9736.30k
aes-128 cbc 62906.31k 73967.35k 81997.59k 83121.98k 82204.21k 81953.55k
aes-192 cbc 56818.02k 66076.54k 71498.42k 70954.90k 70173.51k 70842.87k
aes-256 cbc 52285.88k 57680.59k 61240.86k 61747.55k 62830.41k 60788.55k
sha256 20554.81k 51534.91k 96373.03k 124708.62k 137474.10k 131594.07k
sha512 7381.45k 30574.55k 46215.69k 65184.31k 73468.87k 72961.92k
sign verify sign/s verify/s
rsa 2048 bits 0.006712s 0.000160s 149.0 6253.9
sign verify sign/s verify/s
dsa 2048 bits 0.002066s 0.001764s 483.9 567.0
(I'm seeing everywere that setting the minium scaling to 800 mhz improves performance... think it's all related to the cache bug, fixed in the patchset)
Hmm much slower here... also i get
# echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
-ash: can't create /sys/devices/system/cpu/cpufreq/policy0/scaling_governor: nonexistent directory
# echo performance > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
-ash: can't create /sys/devices/system/cpu/cpufreq/policy1/scaling_governor: nonexistent directory
Give me a logread pls
(you probably don't have cpu scaling at all if that command doesn't work, on my side it does so i think i just lost some file)
Seems like cpufreq support for Qualcom was not enabled in the config for some reason? I enabled it and now and the mbw results are the same as in the R7800 cache scaling issue thread before this patch.
yes this was missing
CONFIG_ARM_QCOM_CPUFREQ_NVMEM=y