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...
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...
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
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
1 Like
@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
1 Like
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
I made a test build of my community build for R7800 with this patch.
lede-r5442-b0b289ea45-20171202-pcie-0071-fix-test
1 Like
Interesting enough is that those patches were hanging in my tree before 0071 was introduced
what about my flashin problem? is it normal that syuppgrade doesn't flash new kernel ?
It's either smth wrong with your build environment or preserved config
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.
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
Luckily it's not new, it's the same as in k4.9 but moved from ../host with the addition of ipq8074 support 
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
I've had more, some are still sitting there, but this time I suppose it's different
@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
@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?
Are you sure that it's related? I mean that it wasn't this way before applying those patches?
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?
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/