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/
I'm running the latest build on the R7800. I have a question about DHCP relay. I have two R7800, Router A is the DHCP server for my network and connects to my cable modem, Router B connects to just one wired host and one wifi host (GamingPC and TPCast for the HTC Vive VR HMD). The problem is I can't get Router B to relay DHCP from Router A for those two hosts. I've tried just about everything in the GUI. I'm wondering if this is a bug in the current build or I'm just missing something.
I ran this exact scenario sucessfully with a slightly different configuration of routers before (DIR-825 with DD-WRT as DHCP server, two Apple Time Capsules in bridge mode relayed DHCP from the DIR-825 quite well). Perhaps a simple way to enable a similar bridge mode would be valuable, I feel like it is a common use.
@hnyman @dissent1
I am currently running with cryptodev enabled and have improved openssl speed results for >16 byte blocks. Have you considered enabling this?
openssl speed -evp aes-256-cbc
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 21947.35k 75799.47k 268364.80k 557521.45k 1527808.00k
openssl speed aes-256-cbc
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256 cbc 49579.51k 57541.38k 58771.24k 60522.57k 58253.92k
Secondly I have been looking at the PVS table for ipq8065 to try and undervolt the router. I've simply copied the values for PVS bin 6 to 4 and compiled Is there any way to verify the voltages and what is applied?
Using 4.9 kernel