Is it considered normal to have to periodically reboot a Raspberry Pi?

[rob77]

That's normal. Linux will drop stuff into swap to maximise available buffer space.
Even with obscene amounts of free memory.

Code: [Select]

brad@srv:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:          64319       21323         570           6       42425       42281
Swap:         40927        4168       36759


not Linux... your distribution is doing than by dictating the default value of swapiness  Linux (the kernel) is just doing what it's told to do. set your swapiness accordingly and the kernel will not page out anything unless it's the last resort option.

Nothing to do with "my distribution" and entirely kernel defaults. So yes, Linux...

There is nothing on any of my systems that tweak kernel policy in any way other than what I explicitly do and I don't touch the VM subsystem.

"your distribution" =>  linux distro you're using.. didn't say you personally changed anything...
it's your linux distro maintainer who chose the default values at compile time. for example raspbian designed to run from a sd crad will have a low default swapiness but a desktop distro will have a higher one.

[BradC]

That's normal. Linux will drop stuff into swap to maximise available buffer space.
Even with obscene amounts of free memory.

Code: [Select]

brad@srv:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:          64319       21323         570           6       42425       42281
Swap:         40927        4168       36759


not Linux... your distribution is doing than by dictating the default value of swapiness  Linux (the kernel) is just doing what it's told to do. set your swapiness accordingly and the kernel will not page out anything unless it's the last resort option.

Nothing to do with "my distribution" and entirely kernel defaults. So yes, Linux...

There is nothing on any of my systems that tweak kernel policy in any way other than what I explicitly do and I don't touch the VM subsystem.

"your distribution" =>  linux distro you're using.. didn't say you personally changed anything...
it's your linux distro maintainer who chose the default values at compile time. for example raspbian designed to run from a sd crad will have a low default swapiness but a desktop distro will have a higher one.

I know what you're saying. I'm saying my "distribution" doesn't touch any knobs. My VM settings, and in fact everything except some block and md settings are absolutely kernel default and those I explicitly change.

[rob77]

I know what you're saying. I'm saying my "distribution" doesn't touch any knobs. My VM settings, and in fact everything except some block and md settings are absolutely kernel default and those I explicitly change.

i see your point... but keeping the kernel source defaults as your distro's defaults still doesn't mean that "Linux will use swap to maximize buffers.." it's still the maintainer of the distro (be it you or anyone else) who decided that will be the behavior of that particular linux distro.

it's like not choosing a color of your new car (even though it would be free of charge) and then stating that they sell only red ones because the one you've got is red.

analogy to the above : you didn't pick a default at compile time and then stated that the behavior of your linux dristro is the behavior of Linux in general.

[Sal Ammoniac]

One of my Pi’s was last rebooted in January 2019.

So it's bang up-to-date with security fixes, then???

It's not connected to the Internet...

[Ed.Kloonk]

One of my Pi’s was last rebooted in January 2019.

So it's bang up-to-date with security fixes, then???

It's not connected to the Internet...

As far as we know..

 

[cdev]

I have several Pis that run 24/7/365.  As a distro, RaspiOS (ex Raspbian) seems very stable. Not quite as stable as freeBSD, but very good..If you are having crashes, look for a memory leak or some problem with one of the programs you are running.

Check the logs.

[e100]

Just an update, this week I discovered that the 32bit version of Influxdb on the Raspberry Pi consumes huge amounts of CPU time if its database is allowed to get  bigger than 2GB. Apparently this is a known problem that won't be fixed in the 32bit version as the Influx developers are focused on the 64bit version. (The Pi still isn't mainstream 64bit yet.)

Strangely the default setting is for Influx databases to have no size limit, which of course is a ticking bomb. You'll either hit the 2GB limit or run out of disk space. The workaround is to set the 'retention policy' at database creation time.

The CPU starvation had a particularly bad impact on my Java program as it throttled the rate at which it could send MQTT messages. It went from the desired 1 per second to 1 every 9 seconds. This in turn caused another program running on a connected microcontroller to think that there was an ongoing comms failure and therefore it went into auto-shutdown mode turning off the hardware it was controlling.

