Hello @SkewedZeppelin,
I've identified a problem with the L2C cache, the sync() function between the L2 cache is not implemented (and therefore wmb()).
Would you have any info since you're keeping your kernel a bit more up to date with lots of patches :D.
Thank you, this is an open question, if anyone else has any info, please share.
I noticed that router system log for august 31th is almost empty, like nothing happened on my network that day. I restarted my router -> network at 22:00 because of a smart hub controlling my lights didn't respond. It didn't resolve the issue with the smart hub, but a few hours later it started responding again (00:03).
To the question, has anyone noticed this kind of behaviour, router log almost empty, no logging for 22 hours?
Do you run a network restart or router restart in cron to every night - is it recommended?
I've seen 30days+ uptime on my router without any problems, so I don't think it's necessary tho...
Here is a patch of interest, long time coming.
sysupgrade has been broken on these devices for a few months now:
I'm offering a 1XMR bounty to anyone who fixes it during the month of October.
i dont know what a 1XMR is but I endorse the bounty. these devices have hardware and firmware capabilities that have made their power long-lived as multfunction routers, despite age and some wifi complexity, and despite many candidate contenders, i havent found a better value solution for the edge and gateway to my large home network. it would be a shame to lose openwrt support for these. i suspect that addtions to the devices in the mvebu hardware support list with their specific u-boot/mtd/sysupgrade cases somehow broke what was working for the linksys wrt32x and wrt19x devices.
+1 to the rest.
Interesting, i did start to notice a strange situation sometime mid-summer where after i sysupgrade my very-similar spin-off of DivestedWRT (it's nearly the same build, but slightly adjusts the packages to either trim them down further and add a few sometimes esoteric other packages i need like nginx in lieu of uhttpd), that whenever i reboot for the new firmware, i initially was unexpectedly seeing older kernel/packages, and eventually i was realizing what made things work was to actually use sysupgrade a second time, as the first boot always seems to come up with my configs but with a build frozen with kernel 6.6.35 (and packages from that time). So I just "worked around" this weirdness eventually by learning to flash twice, but now i realize this sysupgrade issue could in-fact be potentially the reason or at very least related.
One thing i'm doing uniquely however is that i'm always baking-in my latest set of configs (that i track in git) so i don't try to preserve the configs in a sysupgrade-backup. I could flash from a completely blank device and the build will have all my configs already present (not sure if this is a great idea but it's worked so far and i never had to test it (on a fresh device) in-anger).
So anyway, I just did some digging w/ my prev builds, and from those i have on-hand, the problem seems to roughly have started when i had flashed the one based on r26844 (this version has the 6.6.35 kernel which ever-since-then shows up as a indicator of the "failed" sysupgrade). This is the version corresponding to DivestedWRT build 20240625-00.
Likely ever since that version, when i flash newer builds, the first time i reboot it after sysupgrade, it shows me the kernel and respective packages from 20240625 still (tho i haven't checked the partition number, but i know there's two so running sysupgrade a 2nd time shows me the expected newer kernel & packages). Curiously my configs always get preserved, probably because they are written somewhere else.
yes, interesting. i even if i ask it to not preserve config, it fails. think the problem is with the wasy sysupgrade allocates temporary space to preserve configs, but i'm not sure how to confirm/refute.