Issues after upgrading my laptop's RAM

Hey there!
I was following a topic created by someone who seems to have an issue like mine, and now I’m creating a dedicated one to be more detailed, as suggested by @computersavvy

I actually don’t think this is a Fedora-specific issue, since the same problem happens with other distros, but I’m using Fedora right now so I post it here.

So, I’m using a Thinkpad E14 and I recently upgraded it’s RAM, from 16 to 40gb.
Why this odd value?
Well, simply because this specific model of laptop has two RAM slots, with 8gb each by default, but one of the two is soldered, so only the other is upgradable. This leds me to weird RAM values.
I swapped out the slot and replaced it with a 32gb one. So now I have 32+8=40gb.

Actually, free shows total 39850072, which is not exactly 40gb but I think this is somehow normal. Right?

Anyway, this is not the problem. The real problem is that since when I did the upgrade, the system performance has actually gotten worse.
Unfortunately I don’t have any benchmark so nothing truly objective, but specifically when I copy/move large files from/to my NVME, I have frequent freezes.
During the transfer, if I try to do anything (like, anything: using the terminal, opening apps, using already open apps in any way…) the system just freezes for sometime which could be some seconds to 10 minutes top, and it just doesn’t respond anymore. I just have to wait, when that time is finished all the operations I tried to do are actually done, like if there are being queued, somehow.
The system keeps behaving like this no matter what, until the transfer finishes.

I seem to have some graphic glitches that I didn’t have before too, but again I have no objective way to prove it so I might just be wrong about this.

As I said I tried this on many distros and I still have the same issue and the Fedora system I’m writing this from is freshly installed, so my first guess, that I had mis-configured something, was wrong.

After some digging, I found out about the post I linked above which describes exactly my issue, and the solution seems to be to set the right values for vm.dirty_background_bytes and vm.dirty_background_ratio in /etc/sysctl.d/99-sysctl.conf.
After I found this thread, I found other sources talking about this which seems to confirm the solution, like the ArchWiki and SUSE, among others.

The problem is I never really heard about this configuration and the values in the three links I posted are all different, which makes sense because I’m supposed to tweak them according to my amount of RAM, right?

So, since my amount of RAM is a bit unusual and I prefer not to do write random values in /etc/sysctl.d/99-sysctl.conf just to find out by trying, could anyone please help me to find out some reasonable values to write?
Also, obviously if you happen to know other things that might help me to solve my problem, I’d really appreciate to know them!

Thank you.

Please post the values of the file you mention above as preformated text (</>).

A inxi -Fzx would also been interesting to see how your swap space is (and config in general). You had less memory, as you have more you could also increase this value.

/etc/sysctl.d/99-sysctl.conf is empty and it’s a simbolic link for /etc/sysctl.conf, which has just commented text in it, so it’s empty too.
This is a fresh system as I said so I haven’t done any modification. Anyway the text is this:

# sysctl settings are defined through files in
# /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
#
# Vendors settings live in /usr/lib/sysctl.d/.
# To override a whole file, create a new file with the same in
# /etc/sysctl.d/ and put new settings there. To override
# only specific settings, add a file with a lexically later
# name in /etc/sysctl.d/ and put new settings there.
#
# For more information, see sysctl.conf(5) and sysctl.d(5).

The output of inxi -Fzx is this:

System:
  Kernel: 6.9.5-200.fc40.x86_64 arch: x86_64 bits: 64 compiler: gcc
    v: 2.41-37.fc40
  Desktop: GNOME v: 46.2 Distro: Fedora Linux 40 (Workstation Edition)
Machine:
  Type: Laptop System: LENOVO product: 21EB0041SP v: ThinkPad E14 Gen 4
    serial: <superuser required>
  Mobo: LENOVO model: 21EB0041SP v: ThinkPad serial: <superuser required>
    UEFI: LENOVO v: R20ET36W (1.16 ) date: 05/16/2023
Battery:
  ID-1: BAT0 charge: 41.5 Wh (78.0%) condition: 53.2/57.0 Wh (93.4%)
    volts: 12.2 min: 11.5 model: SMP LNV-5B11C73244 status: not charging
  Device-1: hidpp_battery_0 model: Logitech MX Ergo Multi-Device Trackball
    charge: 100% (should be ignored) status: discharging
