[Solved] Cannot wakeup from suspend after adding RAM to 32G

d_fajardo · 2023-05-01 06:02:19

I've been having wakeup issues with my desktop from suspend on RAM and this has happened ever since I upgraded and added more RAM modules from 16G to 32G. I can suspend the system OK. If it is just a short period of suspend, let's say a few minutes, the system wakes up OK. However if I suspend it for longer, like overnight for example, the system doesn't wake up - it powers on again, but screen remains blank and after a few seconds the fans go to maximum speed. The only way to come out of it is a hard reset.

I didn't have this problem at all when my system only had 16GB of RAM and I actually think increasing RAM should improve suspend since it means there's more memory to utilize for sleep.

I have tried a few things. I tried using powertop to enable wakeup for the different buses but that didn't solve it. I also have NVIDIA card and have enabled NVreg_PreserveVideoMemoryAllocations and NVreg_TemporaryFilePath variables but that also doesn't help.

The only curious thing I've noticed in dmesg is this:

0.047450] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff]
[    0.047452] PM: hibernation: Registered nosave memory: [mem 0x00058000-0x00058fff]
[    0.047453] PM: hibernation: Registered nosave memory: [mem 0x0009e000-0x000fffff]
[    0.047455] PM: hibernation: Registered nosave memory: [mem 0x88b11000-0x88b11fff]
[    0.047456] PM: hibernation: Registered nosave memory: [mem 0x88b21000-0x88b21fff]
[    0.047456] PM: hibernation: Registered nosave memory: [mem 0x88b22000-0x88b22fff]
[    0.047457] PM: hibernation: Registered nosave memory: [mem 0x88b48000-0x88b48fff]
[    0.047458] PM: hibernation: Registered nosave memory: [mem 0x88bcc000-0x88bccfff]
[    0.047460] PM: hibernation: Registered nosave memory: [mem 0x88bdc000-0x88bdcfff]
[    0.047461] PM: hibernation: Registered nosave memory: [mem 0x8988b000-0x8988bfff]
[    0.047461] PM: hibernation: Registered nosave memory: [mem 0x8988c000-0x8988cfff]
[    0.047462] PM: hibernation: Registered nosave memory: [mem 0x8d643000-0x8d643fff]
[    0.047464] PM: hibernation: Registered nosave memory: [mem 0x8e948000-0x8eca4fff]
[    0.047464] PM: hibernation: Registered nosave memory: [mem 0x8eca5000-0x8ecd2fff]
[    0.047464] PM: hibernation: Registered nosave memory: [mem 0x8ecd3000-0x8f0e7fff]
[    0.047465] PM: hibernation: Registered nosave memory: [mem 0x8f0e8000-0x8fbfefff]
[    0.047466] PM: hibernation: Registered nosave memory: [mem 0x8fc00000-0x8fffffff]
[    0.047467] PM: hibernation: Registered nosave memory: [mem 0x90000000-0xfdffffff]
[    0.047467] PM: hibernation: Registered nosave memory: [mem 0xfe000000-0xfe010fff]
[    0.047467] PM: hibernation: Registered nosave memory: [mem 0xfe011000-0xfebfffff]
[    0.047468] PM: hibernation: Registered nosave memory: [mem 0xfec00000-0xfec00fff]
[    0.047468] PM: hibernation: Registered nosave memory: [mem 0xfec01000-0xfecfffff]
[    0.047469] PM: hibernation: Registered nosave memory: [mem 0xfed00000-0xfed00fff]
[    0.047469] PM: hibernation: Registered nosave memory: [mem 0xfed01000-0xfedfffff]
[    0.047470] PM: hibernation: Registered nosave memory: [mem 0xfee00000-0xfee00fff]
[    0.047470] PM: hibernation: Registered nosave memory: [mem 0xfee01000-0xffffffff]

It seems memory is not being used.

Anything else I can do to diagnose problem? Any other info I can look at for a lead?

Last edited by d_fajardo (2023-05-05 07:20:52)

seth · 2023-05-01 07:06:06

if I suspend it for longer, like overnight for example, the system doesn't wake up - it powers on again, but screen remains blank

I didn't have this problem at all when my system only had 16GB of RAM

I actually think increasing RAM should improve suspend

Yes "should" …

