[quote="burningjoe, post:192, topic:316"]
I have problems compiling your build lede-r4214-822ee54544-20170526.This is part of the log, which contains the error: https://pastebin.com/CUwfk5CsI've followed your instructions for rebuilding your build environment.
Is this an error on my side or is there something wrong in the line?
[/quote]You need to delete that file package/network/config/firewall/patches/100-test.patch
It contained a firewall fix from Jow in early May and that code has now been mainlined to the firewall with the latest firewall3 version bump. So the patch is now unnecessary (as it tries to add source code that already exists)
The patch will get removed from my next build. So, you can also wait a few hours and then download new firmware creation patches that will apply cleanly.
EDIT:
new version without the patch: lede-r4235-61eb18d3f7-20170529
I'm noticing a bunch of problems with the 5GHz radio on r4235. Changing any frequency options will kill the radio entirely, forcing a reboot to bring it back up. I also noticed it has some issues selecting the appropriate frequency on reboot. I had forced channel 36, and it rebooted on 40. I tried forcing 48, and it booted into 48 fine. I then tried 52 and it failed to associated on reboot. Lastly, I tried auto and it also failed to associate. All these tests were done at 80Hz channel width in AC mode. I'm just going to leave it on 36 (40) in the meantime.
Wed May 31 12:08:20 2017 daemon.notice netifd: radio0 (10144): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process 1953 path ()
Wed May 31 12:08:20 2017 daemon.notice netifd: radio0 (10144): Device setup failed: HOSTAPD_START_FAILED
Channel selection depends quite much on the country CRDA settings etc., so it is quite possible that some channels will not work due to DFS restrictions etc.
@chunkeey@hnyman QCA9984
I've done some extensive testing on the 2.4 ghz issue, though I haven't encountered crash like some users, but I have faced very low upstream throughput (from router to client device), tested on 2 different devices:
2.4 ghz:
router to client device - 25-50 mbits/s
client device to router - 100+ mbits/s
For reference on 5ghz I get 500/500 in both directions.
I've tested all firmware branches 10.4-3.2, 10.4-3.3 and 10.4-3.4. I have also tested CT firmware. Ath10k-CT driver constantly produces errors on both bands, so not taking it into account.
I've also extracted board.bin from board-2.bin, tried symlinking the 2.4 ghz cal file to board.bin instead of 5ghz.
Result is the same in all cases.
Also, that crap that is being produced in identification line
Sun Jun 4 03:05:22 2017 kern.err kernel: [ 26.344681] ath10k_pci 0001:01:00.0: failed to fetch board data for bus=pci,vendor=168c,device=0046,subsystem-vendor=168c,subsystem-device=cafeOh???
Sun Jun 4 03:05:22 2017 kern.err kernel: [ 26.344681] m
Sun Jun 4 03:05:22 2017 kern.err kernel: [ 26.344681] ??????,? from ath10k/QCA9984/hw1.0/board-2.bin
happens on all firmwares and board files with current compat-wireless.
So concluding said above the stability and performance issue that concerns 2.4 ghz band is mostly ath10k driver related, but not firmware.
Also, it seems that our device does have OTP to get calibration and identification from, because I've found a lot of mailing lists with various logs from Netgear R7800 on ath10k driver that have OTP working.
Adding to that, there's an upstream patch to get bmi identification working for pre-cal file on QCA99xx https://patchwork.kernel.org/patch/9748097/
But it doesn't work in our case because we have not pre-cal (pure cal), but cal file (pre-cal + board data). So maybe the offset is shifted or it is possible to extract pre-cal from it. @nbd
This commit will probably be in the next compat-wireless refresh. So no need to worry about it.
I can't say much about the bad performance on the 2.4G though.
I was looking for those messages. Do you have a link to the "various logs from Netgear R7800 on ath10k driver that have OTP working"? I can't seem to find anything since most of the OEM bootlogs are not that verbose when it comes to wifi.
Note: The QCA9984 cards from compex/unex/... do have an eeprom.
That's why the BMI Identification is/was working for them, since this was always supported by ath10k in the kernel.
[...]
Each board data is custom for the board layout / part selection - it's
a template that is used during calibration. The data in OTP is just a
diff against the board template (board.bin / board-2.bin.) [...]
If people aren't using unique BMI IDs (which is another question we
have for QCA) then it's possible you don't have enough information to
"know" which board data to use, so it has to be overridden by a custom
package. We do this at work for our own boards as well - they're
sufficiently different to a reference board that indeed we need to "know".
Now, the reason for pre-loading the calibration data is because it's
needed early in the boot process so the firmware/driver has some idea
of what the hardware is.
So, the driver steps should be:
If you have a pre-calibration file, you load that in before you kick
the firmware too hard;
then you read the calibration data /back/ - then the normal firmware
process will fetch the board ID;
then it loads the board-2.bin matching the board/BMI ID, then
starts things normally.
Now, I forget if the pre-cal data (and say, data in flash versus data
in OTP) is the whole thing or a diff against the board data. I'd have
to triple-check. The OTP data is certainly just a diff against the
board data.
[...]
Build contains wifi firmware calibration fixes, as the ath10k wifi driver is patched to properly read the router-specific board data from flash. Details:
It is not clear from there discussions or the commit description what issue this change fixes. Any chance you can help and describe it in a few sentences?
It fixes the detection and utilisation of the proper device/radio-specific calibration files that are included in the art/caldata partition on flash.
Earlier the same generic file has been used for both 2.4 and 5 GHz radios, because the ath10k wifi driver has failed to read the correct board info file from the router itself. That has been a kludge to get the radios working.
The patches firstly increase the timeout used in the ID reading (as the reading seems to take slightly over 2 seconds that was the earlier timeout limit), and as as the ID reading now works, the second change is the proper naming of the radio-specific calibration files read from the flash so that 2.4 and 5 GHz radios use separate calibration data.
It is yet uncertain what is the net effect of the changes, but likely the performance of one of the radios improves somewhat.
Ps. note that the discussion started in this thread about two weeks ago, was moved to the exploration thread and finally resulted in the PR. (And the whole thing was initially highlighted in March when adding IPQ4xxx support killed all QCA9XXX radios as the original hack was temporarily removed and a new hack was implemented. discussion from Netgear R7800 exploration (IPQ8065, QCA9984) onward)
@tetsuo55
Like yourself, I've been experiencing random ath10k crashes since I started using LEDE with the R7800. I have two of these installed in different buildings and it's usually the 2.4GHz SSID that disappears. Sometimes once a day, sometimes once a week. I've tried countless combinations of countries and channels without improvement. I've tried the last few hnyman builds.
Do you know of a particular build that you have used that does not exhibit these crashes?
That sounds more like a bug in the ath10k driver than a purely R7800 related problem. I have not encountered that myself, but I have rather modest wireless usage.
It could be due to the ath10k buffer size reduction commit by @chunkeey that @dissent1 has tested reverting in his build, but intuitively I think that the "corruption" points more to an actual bug in ath10k than just buffer exhaustion.
I think @hnyman may consider including it in his newer builds? Those buffer sizes has been set for a reason obviously and I'm not sure it's a good catch to decrease it.
There are not much updates concerning R7800 so not sure you need the bleeding edge version if you don't experience any other issues, because you won't notice changes.
