Netgear R7800 exploration (IPQ8065, QCA9984)

Ansuel · 2017-12-01T21:38:56.039Z

ok so unfinished but working right?

dissent1 · 2017-12-01T21:42:26.781Z

Ansuel:

ok so unfinished but working right?

Yes, correct

update: I can't believe it if it's true... if this issue is really fixed at last... I don't experience it anymore, I hope it's not a coincidence...

Ansuel · 2017-12-01T22:25:09.334Z

ummm what issue?

rx corruption?
low performance?
msdu?

had rx corruption.... if you want can you share me your image?

ok i find my problem i think... sysupgrade doesn't actually update the kernel! need to flash with tftp...

dissent1 · 2017-12-01T22:37:07.867Z

Low performance (broken frames). All your issues mentioned could have a single cause.

My patch should not apply correctly for you.
Just delete 0071 patch in your tree and pick 0071-1 ... 0071-9 from my tree

Ansuel · 2017-12-01T22:38:20.590Z

already done

@dissent1 YEP CAN CONFIRM!!! ALL FIXED!!!
max speed in 5ghz

anyway i notice now that for this kind of modification we need to flash the image with tftp... as it's something related to the kernel and sysupgrade doesn't upgrade it... (notice it by watching the kernel log that were reporting that the kernel was compiled on 27 november and not today...)

yes... everything works well except for the log spammend with debug thigs (don't know if it's just me or the patch)
luci bug no more present
no crash all works so good

dissent1 · 2017-12-01T23:43:46.609Z

@hnyman
I think we've found the cause and a "fix" for ipq806x wireless regression observed on k4.9
Could you apply the following commit so more ppl can test it?
https://github.com/dissent1/r7800/commit/8d7faff577d7fccd3f0cba589d0637b80357d54d
@nbd @blogic @chunkeey

Ansuel · 2017-12-02T01:02:36.097Z

think we should also push them upstream.... anyway i was right about the 0071 patch... it's just impressive how fixing this solves all the other problems... i mean we have this bug from the introduction of 4.9 and we actually had already a fix

hnyman · 2017-12-02T06:03:05.153Z

dissent1:

I think we’ve found the cause and a “fix” for ipq806x wireless regression observed on k4.9

Could you apply the following commit so more ppl can test it?

I made a test build of my community build for R7800 with this patch.
lede-r5442-b0b289ea45-20171202-pcie-0071-fix-test

Build for Netgear R7800 Community Builds, Projects & Packages

I have built a nice build for Netgear R7800 that offers the basic router functionality plus some useful add-ons, but does not contain too much additional fancy stuff like multimedia. The build is based on the bleeding-edge development main/master branch and the stable 23.05 branch. ("master" has been renamed as "main" in OpenWrt) Current version: Branch Version (branch-revision-commithash-date) main/master (development branch) main-r24930-0c45d2cfc6-20240127 (DSA) stable openwrt-23…

dissent1 · 2017-12-02T08:12:55.063Z

Ansuel:

think we should also push them upstream… anyway i was right about the 0071 patch… it’s just impressive how fixing this solves all the other problems… i mean we have this bug from the introduction of 4.9 and we actually had already a fix

Interesting enough is that those patches were hanging in my tree before 0071 was introduced

Ansuel · 2017-12-02T11:46:20.483Z

what about my flashin problem? is it normal that syuppgrade doesn't flash new kernel ?

dissent1 · 2017-12-02T11:56:04.495Z

It's either smth wrong with your build environment or preserved config

chunkeey · 2017-12-02T18:39:01.930Z

Ansuel:

@dissent1 YEP CAN CONFIRM!!! ALL FIXED!!!

max speed in 5ghz

dissent1:

I think we’ve found the cause and a “fix” for ipq806x wireless regression observed on k4.9

Could you apply the following commit so more ppl can test it?

Ansuel:

think we should also push them upstream… anyway i was right about the 0071 patch… it’s just impressive how fixing this solves all the other problems… i mean we have this bug from the introduction of 4.9 and we actually had already a fix

Well, can you test if the "ring reduction" patch now does impact the performance or not?

