Yes, seems that's the reason 
at least when I've switched to QSDK variant the issue is gone.
can you link me the variant?
i tried to completely remove that patch but no luck... same problem (lower download speed actually)
am i wrong or here we have more patches than the lede repo ?
if you want i can test them... 
Yes, please, it's enough to test and verify if it fixes the issue, there are just more fixes in qsdk to port
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