TijuanaKez

Linux 6.1.63-current-rockchip64

Just chiming in here to say that after updating Armbian via OMV6 backend some time after my last post in Sep last year, my unit has remained stable for over 3 months. No idea why. Perhaps a magic fairy helped us. Happy days!

Yeah, totally hosed my whole setup. Can't ssh in anymore, and the serial output seems to have stopped working so it's a pretty pink paperweight till further notice

Thanks for adding that info. As for updates, I was actually thinking I was in the clear. The unit had stayed up without a hitch since my last post over a month ago and seemed impervious to putting it through it's paces. That was with 5.15.93-rockchip64 and 400-14000 ondemand governor. Sorry to say though I ran the auto update in the OMV6 backend that contained some Helios64 specific updates. At the time I thought great, someone, somewhere has made some tweaks! But now my unit is completely hosed. I can't even boot it to a state where I can ssh in and see what's up. TBH, I don't really understand where these updates came from. Are these coming from the community? Or are the being autogenerated by the Armbian build process, perhaps with old and outdated code that contains issues because the Helios code is not maintained? If so, anyone got tips on rolling back the kernel / updates? TBH I'm not even sure if the Helios64 specific updates were to do with the kernel or something else.

Interesting that yours doesn't freeze up on Segmentation fault etc. I also have a suspicion that the amount and kind of drives installed as this has an effect on power drawer and possibly integrity of the 12V and 5V rails. Grounds for the suspicion: Suggestion to raise VDD to 0.95V to improve stability as done with other Rockhip RK3399 boards Preventing the higher CPU frequencies makes it more stable. High CPU freqs are more demanding on power. The fact they shipped the unit with big electrolytic capacitors soldered to the end of wires on the Sata loom. Seems like a way to help smooth power rails without having to redesign the board. Various other hints here on the subject of VRMs, cpu governor settings, ramp time, latency etc in relation to the RK3399. https://forum.odroid.com/viewtopic.php?t=30303 https://github.com/u-boot/u-boot/commit/f210cbc1f3d4f84baa595d83933369b4d6a529ea https://github.com/u-boot/u-boot/commit/5a6d960b222203e60ab57e19b3eb7b41c24b564b https://wiki.t-firefly.com/en/Firefly-RK3399/driver_pwm.html http://patchwork.ozlabs.org/project/uboot/patch/20191128061433.1952869-2-anarsoul@gmail.com/ So, @mrjpaxton interested to know how many drives you have installed, and what type (5400, 7200, or SSD)? Also a possibility is running fewer tasks on the unit means the CPU has less demand and the governor may by rarely, if at all, trying to switch into the higher problematic frequencies. update: my unit still hasn't frozen again since last post with the 4000-14000 omdemand so things are looking pretty stable. so far so good anyway.

@mrjpaxtonI defintely bulit the unit corretly. As I said in the post, I had a %100 stable unit on OMV5 with the image listed in the wiki for years. Paying attention to this forum though, it's clear stability issues have been long running for many users and from what I can gather, the root problem is to do with cpu and power management. Quite a complex subject, something that PC overclockers would know more about than me. @snakekick thanks for chiming in too. Good info. Collecting info as I find it, it does seem like preventing the CPU from hitting the high end is the best way to go (contrary to other posts here). Still running on-demand 400-14000 now on @bunducafe's info, and it's more or less stable. As it's only happened once so far since changing to that setting, I can't even confirm it wasn't some other insult to the system

@mrjpaxton Thanks for the info. If I get some time I may try that out. Really though I'd be happy to freeze the kernel now if it would remain stable. The main purpose of the unit for me is running Nextcloud so whatever it takes to keep that running and the unit staying up. Btw, is your unit currently stable? If so can you share your CPU governor settings and any other tweaks you may have made? Thanks!

Mine never reboots, it only 'freezes' sporadically on the default cpu freq/governor settings and requires me to physically press the reset button. TBH a reboot would be better as I dont need to be in the house to fix it. Did you try disabling the suspend modes I mentioned a few posts back?

@mrjpaxton Thanks for chiming in. The TerreMaster does indeed have alot in common with the Helios64, and it does have the bonus of 10gbe. At over A$1000 (probably AUD$1100 with postage) it's it's more than double what I paid for the Helios full bundle, and the Helios was already a bit of a stretch philosophically for what a NAS adds to my life. Add to that the caveats you mentioned...... Likewise the 'build a small PC' type NAS always seemed I'd be entering into the power consumption equivalent of just leaving my main PC on 24/7 (which has plenty of sata and 10gbe already). When the PI3 then 4 came around, it seemed like the perfect thing for a NAS. The right amount of CPU/ram, the small form factor, low power consumption, low price, easy to get OMV on it etc. Just sadly no way to get real sata on it. With a Pi4 4GB costing me about A$100, it seemed adding *with* real sata for a modest price increase shouldn't be too much to ask for. Why doesn't someone make it I thought? Well they did, it was the Helios board. And it was awesome. And even though I dont care much about the case for something that'l probably be out of sight (I can 3D print), the hot pink got me Fast forward to now, when such things should be getting cheaper, TerraMaster think A$900 is appropriate to add to a raspberry pi 4 equivalent SBC to add 5 sata ports, 10gbe, and a plastic case. Not feeling any purchase urges at all. @bunducafe On a positive note, I've been running with your governor settings (ondemand - 4000 - 14000) and it does seem pretty stable. I've had to reset it once in 10 days, but I think I can live with that.

If so how'd ya do it!?!? My personal experience had been a rock solid device on the original official Debian Armbian image (Linux Kernel: 5.10), and OMV5. It never went down unless I manually rebooted, and I never needed any CPU governor changes, voltage changes or otherwise to keep it stable. Reading so much stuff about OMV5 being end of life made me pull the trigger on upgrade to OMV6 along with the kernel upgrade that OMV did automatically, at the time unaware of the state of Kobol and Armbian support. Now I get about 1-2 days on average before it KPs and I have to hit the reset button. Tried the CPU underclocking, performance setting, VDD boost and various combinations but to no avail. So just reaching out to any other users here, is anyone still rocking a stable unit in 2023? Did you have to revert to Buster / OMV5? Are there any other tweaks to try that I've missed other than CPU clock/profile/vdd tweak? Is there any way to get any information on why it might be happening? Or is the only way to have a hardware serial console open 24/7 via a usb cable?