The 64bit version of the OS is considered beta. While that might be unrelated to this, it would be worth testing with 32-bit Raspbian. RPi ought to make the 64-bit version available on their main download page when it’s stable.
Unless you are running massive databases, 4GB memory per process is going to be beyond-ample for typical and extreme-type use cases for single board computers. The 64-bit OS may assist some very-niche situations, such as >4GB databases sitting in memory on an SBC, though that’s not a normal situation that most folks find themselves in!
Let us know how you get on with the 32-bit version of Raspbian. Again, might be unrelated. Though it is beta and best suited for developers that can contribute new featues and stability improvements.
I’ve tried several versions and have not had much luck aside from my latest 10 day streak using raspberry 64. I’ve had the same issues with ubuntu 64, raspberry os 32 and raspberry os 64.
That’s very interesting, I would suggest taking a look at Cron Jobs to see whether you can set up an automated restart on your Pi each given period of time, by restarting frequently to this should ensure that the Pi continues to run for extended periods. It’s not an optimal solution, but as long as you’ve got scripts to automatically start the required programs on boot, it may help with the issues you’re currently having until the actual problems can be solved.
This Pi is due to be returned now. If anyone reading this has issues with their Pi or other part purchased from Core Electronics due to faults please reply to your order confirmation email and we’ll get it sorted out right away. Of course, we’re more than happy to help troubleshoot on the forum and see whether we can fix it . Have a great day!
Looks like the GitHub issue is still open, but they’ve got some excellent suggestions on where to get started. I’d try a few of their suggestions since when we tested the Pi we found that all the hardware was functional, so it’s likely a software issue (potentially related to running the Pi headless). Please let us know how you go with it and if there’s anything that we can do to help, have a great day!
Also FYI for anyone who finds this via Google. We ran stressberry for 50h on Lyall’s Pi without a hiccup, so confirmed it wasn’t a stability issue with the hardware.
after further testing i found that whatever you set the cpu and gpu and over voltage to is what the cpu will be running when the governor is set to performance…
under Ubuntu it has a cpu scaling monitor.app .i found this to only be a pull down governor control…
so for example if you have set the arm_freq=2000 and you have the governor set to performance then that is the max speed that the cpu will be running at.
you can govern it down but you cannot govern it higher than what you have set it to in the config.txt file but you can govern it down using the cpu scaling monitor.
.i have only just started to use Debian so i am not 100 % shure of its cpu control under the Debian gui…
The new wifi firmware is looking promising. I’m at 11 days uptime with the WIFI having remained stable the entire time. Previously if the firmware crashed only a reboot would bring it back.
. Have a great day!