Even stranger was that node-red running on the same Pi was affected to some degree, but not as badly affected as my Java program. No idea why that would be the case.

Nothing crashed, all the program logic behaved as designed, there were no memory leaks, my Java program just got slower and slower until the keep-alive timeouts I had programmed into the system to detect hardware disconnections were triggered by software slowness. To fix it I deleted the database and recreated a new one with a 28 day retention policy and everything just went back to normal with MQTT messages being sent at the desired 1 second interval. I didn't need to restart any processes or reboot the Pi.

Not sure how you would detect this kind of problem in a test environment except for leaving it running for months. Sure, if you had prior knowledge about a weakness then you could prime the system and wait for it to fail at a predicted time, but in this case who would of thought that there would be a sudden massive increase in CPU usage just because a database file has gone over some size limit. The whole point of databases is that they are good at storing stuff therefore you would assume that 2GB wouldn't be a problem.

[cdev]

if you make 64 bit hw and os your defaults you'll see fewer problems. A lot fewer

[brucehoult]

(The Pi still isn't mainstream 64bit yet.)

Shockingly.

The first 64 bit Pis went on sale more than 6 years ago, and every Linux-capable Pi in the line-up is now 64 bit, even the Pi Zero 2.

[SiliconWizard]

I've been using Archlinuxarm on the Pi, and there's a 64-bit version that works fairly well.
https://archlinuxarm.org/
They claim "near full support", I haven't personally run into issues with it, but possibly some hardware features might not have full support yet. Graphics acceleration works. But I don't use Pi's as any kind of "desktop" computing, so some things may be missing that do not bother me.

As to the lag supporting 64-bit being shocking, yeah, but usual. As I routinely say, the real problem with all those SBCs, Pi included (but possibly to a lesser extent than some other brands), is software support.
The hardware may be great, but software support is often lacking in some ways and you're just stuck with that. And since many of them use SoCs than do not have public documentation, you can't even help.

[james_s]

I think the reason for the lack of much 64 bit support has been that most of the RPis out there have too little memory to need 64 bit. None of mine have more than 4GB and for the things I use them for they don't need it. That's not to say there isn't a point in 64 bit or that in the future it won't be more common but so far it hasn't really been sorely needed.

[SiliconWizard]

That sure was one of the main points, but the Pi now has 8GB versions, so...

[james_s]

That sure was one of the main points, but the Pi now has 8GB versions, so...

It does now, but that is a recent development, and the vast majority of those deployed have much less. 64 bit will mature over time, when the first version of the RPi came out things were pretty rough around the edges on that one too.

[brucehoult]

I think the reason for the lack of much 64 bit support has been that most of the RPis out there have too little memory to need 64 bit. None of mine have more than 4GB and for the things I use them for they don't need it. That's not to say there isn't a point in 64 bit or that in the future it won't be more common but so far it hasn't really been sorely needed.

On both ARM and x86 there are a number of very good reasons to use the 64 bit ISA even if you don't need more than 4 GB of (virtual) memory [1] On both you get double the number of registers and a much more efficient function call ABI in the 64 bit ISA.

In the RISC-V world there are 64 bit SoCs with as little as 8 MB RAM (Kendryte K210) or 64 MB running Linux (MangoPi-Nezha MQ with Allwinner D1s) and no one says "OMG they should only be 32 bit!". They don't even *have* a 32 bit mode -- 64 is all you get.

[1] and there are also reasons to use more than 4 GB of virtual memory even if you don't have that much physical memory -- sparce address spaces have a number of benefits, including security and fragmentation.

[DiTBho]

They don't even *have* a 32 bit mode -- 64 is all you get.

Like MIPS4. 64bit is all you get

p.s.
I have here a R18K prototype board.
R16K was the last commercial MIPS4.

[brucehoult]

They don't even *have* a 32 bit mode -- 64 is all you get.

Like MIPS4. 64bit is all you get

p.s.
I have here a R18K prototype board.
R16K was the last commercial MIPS4.

It's going to be interesting to see what MIPS does with RISC-V and whether it is successful.

[cdev]

The OS yes, but the RPI3 only comes in a 1GB flavor which supoorts a 64 bit OS, there is no such thing as a 4GB RPI3. (unless you build it yourself, which might be possible, with the right RAM modules, if such exists, I suspect)

[james_s]

The RAM on the RPI is integrated into the SOC and AFAIK you can't buy the CPU anywhere. Broadcom only sells them to large volume manufactures.

[brucehoult]

The OS yes, but the RPI3 only comes in a 1GB flavor which supoorts a 64 bit OS, there is no such thing as a 4GB RPI3. (unless you build it yourself, which might be possible, with the right RAM modules, if such exists, I suspect)

You should be able to expect to run a 1 GB application (minus maybe 32 or 64 MB for the OS) on a machine wth 1 GB RAM. But in a 32 bit address space that is close enough to 4 GB (or 2 GB for user space) that all kinds of undesirable things start to happen:

- a random pointer (or a malicious one) is likely to point to actual in-use data

- a conservative garbage collector won't be able to tell that integers aren't poointers

- if a malloc()-using application is repeatedly allocating and freeing objects of even a few dozen KB, let alone MB, then the address space can easily become so fragmented that it's not possible to allocate a large object even though there is plenty of space available.


Running a 64 bit OS solves all these problems.

The only downside is that pointers are twice as big in RAM, and also registers saved on the stack by function calls are twice as big. This can be a real problem for programs that use only a few KB of RAM, but programs that use 1 GB of RAM seldom use a significant percentage of that for stack or pointers.

[DiTBho]

the CPU module of my MIPS32board exports 32bit address, 32bit data, ctrl, DMA, IRQ, etc, but it reserves the highest 512Mbyte for the PCI and memory mapped stuff

You have { A31..A00 }, but you you cannot install 4GB of ram, the max you can practically address is 3.5GB 

[dave j]

The RAM on the RPI is integrated into the SOC and AFAIK you can't buy the CPU anywhere. Broadcom only sells them to large volume manufactures.

Only on the Pi Zero 2 is the RAM integrated into the SOC. The BCM2835 based Pis (Pi1, CM1 and original Zeros) use PoP. All the other Pis have separate RAM chips soldered to the circuit board.

[SiliconWizard]

The RAM on the RPI is integrated into the SOC and AFAIK you can't buy the CPU anywhere. Broadcom only sells them to large volume manufactures.

Only on the Pi Zero 2 is the RAM integrated into the SOC. The BCM2835 based Pis (Pi1, CM1 and original Zeros) use PoP. All the other Pis have separate RAM chips soldered to the circuit board.

Yes. This was a new step with the SoC designed for the Zero 2. And it's limited to only one RAM size of course (making SoCs with multiple options for RAM size would be pretty expensive for no good reason.)

Now I don't have any schematic for the Pi4 (for instance), so I don't know whether it would just be a matter of reworking the board (desoldering the existing RAM chip(s) and soldering new ones, assuming you have the equipement and skills to do it), or if the PCBs are different. Or if there is any other step to take, like solder jumpers, or something.

[dave j]

Now I don't have any schematic for the Pi4 (for instance), so I don't know whether it would just be a matter of reworking the board (desoldering the existing RAM chip(s) and soldering new ones, assuming you have the equipement and skills to do it), or if the PCBs are different. Or if there is any other step to take, like solder jumpers, or something.

There have been several queries about upgrading the RAM on the Raspberry Pi forums. They changed the circuit board for the Pi4 8GB to provide more power but I don't know if they are now using that board for all Pi4s now. There's also the issue of how would you get the SoC to recognise a different chip.

[DiTBho]

There's also the issue of how would you get the SoC to recognise a different chip.

It looks like what we did in 2004 with Fonera, to upgrade the ram from 16 MB to 32 MB ... we had to - desolder and resolder - and - to hack the firmware - to make it recognize the different ram chip.

It's always the same game