As for upstreaming: The real upstream is the linux kernel. But 4.14 comes with a new/another pcie driver.
https://github.com/torvalds/linux/blob/master/drivers/pci/dwc/pcie-qcom.c

The prudent thing to do, would be to check if the fix (which seems to be clock and reset line related?) is also present in the new driver. Note: The pcie driver above has a compatible for the "qcom,ipq8064", I don't know if the IPQ8065's pcie will work as well? (Or was this the problem all along?)

Anyway, I'm sure the proposed patch will be applied to the lede source.git (it would need to be proposed as a PR on github or via mail on the ML). That said, dissent1 doesn't seem to have any luck with the QSDK patches. I remember he has/had one queued for the USB... And it's just sitting on github, right? Maybe the "upstreaming" could be coordinated by the IPQ806x users... i.e. by testing the PRs and posting a tested-by tag like on his PR/Mails.

robimarko · 2017-12-02T18:42:21.280Z

It would be better to send patches via email to patchworks.
That is where all maintainers are active,only some of them are active reviewing github PR-s

dissent1 · 2017-12-02T19:45:07.575Z

chunkeey:

As for upstreaming: The real upstream is the linux kernel. But 4.14 comes with a new/another pcie driver.

Luckily it's not new, it's the same as in k4.9 but moved from ../host with the addition of ipq8074 support

chunkeey:

The prudent thing to do, would be to check if the fix (which seems to be clock and reset line related?) is also present in the new driver. Note: The pcie driver above has a compatible for the “qcom,ipq8064”, I don’t know if the IPQ8065’s pcie will work as well? (Or was this the problem all along?)

It had ipq8064 compatibility string since the beginning but for some reason it lacked and lacks ipq806x specific bits. Luckily qca doesn't differ ipq8065 from ipq8064 on this matter

chunkeey:

That said, dissent1 doesn’t seem to have any luck with the QSDK patches. I remember he has/had one queued for the USB… And it’s just sitting on github, right?

I've had more, some are still sitting there, but this time I suppose it's different

github.com/lede-project/source

ipq806x: fix wireless regression on k4.9, sync with QSDK

lede-project:master ← dissent1:pci-3

opened 06:28PM - 02 Dec 17 UTC

dissent1

+750 -324

In current state there's huge regression on ipq806x target that causes the devic…e to transmit broken/malformed frames that are not corrected/detected by error control mechanisms and other less severe issues. https://bugs.lede-project.org/index.php?do=details&task_id=1197 This finally had been narrowed down to patch 0071-pcie-qcom-fixes.patch Meanwhile QSDK contains a handful of commits that add support for ipq806x to upstream qcom pcie driver https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/log/drivers/pci/host/pcie-qcom.c?h=eggplant Unfortunately qca developers do not bother to push it upstream. Using those commits instead of lede 0071 patch fixes mentioned issue and probably many others as it seems that corrupted data has been originating within pcie misconfiguration. Fixes: FS#1197 and probably others Confirmed by at least 1 more user (besides me). https://forum.lede-project.org/t/netgear-r7800-exploration-ipq8065-qca9984/285/571 Need more testers to confirm that it's not just a coincidence. According to QSDK and OEM tarballs (checked c2600, r7500v2, r7800) 2nd pci slot (pci1, 2,4 GHz card)) on ap148 based boards should operate in gen1 mode. In previous commit we've added the support for this option, so enable it in DT for affected devices. QSDK ref: https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?h=release/endive_preview_cc&id=f3b07fe309027c52fc163149500cedddd707c506

Ansuel · 2017-12-02T23:00:25.643Z

@dissent1 if you have something else to test i'm here

Magnetron1.1 · 2017-12-03T04:07:20.865Z

@dissent1
Sorry for the delay, but I've been testing and using Kong's R7800 DD-WRT builds for nearly 2 months.

For the iperf3 tests, I installed @hnyman build r5442.
My HP Pavilion dv7 laptop iperf3 server is running Ubuntu 16.04 LTS and using an Edimax AC1200 Wi-Fi adapter that is about 3.5 feet from the router.
The router Wi-Fi is set to AC 80 MHz bandwidth, channel 36, security WPA2 PSK, and tx power is 15 milliwatts.