CPU:
  Info: 8-core model: AMD Ryzen 7 5825U with Radeon Graphics bits: 64
    type: MT MCP arch: Zen 3 rev: 0 cache: L1: 512 KiB L2: 4 MiB L3: 16 MiB
  Speed (MHz): avg: 1348 high: 2611 min/max: 400/4546 cores: 1: 400 2: 2021
    3: 1927 4: 2174 5: 400 6: 400 7: 400 8: 400 9: 1900 10: 2611 11: 400 12: 400
    13: 2046 14: 2162 15: 1942 16: 1996 bogomips: 63885
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
  Device-1: AMD Barcelo vendor: Lenovo driver: amdgpu v: kernel arch: GCN-5
    bus-ID: 05:00.0 temp: 47.0 C
  Device-2: Luxvisions Innotech Integrated RGB Camera driver: uvcvideo
    type: USB bus-ID: 1-3:2
  Display: wayland server: X.Org v: 24.1 with: Xwayland v: 24.1.0
    compositor: gnome-shell driver: dri: radeonsi gpu: amdgpu resolution:
    1: 2560x1440~60Hz 2: 1920x1080~60Hz
  API: OpenGL v: 4.6 vendor: amd mesa v: 24.1.2 glx-v: 1.4
    direct-render: yes renderer: AMD Radeon Graphics (radeonsi renoir LLVM
    18.1.6 DRM 3.57 6.9.5-200.fc40.x86_64)
  API: EGL Message: EGL data requires eglinfo. Check --recommends.
Audio:
  Device-1: AMD Renoir Radeon High Definition Audio vendor: Lenovo
    driver: snd_hda_intel v: kernel bus-ID: 05:00.1
  Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor vendor: Lenovo driver: N/A
    bus-ID: 05:00.5
  Device-3: AMD Family 17h/19h HD Audio vendor: Lenovo driver: snd_hda_intel
    v: kernel bus-ID: 05:00.6
  Device-4: Focusrite-Novation Focusrite Scarlett 2i2 2nd Gen
    driver: snd-usb-audio type: USB bus-ID: 1-2.1.1:6
  API: ALSA v: k6.9.5-200.fc40.x86_64 status: kernel-api
  Server-1: PipeWire v: 1.0.7 status: active
Network:
  Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
    vendor: Lenovo driver: r8169 v: kernel port: 2000 bus-ID: 02:00.0
  IF: enp2s0 state: down mac: <filter>
  Device-2: MEDIATEK MT7921 802.11ax PCI Express Wireless Network Adapter
    vendor: Lenovo driver: mt7921e v: kernel bus-ID: 03:00.0
  IF: wlp3s0 state: up mac: <filter>
  IF-ID-1: docker0 state: down mac: <filter>
  IF-ID-2: it-mil-wg-002 state: unknown speed: N/A duplex: N/A mac: N/A
Bluetooth:
  Device-1: Foxconn / Hon Hai MediaTek Bluetooth Adapter driver: btusb v: 0.8
    type: USB bus-ID: 3-4:3
  Report: btmgmt ID: hci0 rfk-id: 1 state: down bt-service: enabled,running
    rfk-block: hardware: no software: yes address: <filter> bt-v: 5.2 lmp-v: 11
Drives:
  Local Storage: total: 9.56 TiB used: 2.24 TiB (23.4%)
  ID-1: /dev/nvme0n1 vendor: Micron model: MTFDKCD512TFK size: 476.94 GiB
    temp: 36.9 C
  ID-2: /dev/nvme1n1 vendor: Kingston model: SNV2S4000G size: 3.64 TiB
    temp: 50.9 C
  ID-3: /dev/sda vendor: Crucial model: CT1000P1SSD8 size: 931.51 GiB
    type: USB
  ID-4: /dev/sdb vendor: Seagate model: Expansion+ size: 3.64 TiB type: USB
  ID-5: /dev/sdc vendor: Western Digital model: WD10JMVW-11AJGS4
    size: 931.48 GiB type: USB
Partition:
  ID-1: / size: 475.34 GiB used: 162.56 GiB (34.2%) fs: btrfs dev: /dev/dm-0
    mapped: luks-a5f17555-3e0d-40eb-a300-4442c9d6af5f
  ID-2: /boot size: 973.4 MiB used: 397.6 MiB (40.9%) fs: ext4
    dev: /dev/nvme0n1p2
  ID-3: /boot/efi size: 598.8 MiB used: 19 MiB (3.2%) fs: vfat
    dev: /dev/nvme0n1p1
  ID-4: /home size: 475.34 GiB used: 162.56 GiB (34.2%) fs: btrfs
    dev: /dev/dm-0 mapped: luks-a5f17555-3e0d-40eb-a300-4442c9d6af5f
Swap:
  ID-1: swap-1 type: zram size: 8 GiB used: 0 KiB (0.0%) dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 53.0 C mobo: 48.0 C gpu: amdgpu temp: 48.0 C
  Fan Speeds (rpm): fan-1: 1800 fan-2: 1800
