cb1 ram issues

[grim trellis]

What does cat /proc/meminfo show?

[ruby delta]

I'll get back to you in 5 days if I don't forget

I've rebooted already

[gritty hatch]

Just realized the cb1 image is 64-bit. That might explain the problems. Is there a 32-bit image available?

[grim trellis]

no, just the pre-installed klipper or the minimal image
https://github.com/bigtreetech/CB1/releases/tag/V2.3.3

[gritty hatch]

shit

[grim trellis]

I will ask Alan if they can make a 32 bit version

[gritty hatch]

definitely worth a shot. 64-bit makes no sense on a CB1 anyway 😄

[ruby delta]

currently 66% mem load

[ruby delta]

btw there are newer releases on the armbian page for cb1

[grim trellis]

btw, have you tried to make a RatOS image from them?

[ruby delta]

nope

[grim trellis]

looks like they only have "bookworm" which is the version after "bullseye" which is what ratos is currently using

[ruby delta]

after 6 days

[grim trellis]

@gritty hatch is it normal for there to be so many klipperscreen instances and for each of them to be taking over a gig of virtual RAM?

Adding up the physical memory usage of the top ones in htop you only get like 35%.

Looking at meminfo there, there is a lot of memory being used by the kernel(slab, sunreclaim). Sounds like something is having a memory leak

It also is suspicious to me that so many of those klipperscreen instances have 0 runtime. I would try disconnecting whatever klipperscreen you have

[ruby delta]

I dont have one

I normally just stop klipperscreen and configurator services after restart, that way this memory "crawl" takes longer

[gritty hatch]

That process tree is misleading, i think those are a bunch of childprocesses and the 1gig is the total (which is high and unusual).

try top instead

[ruby delta]

sorted by %mem, shr, virt respectively

[ruby delta]

I have now(out of boredom)
https://github.com/Richter-gh/RatOS/actions/runs/6132282526

this uses latest image from github tags. havent tried with the one from armbian