Enter the BIOS/UEFI settings and select the most conservative (slowest) timings for the RAM - "adding later" most likely means "incompatible".
If these are 4 (2x2) DIMMs, make sure to select the proper slots (typically interleaving, consult the boards manual)

d_fajardo · 2023-05-01 07:40:58

"adding later" most likely means "incompatible

I added exactly the same brand and class of modules.
I'll have a look at BIOS thanks.

MadCat_X · 2023-05-01 08:43:41

Is there anything useful in journalctl or does the system not get that far to log anything? Any chance there is a BIOS update available for your MB?

seth · 2023-05-01 12:53:09

Ftr, you wante them from the same batch, brand is pretty much irrelevant.
You may also want to take a look at dmidecode for the present config.

d_fajardo · 2023-05-01 14:48:30

MadCat_X wrote:

Is there anything useful in journalctl or does the system not get that far to log anything? Any chance there is a BIOS update available for your MB?

No much help from journal execept for the dmesg quoted above. And yes I have the most recent BIOS.

seth wrote:

You may also want to take a look at dmidecode for the present config.

I'll have a look at that. Currently I experimented and disabled C6 and C7 states for the CPU in the BIOS and so far system wakes. I'll monitor it further, come back and I'll give an update.

seth · 2023-05-01 14:50:35

The C-states are not the RAM timings, https://en.wikipedia.org/wiki/Memory_timings

d_fajardo · 2023-05-01 15:06:04

The C-states are not the RAM timings

I know.
Memory looks OK though:

Handle 0x0011, DMI type 17, 40 bytes
Memory Device
        Array Handle: 0x0010
        Error Information Handle: Not Provided
        Total Width: 64 bits
        Data Width: 64 bits
        Size: 8 GB
        Form Factor: DIMM
        Set: None
        Locator: ChannelA-DIMM0
        Bank Locator: BANK 0
        Type: DDR4
        Type Detail: Synchronous
        Speed: 2133 MT/s
        Manufacturer: 029E
        Serial Number: 00000000
        Asset Tag: 9876543210
        Part Number: CMK16GX4M2B3200C16  
        Rank: 1
        Configured Memory Speed: 2133 MT/s
        Minimum Voltage: 1.2 V
        Maximum Voltage: 1.2 V
        Configured Voltage: 1.2 V

Handle 0x0012, DMI type 17, 40 bytes
Memory Device
        Array Handle: 0x0010
        Error Information Handle: Not Provided
        Total Width: 64 bits
        Data Width: 64 bits
        Size: 8 GB
        Form Factor: DIMM
        Set: None
        Locator: ChannelA-DIMM1
        Bank Locator: BANK 1
        Type: DDR4
        Type Detail: Synchronous
        Speed: 2133 MT/s
        Manufacturer: 029E
        Serial Number: 00000000
        Asset Tag: 9876543210
        Part Number: CMK16GX4M2B3200C16  
        Rank: 1
        Configured Memory Speed: 2133 MT/s
        Minimum Voltage: 1.2 V
        Maximum Voltage: 1.2 V
        Configured Voltage: 1.2 V

Handle 0x0013, DMI type 17, 40 bytes
Memory Device
        Array Handle: 0x0010
        Error Information Handle: Not Provided
        Total Width: 64 bits
        Data Width: 64 bits
        Size: 8 GB
        Form Factor: DIMM
        Set: None
        Locator: ChannelB-DIMM0
        Bank Locator: BANK 2
        Type: DDR4
        Type Detail: Synchronous
        Speed: 2133 MT/s
        Manufacturer: 029E
        Serial Number: 00000000
        Asset Tag: 9876543210
        Part Number: CMK16GX4M2B3200C16  
        Rank: 1
        Configured Memory Speed: 2133 MT/s
        Minimum Voltage: 1.2 V
        Maximum Voltage: 1.2 V
        Configured Voltage: 1.2 V

Handle 0x0014, DMI type 17, 40 bytes
Memory Device
        Array Handle: 0x0010
        Error Information Handle: Not Provided
        Total Width: 64 bits
        Data Width: 64 bits
        Size: 8 GB
        Form Factor: DIMM
        Set: None
        Locator: ChannelB-DIMM1
        Bank Locator: BANK 3
        Type: DDR4
        Type Detail: Synchronous
        Speed: 2133 MT/s
        Manufacturer: 029E
        Serial Number: 00000000
        Asset Tag: 9876543210
        Part Number: CMK16GX4M2B3200C16  
        Rank: 1
        Configured Memory Speed: 2133 MT/s
        Minimum Voltage: 1.2 V
        Maximum Voltage: 1.2 V
        Configured Voltage: 1.2 V