Find the list of TCP congestion algorithms and the default one:

root@R7800RT1:~# sysctl -a 2>/dev/null|grep congestion
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_congestion_control = cubic

Sample iperf3 test using the default 'cubic' algorithm:

root@R7800RT1:~# iperf3 -c 192.168.16.107
Connecting to host 192.168.16.107, port 5201

[  5] local 192.168.16.1 port 51802 connected to 192.168.16.107 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  16.8 MBytes   141 Mbits/sec    0    724 KBytes       
[  5]   1.00-2.00   sec  14.4 MBytes   121 Mbits/sec    0   1.28 MBytes       
[  5]   2.00-3.00   sec  13.7 MBytes   115 Mbits/sec    0   1.68 MBytes       
[  5]   3.00-4.00   sec  17.8 MBytes   149 Mbits/sec    0   1.87 MBytes       
[  5]   4.00-5.00   sec  17.2 MBytes   144 Mbits/sec    0   2.19 MBytes       
[  5]   5.00-6.00   sec  16.6 MBytes   139 Mbits/sec    0   2.30 MBytes       
[  5]   6.00-7.00   sec  16.6 MBytes   140 Mbits/sec    0   2.42 MBytes       
[  5]   7.00-8.00   sec  16.1 MBytes   135 Mbits/sec    0   2.42 MBytes       
[  5]   8.00-9.00   sec  14.2 MBytes   119 Mbits/sec    0   2.42 MBytes       
[  5]   9.00-10.00  sec  16.0 MBytes   135 Mbits/sec    0   2.42 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   159 MBytes   134 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   158 MBytes   132 Mbits/sec                  receiver

iperf Done.

Sample iperf3 test using the 'reno' algorithm:

root@R7800RT1:~# iperf3 -c 192.168.16.107 -C reno
Connecting to host 192.168.16.107, port 5201

[  5] local 192.168.16.1 port 51818 connected to 192.168.16.107 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  18.2 MBytes   152 Mbits/sec    0   2.71 MBytes       
[  5]   1.00-2.00   sec  18.8 MBytes   158 Mbits/sec    0   2.74 MBytes       
[  5]   2.00-3.00   sec  19.9 MBytes   167 Mbits/sec    0   2.74 MBytes       
[  5]   3.00-4.00   sec  18.2 MBytes   152 Mbits/sec    0   2.74 MBytes       
[  5]   4.00-5.00   sec  16.5 MBytes   138 Mbits/sec    0   3.24 MBytes       
[  5]   5.00-6.00   sec  15.7 MBytes   132 Mbits/sec    0   4.69 MBytes       
[  5]   6.00-7.00   sec  18.9 MBytes   158 Mbits/sec    0   4.69 MBytes       
[  5]   7.00-8.00   sec  19.3 MBytes   162 Mbits/sec    0   4.69 MBytes       
[  5]   8.00-9.00   sec  16.5 MBytes   139 Mbits/sec    0   4.69 MBytes       
[  5]   9.00-10.00  sec  18.5 MBytes   155 Mbits/sec    0   4.69 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   180 MBytes   151 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   179 MBytes   150 Mbits/sec                  receiver

iperf Done.

I would say that the packet corruption and performance problems have been solved. Kudos to the Devs.

Magnetron1.1

Ansuel · 2017-12-03T14:22:57.089Z

@dissent1 anyway now i have problem with luci.... it doesn't recognize rx / tx speed in the gui...
and why my device doesn't get 40 mhz?

dissent1 · 2017-12-03T17:27:15.197Z

Are you sure that it's related? I mean that it wasn't this way before applying those patches?

Ansuel · 2017-12-03T17:30:05.217Z

i don't think it's related, it's just another bug... now that we fixed the big one we can move on the small one right?

sdysj · 2017-12-04T04:54:36.862Z

Glad to see WIFI issue being fixed, the next big issue is the stmmac driver that the LAN upload speed still stuck at 20Mbit/s.

Edit: Is someone try the nss-gmac? Some info https://patchwork.ozlabs.org/patch/426866/