Not according to the code, but I've never tested it in practice.
rrdtool: Keep time as 'long' despite 64bit time_t in musl
openwrt:master
← hnyman:rrd2
Adjust to the 64 bit time_t in musl 1.2.2 by keeping time internally in RRD stil…
Not according to the code, but I've never tested it in practice.
Please note
openwrt:master
← hnyman:rrd2
Adjust to the 64 bit time_t in musl 1.2.2 by keeping time internally in RRD stil…
It is possible that we revert back to the 32bit time in RRD in 32bit targets.
It is possible that we revert back to the 32bit time in RRD in 32bit targets.
Ok noted.
While not the end of the world if losing historical stats, assuming process works backward as well, meaning xml dump in 64bit and restore in 32bit system?
Sure, it should work.
Personally I restored my old 32bit database from Sept 24, and lost the data of the two recent weeks. Easiest and good enough for me.
Good, main point is learning something new (like converting successfully rrd database).
master-r17693-c2222f74c8-20211008
The newest build is again using the old 32bit time_t in 32bit targets (like ipq806x).
Not sure yet, which RRD time variant will remain, but likely this 32bit side.
EDIT:
As of master-r17739-81d694e30b-20211010, the fix to go with the 32bit "long" time has been selected.
Is there any point in me upgrading
Possibly the recent wifi VHT160 fix that I included into my build a week ago, is probably the only real reason.
There has also been the bump to kernel 5.10, but that did not bring much new by itself. (The forthcoming DSA switch wil lthen change more things, but even that will not change anything for the basic router use (without VLANs)).
Thank you hnyman,
your builds are running great for me for several months. i am looking forward to DSA. would it be possible to create a test build DSA + VHT160 fix.
I have already tried DSA. I see with it minimal improvement but it does bring advantages
Based on my tests VHT160 doesn't bring performance gain and is causing flaky connectivity to Apple stuff.
@hnyman
I am running very good version
Firmware Version OpenWrt SNAPSHOT r17520-5ef4608c02 / LuCI Master git-21.226.86205-376af36, Kernel Version 5.10.64
Meanwhile, I am going to install gpiofan control via USB port, that requires 5.10.75-1 - Kernel
(kmod-hwmon-gpiofan - 5.10.75-1 - Kernel module for GPIO controlled FANs)
Please show me your stable build with 5.10.75-1
Again, thank you.
If you want to add kernel modules not provided by this build, you'll have to build it from source together - with or without the modifications of this community build. How to do that has been described in detail, just follow it (you don't have to actually flash your first attempt, but get a feeling about it first). Fortunately this device is rather resilient to failures and has a mature push-button tftp recovery mechanism.
After upgrading to r17842-b428f187f0-20211024, my R7800 2.4Ghz and 5Ghz wifi stopped working and the Luci wireless page shows Generic 802.11bg for both radios. I am using the ath10k drivers and from a bit of research, I came across a patch which seems to address the recent issue https://patchwork.kernel.org/project/linux-wireless/patch/20211020075054.23061-1-kvalo@codeaurora.org/.
This is what I see in my logs:
[ 14.166486] ath10k_pci 0000:01:00.0: assign IRQ: got 43
[ 14.167052] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142)
[ 14.167148] ath10k_pci 0000:01:00.0: enabling bus mastering
[ 14.167732] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 15.140001] ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[ 15.140218] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
[ 15.155530] ath10k_pci 0000:01:00.0: firmware ver 10.4-3.9.0.2-00131 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 23bd9e43
[ 17.426888] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id 0:1 crc32 85498734
[ 21.085387] ath10k_pci 0000:01:00.0: failed to copy target iram contents: -12
[ 21.172940] ath10k_pci 0000:01:00.0: could not init core (-12)
[ 21.173569] ath10k_pci 0000:01:00.0: could not probe fw (-12)
[ 21.178236] ath10k_pci 0001:01:00.0: assign IRQ: got 45
[ 21.179906] ath10k_pci 0001:01:00.0: enabling device (0140 -> 0142)
[ 21.183740] ath10k_pci 0001:01:00.0: enabling bus mastering
[ 21.184702] ath10k_pci 0001:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 21.396114] ath10k_pci 0001:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[ 21.396149] ath10k_pci 0001:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
[ 21.407102] ath10k_pci 0001:01:00.0: firmware ver 10.4-3.9.0.2-00131 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 23bd9e43
[ 23.686963] ath10k_pci 0001:01:00.0: board_file api 2 bmi_id 0:2 crc32 85498734
[ 27.354454] ath10k_pci 0001:01:00.0: failed to copy target iram contents: -12
[ 27.443524] ath10k_pci 0001:01:00.0: could not init core (-12)
[ 27.444154] ath10k_pci 0001:01:00.0: could not probe fw (-12)
After upgrading to r17842-b428f187f0-20211024,
With r17842-b428f187f0-20211024 I have clients connected to both 2.4 and 5 GHz networks, with the default ath10k-ct wifi driver.
I am using the ath10k drivers and from a bit of research, I came across a patch which seems to address the recent issue https://patchwork.kernel.org/project/linux-wireless/patch/20211020075054.23061-1-kvalo@codeaurora.org/
I haven't really looked into the mainline ath10k.
Ps. you might highlight that upstream patch to @hauke who just merged the newest batch of the upstream mac80211 wifi backports. As the fix was apparently accepted by upstream, the fix will trickle down to us at some point.
I made an updated DSA test build, as most of the qca8k switch config has now been merged, and the current PR is mostly about toggling the device DTSs.
Test-DSA-master-r17855-a1939e7e37-20211025
(Based on PR 4036 from @Ansuel . Possible feedback to there...)
owrt2102-r16327-a77ea2f05f-20211026
Equivalent to the soon-to-be-released 21.02.1
The relevant recent 21.02 change is the new ath10k-ct version with the VHT160 fix. It has been officially backported to 21.02 before the maintenance release 21.02.1 was tagged (My previous 21.02 build already contained it.)
(Not applicable to my build with openssl, but the 21.02.1 will also have the wolfssl fix for the Letsencrypt certs.)
@hnyman
Thanks for awesome latest build
I'm getting following error, any help would be highly appreciated
Thu Oct 28 02:55:24 2021 daemon.err nlbwmon[2428]: Netlink receive failure: Out of memory
Thu Oct 28 02:55:24 2021 daemon.err nlbwmon[2428]: Unable to dump conntrack: No buffer space available
Having total 18 buffer size shortage in Logs in 11 hour active time
Heaviest service I've in my opinion is samba v4
As kernel doesn't support light ksmbd
Secondly, is there any chance i can get compatibility of following module in upcoming releases
I am using the ath10k drivers and from a bit of research, I came across a patch which seems to address the recent issue https://patchwork.kernel.org/project/linux-wireless/patch/20211020075054.23061-1-kvalo@codeaurora.org/
The upstream patch for the mainline ath10k got merged a few minutes ago.
See
What is the difference between this build and the one in the wiki?:
Netgear R7800 (Nighthawk X4S AC2600) Netgear R7800 is a dual-core 1.7 GHz AC2600 router based on IPQ8065 SoC and QCA9984 wifi. Router has 512 MB RAM and 128 MB flash (about 80 MB free flash space after installation in 18.06 and later). [R7800] ...
I see you included some additional software to enable similar functionality as the stock firmware. Is there anything else non obvious you have done?
How about reading the very first post of this thread?