I'll monitor further and if I get more issues I'll look at RAM timings. Thanks for the lead.

EDIT: @seth It is possible that timing is culprit. I installed higher clock speed RAM modules (they were on sale) of 3200 and my system only allows 3200 in overclock and maxes at 2400 without overclock. I don't overclock. Like I said I shall have a look at this further.

Last edited by d_fajardo (2023-05-01 15:13:48)

MadCat_X · 2023-05-03 07:30:41

d_fajardo wrote:

MadCat_X wrote:
Is there anything useful in journalctl or does the system not get that far to log anything? Any chance there is a BIOS update available for your MB?
No much help from journal execept for the dmesg quoted above. And yes I have the most recent BIOS.

Could you provide a full journald dump all the way up until the point the machine dies? There might be some clues there.

If you're concerned about unreliable memory configuration, you can try to run Prime95 Blend test or Memtest for a couple of hours. If there is a problem, the tests should detect it.

This may be a dumb question but did you try to take the two new modules out to see if it fixes the problem? Does everything work if you run in 16 G with the new modules only?

ewaller · 2023-05-03 14:23:45

Just ensuring we are all on the same sheet of music. When you say suspend, do you mean sleep (or suspend to RAM) or hibernate (suspend to disk). Any chance your system is doing some sort of hybrid sleep where it starts off suspending to RAM, and after a period of time is suspending to disk? This might explain it not awakening after prolonged 'sleep'. If you are, per chance, suspending to disk, did you size your swap partition and or swap file appropriately for the expanded RAM?

I actually think increasing RAM should improve suspend since it means there's more memory to utilize for sleep.

Not sure exactly what you mean by that, but I think you misunderstand what is happening. Dynamic memory can only store a 'bit' for a short period of time before it needs to be 'refreshed' in which it is re-written. This time is measured in milliseconds. If this does not occur, the data stored in memory will just fade away. When your computer sleeps, it actually wakes up hundreds of times a second for the express purpose of refreshing the DRAM. This requires a small amount of energy, but will still drain a laptop battery in a period measured in hours or tens of hours. Adding more memory will not improve upon this.

To reduce the energy use to (practically) zero, systems can write (almost) the entire contents of memory to disk and then power off. At power up, those data are copied back to RAM and the system can be resumed. It appears he stuff you noted in dmesg in your first post indicates what portions of memory are not to be swapped out to disk.

Last edited by ewaller (2023-05-03 14:25:05)

d_fajardo · 2023-05-03 20:54:32

When you say suspend, do you mean sleep (or suspend to RAM) or hibernate (suspend to disk).

I am in fact trying to suspend to RAM.

This requires a small amount of energy, but will still drain a laptop battery in a period measured in hours or tens of hours.

I am on a desktop which is plugged all the time so battery drain is not really relevant. I feel however that the issue could be just that that - RAM seems to be running out of power since occasionally short duration suspend to RAM works. However as in my earlier post, I didn't have this issue before.
I will try hibernation and might be a better option for me.

Prime95 Blend test or Memtest

I don't want to run Memtest quite yet. My computer runs flawlessly other than the sleep issue and Prime95 was the very first stress test I ran after building my PC and the system passed the maximum stress levels without much of an issue.
I am also suspecting NVIDIA might be a the culprit. The card an RTX A4000 has 16G of VRAM and my tmpfs might not have adequate size to preserve graphics. But running df | grep tmpfs shows:

tmpfs            16349216     145164  16204052   1% /dev/shm
tmpfs            17825792      22520  17803272   1% /tmp
tmpfs             3269840         48   3269792   1% /run/user/1000

And I have NVreg_TemporaryFilePath=/tmp. I would think the 17G tmp directory is enough? Though question regarding what the wiki says:

The chosen file system containing the file needs to support unnamed temporary files (e.g. ext4 or XFS) and have sufficient capacity for storing the video memory allocations (i.e. at least 5 percent more than the sum of the memory capacities of all NVIDIA GPUs).

