Like I said earlier:
Once the aged 17.01.7 build has been finalised, the devs will convert the 17.01 build infra to do 19.07 builds. But currently 19.07 is still only sources, not yet downloadable binaries.
2 Likes
Should we be concerned about these errors?
Thu Jun 27 13:10:17 2019 kern.err kernel: [ 8984.278312] print_req_error: I/O error, dev mtdblock1, sector 0
Thu Jun 27 13:10:17 2019 kern.err kernel: [ 8984.285422] print_req_error: I/O error, dev mtdblock1, sector 8
Thu Jun 27 13:10:17 2019 kern.err kernel: [ 8984.291096] print_req_error: I/O error, dev mtdblock1, sector 16
Thu Jun 27 13:10:17 2019 kern.err kernel: [ 8984.297354] print_req_error: I/O error, dev mtdblock1, sector 24
Thu Jun 27 13:10:17 2019 kern.err kernel: [ 8984.304166] print_req_error: I/O error, dev mtdblock1, sector 0
Thu Jun 27 13:10:17 2019 kern.err kernel: [ 8984.308609] Buffer I/O error on dev mtdblock1, logical block 0, async page read
No. (and there is nothing specific to my build)
Maybe the earlier discussion about that gives you enough answers:
Forum search:
https://forum.openwrt.org/search?q=print_req_error%3A%20I%2FO%20error%2C%20dev%20mtdblock1
Leads to e.g.:
Are I/O errors on mtdblock concerning? - #4 by joaoabs
and
Blk_update_request: I/O errors - #27 by Doppel-D
Leading further via https://openwrt.org/docs/techref/flash to https://bugs.openwrt.org/index.php?do=details&task_id=1871 that contains the detailed explanation:
Reason for closing: Not a bug
Additional comments about closing:The first few blocks of a NAND flash are guaranteed good to ensure that a bootloader stored there can never get corrupted, so it will get written without valid ECC data (the SoC won't check the ECC anyway).
When block-mount scans all block devices, it will try to read from those blocks, which are exposed as partitions, and the NAND driver will report failed ECC checks (the I/O errors in the log).
There is nothing wrong here in either way, and nothing we can really do to prevent it.
1 Like
actually... can't we patch block-mount to skip ecc checks for this blocks ? i mean this error gets pretty annoying if you scan mounted partition periodicaly as it will be reported every time
1 Like
I have not noticed these errors until now on build r10312, but it sounds like they have been there all this time.
they show up as soon as you install block-mount
@hnyman I tried the latest ct build r10312 and unfortunately it still doesn't work well with my clients compared to the "old" builds 
I keep hoping that "ct" improves so I don't have to worry about "old" not being available anymore. At some point I suppose I'll be stuck on the last "old" build you will have made.
Sorry, which package should i install? I see 3 masters, 2 owrt's.
I'm sure latest version is right but not sure about masters vs 1907.
Also i'm coming from R7800 factory img.
I should install the sqfs-factory.img correct? And not the sysupgrade.bin unless upgrading from old version?
I had come from my WNDR3700v4 and a family member disliked i went and flashed custom firmware to his router. Was getting tired of bufferbloat being a main issue with gaming. Couldn't stand it. Thanks
The versions are listed on the message 1.
There are two different WiFi versions for the bleeding edge development master, one new 19.07 version with warning, and one stable 18.06 version. If you are unsure, use the newest stable 18.06 build.
Note that each build in the download directory has a date stamp. If there are several versions, take the newest.
You need the factory version to flash from the Netgear OEM firmware.
EDIT:
owrt1806-r7810-b84f761d91-20190630 should be equivalent to the 18.06.4 which is currently being compiled at the release buildbot.
1 Like
One year of further development, more updated versions for quite many packages etc.
But nothing spectacular.
Hi, I am currently running a recent regular snapshot. I understood that there are quite some issue left w.r.t. the R7800, as in:
- latency spikes: my assumption is that these are solved?
- NSS drivers not installed, because frequency scaling doesn't work: currently WIP.
- CPU frequency scaling not working properly, resulting in delays and/or reboots.
- sub-optimal (or even no use?) of dual core: IRQ's need to be appointed to a CPU manually to ensure efficiency here.
- MU-MIMO not working: as far as I know this isn't working on any router yet.
- any other known issues?
Therefore, I am considering hyman's build.
I don't suffer from reboots, but my internet isn't fast. I am just doubting if I should continue with the R7800, go for a Linksys WRT-32X with OpenWrt (Davidc502's builds) or switch to something like Ubiquity.
Thanks in advance for your help.
Forcing the NSS CPU to a fixed frequency worked around the stability issue. My R7800 has been up for more than 3 days now with the NSS cores accelerating routing functions. At the moment, my builds are based on lede-17.01 tho.
If you don't mind running a v4.4.x kernel, you can try installing my builds and see if it's performing up to your expectations. At the moment, we need more people to test in order to surface major issues.
1 Like
R7800 has good all around OpenWrt support but people seem to have different levels of success as with the issues you point out. WRT32X is an excellent OpenWrt router too, with 940Mbit routing performance, fast SQM, 80 MB/s USB storage speed, cheaper price, great looking, etc. but has some missing Wi-Fi features because the mwlwifi driver was unfortunately abandoned by Marvel, so it doesn't do MU-MIMO or Mesh. I'd say both routers work well and are about equal overall with their own pros/cons.
1 Like
Thank you for your good work. My post might have been a bit less polite. Hopefully Inhave some time to test your build this weekend, although I am not that technical. Stupid(?) question: is it possible to install and configure the NSS drivers in a snapshot build? Same question for setting the CPU to performance and sorting uit the IRQ issues.
Should be possible, but my attention at this point is to make the NSS drivers usable enough for my R7800 for lede-17.01 branch, i.e. kernel v4.4.x first. Then I'll proceed to port over to master, which is on v4.19.x. The NSS drivers are targeted for the v4.4.x kernel, but from what I understand so far, it shouldn't take too much effort to port it to v4.19.x. Hopefully I'm right.
In any case, v4.4.x is on LTS until early 2022, so it should still get security and bug fixes and it's still maintained by the OpenWRT folks.
1 Like
The v17.01.7 release will also mark the end-of-life of the LEDE 17.01 series - we'll decommission the LEDE 17.01 related build resources and repurpose them for producing 19.07 binaries.
That's a shame. For some reason, v4.4.x LTS EOL is 1 year later than v4.19.x which is projected to end by Dec 2020. v4.4.x EOL is projected by Feb 2022.
So it looks like OpenWRT will be moving to v5.x next year.
What if you just run it once a week with --oneshot as part of a cron job, as suggested by @ hnyman? irqbalance caused crashes and freezes on my router when I used to have it running all the time, though it could be a coincidence too.
Well, this implies that one can predict the future based on the past only, with is not true.
A while ago I found that in my case it is beneficial for this router to split the CPU cores by dedicating one to processing network interrupts and the other one for all the other processes like dnsmasq, hostapd, collectd, nlbwmon, etc with no cross pollination. Everyone's milage will vary, but when I stopped doing that (decided to save some time by using the image builder) I started hearing complaints that the gaming experience suffers: a game-server party of 12 becomes a slide show apparently and the max party size dropped to 8...
Another option (that I am playing with right now) is to have both wifi's and all processes on one core and wired LAN/WAN/SQM on the other. It also looks pretty good so far.
this is a thread specifically about hnyman's community build for the Netgear R7800. Nevertheless; yes: your router is supported https://openwrt.org/toh/start?dataflt[Model*~]=wrt32x and there's a community build available, too https://forum.openwrt.org/t/davidc502-wrt1200ac-wrt1900acx-wrt3200acm-wrt32x-builds/
2 Likes