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

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?