and I'm on BTRFS. Does BTRFS support unnamed temporary files?

V1del · 2023-05-03 21:08:01

The Nvreg_TemporaryFilePath will dump the entirety of the VRAM there and you are basically filling it on suspend. Pick a dir that is not on tmpfs but has sufficient free space. Pretty sure BTRFS supports that as well and you probably want to make the dir you'll designate disable CoW https://wiki.archlinux.org/title/Btrfs#Disabling_CoW

Last edited by V1del (2023-05-03 21:10:42)

d_fajardo · 2023-05-03 21:33:51

@V1del Thanks. I'll have a look at that.
Just for info, this is the log when suspend is triggered:

May 03 22:21:43 taichi-z270 systemd[1]: Reached target Sleep.
May 03 22:21:43 taichi-z270 systemd[1]: Starting NVIDIA system suspend actions...
May 03 22:21:43 taichi-z270 suspend[10629]: nvidia-suspend.service
May 03 22:21:43 taichi-z270 logger[10629]: <13>May  3 22:21:43 suspend: nvidia-suspend.service
May 03 22:21:44 taichi-z270 kernel: snd_hda_codec_hdmi hdaudioC2D0: HDMI: invalid ELD data byte 0
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/ldac
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSink/aptx_hd
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/aptx_hd
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSink/aptx
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/aptx
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSink/aac
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/aac
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSink/sbc
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/sbc
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSink/sbc_xq
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/sbc_xq
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/aptx_ll_1
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/aptx_ll_0
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_1
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_0
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/faststream
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/faststream_duplex
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSink/sbc_xq
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/sbc_xq
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/aptx_ll_1
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/aptx_ll_0
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_1
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_0
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/faststream
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/faststream_duplex
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSink/opus_05
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/opus_05
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSink/opus_05_duplex
May 03 22:21:44 taichi-z270 bluetoothd[697]: Endpoint unregistered: sender=:1.31 path=/MediaEndpoint/A2DPSource/opus_05_duplex
May 03 22:21:45 taichi-z270 systemd[1]: nvidia-suspend.service: Deactivated successfully.
May 03 22:21:45 taichi-z270 systemd[1]: Finished NVIDIA system suspend actions.
May 03 22:21:45 taichi-z270 systemd[1]: Starting System Suspend...
May 03 22:21:45 taichi-z270 systemd-sleep[10637]: Entering sleep state 'suspend'...
May 03 22:21:45 taichi-z270 kernel: PM: suspend entry (deep)

Could the sound system have a bearing on the issue? Not sure what the significance is of those Bluetooth messages just before sleep.
I have to hard reboot the system after this suspend log. No messages for resume.

V1del · 2023-05-03 21:40:22

The bluetooth messages are simply the information that the tool you're using that registers on bluez (e.g. pipewire/pulse) is unregistering from listening (...due to getting suspended I suppose) and shouldn't be inherently problematic.

d_fajardo · 2023-05-05 07:20:32

I set up hibernation in my system - added the resume hook to the kernel and pointed to my swap partition in my kernel parameters. Hibernation works as expected. But what is surprising is suspend to RAM works now as well! It seems to me that the resume hook was what was needed all along.
I'm not really sure if this is now a hybrid suspend but I can't tell the difference between this and the old suspend to RAM.
I've monitored system in different duration of suspend and the system seems to be stable so I will mark this thread as solved. If I encounter any issues I'll post another thread.
Thanks all for the help.

Arch Linux

#1 2023-05-01 06:02:19

[Solved] Cannot wakeup from suspend after adding RAM to 32G

#2 2023-05-01 07:06:06

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#3 2023-05-01 07:40:58

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#4 2023-05-01 08:43:41

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#5 2023-05-01 12:53:09

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#6 2023-05-01 14:48:30

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#7 2023-05-01 14:50:35

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#8 2023-05-01 15:06:04

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#9 2023-05-03 07:30:41

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#10 2023-05-03 14:23:45

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#11 2023-05-03 20:54:32

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#12 2023-05-03 21:08:01

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#13 2023-05-03 21:33:51

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#14 2023-05-03 21:40:22

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

#15 2023-05-05 07:20:32

Re: [Solved] Cannot wakeup from suspend after adding RAM to 32G

Board footer