RAM: 1GB vs 768MB (DON'T DO THAT)

amouiche / qnap_mtd_resize_for_bullseye

Script for resizing MTD partitions on a QNAP device in order to be able to upgrade from buster to bullseye

GNU General Public License v2.0

51 stars 11 forks source link

RAM: 1GB vs 768MB (DON'T DO THAT) #45

Closed lpaolini closed 8 months ago

lpaolini commented 10 months ago

I'm running Debian Bookworm on a QNAP TS-221.

Does anyone know if the Debian bug preventing the use of 1GB of RAM has been solved in Bookworm?

I assume it's safe to stop U-Boot from the serial console, replace 768M with 1024M in bootargs and try booting...

lpaolini commented 10 months ago

Ok, I tried that and it seems to be working normally, but with an extra 256MB of RAM. Yay!

Also, I've been running memtester to stress-test all the available RAM (800MB in my case) for a few hours (8 loops completed) without any issue.

amouiche commented 10 months ago

Good !

On Thu, 2023-09-07 at 22:55 -0700, Luca Paolini wrote:

Ok, I tried that and it seems to be working normally, but with an extra 256MB of RAM. Yay! Also, I've been running memtester to stress-test all the available RAM (800MB in my case) for a few hours (8 loops completed) without any issue. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.*** m>

Conan179 commented 9 months ago

@lpaolini How did you remove the mem=768M?

tbm commented 9 months ago

@lpaolini what kernel version is this? I wasn't aware that 1 GB is working now. Are you using an unmodified kernel from Debian?

lpaolini commented 9 months ago

@tbm I'm on latest Debian bookworm, unmodified kernel. Linux nas 6.1.0-11-marvell #1 Debian 6.1.38-4 (2023-08-08) armv5tel GNU/Linux

lpaolini commented 9 months ago

@Conan179

I did it like this:

connect a serial console (115200, 8n1)
power on
stop U-boot by pressing a key
print the current U-boot environment using the printenv command
copy the bootargs line in an editor end remove the portion with mem=768M
use the setenv command for setting new bootargs (setenv bootargs=...)
use the boot command to boot using the current bootargs, which will be lost at the next reboot
if it worked, reboot and repeat the entire process, but after the setenv command also run saveenvto persist the changes.

However, there's a much simpler alternative (which doesn't require a serial console) explained here by @tbm.

Conan179 commented 9 months ago

Hm QNAP: Recovery Button pressed: 0 Marvell>> printenv Unknown command 'printenv' - try 'help'

Conan179 commented 9 months ago

You have to come to that first. I have to type/copy the command twice. Always, the first time you do it, you get the message “I don’t know the command!” the second time it works.

lpaolini commented 8 months ago

I don't know it if's related or not, but since when I extended the RAM to 1GB, despite apparently working fine, I started having some unfrequent random issues, like losing ssh connectivity.

Yesterday, while flashing the kernel and initrd after an update, I got a pretty scary *** stack smashing detected ***: terminated, which I had never seen before.

So, at least for now, I've restored mem=768M in the bootargs. Let's see if there's some correlation...

Conan179 commented 8 months ago

I also put the "mem=768M" back in, a restart took 3-4 times as long as with the option. As a summary I would say the ram bug is still there.

lpaolini commented 8 months ago

After switching to mem=1024M I started noticing some weird behaviour, which now I correlate to the memory "upgrade".

A few times it happened that I lost ssh connectivity, as if the daemon was not listening. But a few days ago, a failed apt upgrade ended up with a corrupted kernel and initrd in flash memory. I managed to recover the system, but I came to the conclusion that those extra 256MB of RAM are simply not worth it, if that's the price to pay.

So, at the end I finally reverted my bootargs from mem=1024M to mem=768M.

My advice is to stay with 768MB and avoid a lot of troubles.