Info:
  Memory: total: 40 GiB note: est. available: 38 GiB used: 4.33 GiB (11.4%)
  Processes: 448 Uptime: 2h 55m Init: systemd target: graphical (5)
  Packages: 25 Compilers: N/A Shell: Bash v: 5.2.26 inxi: 3.3.34

That sounds valid and explains the mismatch in sizes I noted in the other thread. Thank you for the additional information.

To dig just a little deeper into the ram issue:

  1. Are you 100% certain that the newly installed ram is compatible and identical to the replaced sodimm so there is not a potential issue with mismatched memory.
  2. Are you 100% certain that the system will function properly with that sodimm? The laptop manual should show what memory is supported and in what sizes.
  3. Have you updated the laptop firmware (bios) to the latest version so you are certain that bios version may not be an issue.

The freeze/hang that you have described can also be caused by memory problems. To confirm if this is memory or not, could you try removing the new sodimm and reinstall the original 8GB sodimm and see if the problem continues or is solved.

This would be the first troubleshooting step I would suggest since it appears the problem may have appeared after the memory upgrade and you have not specifically indicated that it existed before the memory change or only appeared after.

Are you 100% certain that the newly installed ram is compatible and identical to the replaced sodimm so there is not a potential issue with mismatched memory.

It’s not identical. Should it be?
I replaced an 8gb Samsung with a 32gb Crucial. It’s compatible though, I’m reasonably sure.
It’s this, btw. I have a generally good experience with Crucial and I saw this specific RAM suggested elsewhere a few times for my laptop, so I’d honestly be surprised if the problem was the RAM itself.

Are you 100% certain that the system will function properly with that sodimm? The laptop manual should show what memory is supported and in what sizes.

That is confirmed by the link above. Yes.
Please correct me if you see something I missed though.

Have you updated the laptop firmware (bios) to the latest version so you are certain that bios version may not be an issue.

I don’t have available updates, but last time I updated it was something like a year ago, so long before this change, so I don’t think this could be bios-related, since I never had issues on this laptop before.

you have not specifically indicated that it existed before the memory change or only appeared after

You’re right. No, nothing similar ever happened. That’s why in the other thread I was saying that it’s weird to see 40gb RAM perform worse than 16. Because I never had any problem with 16gb.
This problem started when I did the upgrade, so I don’t need to reinstall the original one, I’m totally sure that everything would be ok with that.

And that’s what I could do eventually, if it turns out that the problem is the RAM, as I would think at the beginning. Since I found the informations I linked though, about those values, I found out I’m not the only one and that my RAM is probably fine, and I just need to add those two lines.
Don’t you agree?

Also @ilikelinux, even though the files are empty, I managed to get some (maybe) useful informations about the current settings with sysctl -a | grep dirty. The output is:

vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200

Did the crucial website tell you this sodimm is valid for your laptop?
I always use their web site tool to recommend compatible memory.

The hang maybe waiting for memory to be flushed to disk.
Check in /proc/meminfo for the amount of dirty memory while doing a file copy. I use something like

watch ‘grep -i dirty /proc/meminfo’

You could also run a memory test to make sure the ram is working.

I would try to do an update with fwupdmgr just in case though. Especially since ATM there seems to be a lot of CPU specific updates happening in the kernel, and firmware updates.

Did the crucial website tell you this sodimm is valid for your laptop?

Yes! It’s explicitly written, more times, in the link I posted.

I always use their web site tool to recommend compatible memory.

Me too, and that’s why I think the RAM is compatible and generally fine.

watch ‘grep -i dirty /proc/meminfo’

Just did it, copying a 19gb folder on an external disk to my NVME.

Dirty: 3055956 kB it’s the highest value it reached.

You could also run a memory test to make sure the ram is working.

How can I do that?

I don’t know if it could count as a “test”, but:

$ free
               total        used        free      shared  buff/cache   available
Mem:        39850068     3415652    20070792       40348    16929660    36434416
Swap:        8388604         768     8387836

I should add that, for some reason, this last transfer I did hasn’t created the issue…

That’s really weird.
The freezes did happen when I, after a fresh install, copy all my old ~ folders from my backup external NVME to my laptop’s NVME.
It happened consistently and several times with 40gb of RAM on Fedora, Debian and Arch, and never happened before with 16gb, on any distro.

Now for the test I tried to move again my ~/Music folder from the backup to my disk, and it didn’t freeze at all :thinking:

The freezes has always been a bit random and not accurately reproducible, but I can’t reproduce it at all right now for some reason…I’m a bit confused at this point :sweat_smile:

$ fwupdmgr
Command not found

Use fwupdmgr --help for help

Could you please point me to the correct way to use it? fwupd is installed.

Hello @loyak ,
fwupdmgr update will do the job if there is an update for any of your firmware that it can do it will do it, it will also show what it can update but has no new firmware for. Also, for info on Fedora commands, fwupdmgr --help or for more details man fwupdmgr. Basically almost everything comes with --help or a manpage.

I suggest you look at system logs (journalctl) after one of the freezes occurred to find out more about potential causes.

1 Like

This clearly shows that the change of ram is likely the issue, and that the system is unable to properly manage the newer and larger ram.
It may be a poor contact which could possibly be fixed with removing and reseating the sodimm after cleaning the socket with air. It may be an actual hardware issue with a mismatch of the memory settings. There are lots of different criteria to ensure the memory chips are the same and the characteristics of the original 8G sodimm should be available for comparison with the new 32G sodimm. If there are differences in the characteristics posted then you can usually assume an incompatibility.

Checking the information on the link you provided seems to indicate it should be compatible, but it has been known to occasionally receive defective parts.

Thus the approach would be to

  1. perform a full memtest using memtest86+. How that is done is online in many places, including the ability to boot a live memtest86+ image and boot from usb to perform the test.

  2. if any errors are shown then replace the 32G sodimm

  3. potentially revert to the original 8G sodimm (I usually keep older parts for a time after replacement or upgrading)

Just as an afterthought:
Sometimes it is necessary to enter the bios setup and change the memory settings when memory is added or changed. If bios still is configured for only 16G when it actually has 40G that can cause issues. Did you check that?

1 Like
Swap:
  ID-1: swap-1 type: zram size: 8 GiB used: 0 KiB (0.0%) dev: /dev/zram0

What i ment above, your zram has been from the installation 1/2 of total memory space.
Now you are missing 12GB to have the 1/2 ratio.

I would say, beside making the memory tests and checking if Firmware / Bios is correct, a new installation (with the new amount of memory) would be probably the best. This way zram and oter configs will be made automatically by the install process.

Install memtest86+ package. It should add a new item to the grub boot menu to run memtest.

1 Like

That is rather extreme for what is a small config change.
See man zram-generator.conf for how to configure zram.
The default config is in /usr/lib/systemd/zram-generator.conf
And your local config file will go in /etc/systemd/zram-generator.conf
If you need to change from the defaults.

2 Likes

Hi guys. Thank you for your answers, I really appreciate that!

So,

I did it, it shows updates for my NVME, my UEFI dbx and my Logitech Mouse, but I have only the Reinstall button (I’m doing it from gnome-firmware). If I hit it, it prompts me to restart the system after the reinstallation of the firmware and then I just have that Reinstall again, so I guess it’s not an upgrade, just literally a “reinstaller”.
Anyway nothing changes. Thank you, though.

@computersavvy I did check the memory and it’s all okay, no errors. It’s recognized as 40gb and nothing worrying comes up.
To be honest I don’t think I have a faulty RAM, as I said I found various documentation for NVME freezes on systems with large RAM and they all point to the dirty bytes solution, so I think this issue could be considered sort of expected and solved that way. I still could send the RAM back and ask for a refund or a substitution, I just don’t think it’s necessary, since the RAM is correctly recognized and I have no errors.

BUT!

@ilikelinux this confuses me. Are you sure I should have 20gb?
I reinstalled this system a couple of days ago with the new RAM already installed, so reinstall it again would be useless. I’m 100% sure I didn’t touch in anyway the swap, zram or RAM since I have installed this system. This means the configuration I have is made automatically by Fedora.
So it might be a bug with the installer maybe, that is misconfigured it for some reason? I have no idea.

The default config of zram seems to work for almost everyone so I doubt that may be an issue. Some like to have as large a swap space as possible, but I have been happy with the default of 8Gb for a long time so do not plan to change mine…

What do you mean by ‘gnome-firmware’? The fwupdmgr should properly download and install all appropriate firmware updates (including the dbx file). Firmware updates are actually a swap of the original with the newer version so it seems a reinstall but is actually a replacement.

Updates for the nvme could easily be the repair that is addressed by the commands or variables you noted above. I would suggest that update to the nvme firmware and the dbx before altering the system status with those commands.

I have no problem with 8gb swap, I just wanted to make sure that it’s normal to have it and I shouldn’t have more by default, as @ilikelinux was saying.

What do you mean by ‘gnome-firmware’?

It’s just a GUI for fwupd, so I think I already did that. Thank you.

1 Like

memtest86+ just finished with 0 errors!