Suspend / Resume doesnt work with 4 GB of RAM (works up to 3 GB)

This has been a problem for a long time. I have a quite old Acer laptop TravelmḾate 5520 (2007/2008), but it is still in good condition and has sufficient power for the kind of calculations I do. I upgraded its RAM from original 1 GB to 2 GB, and later to 4 GB (2x 2GB modules). But the puzzling thing is that when having 4 GB of RAM suspend-to-ram (resume) doesn’t work. I had to use 2+1 GB modules. Totally with 3 GB, suspend/resume works again.

CPU is AMD Turion 64 x2 (2 cores, 64 bit) bud I am still using 32bit openSUSE 11.3 (I don’t want 64bit version). Kernel is -Desktop which contains PAE (and openSUSE showed 4 GB in system information).

I’d love to use 4 GB, though. Any idea?

(Graphics ATI Mobility Radeon 2400XT with fglrx driver.)

I’d check the RAM for errors first. Install ‘memtest86+’, it should (!) create a new entry in your GRUB-menu - let it run for six or eight hours (the longer the better).

You should also describe what “doesn’t work” looks like in detail.

Hi there,
no, there is nothing wrong with the RAM. It was checked by very easy and much quicker test. :wink: Both 2 GB modules were combined with one 1GB module and they worked (including suspend/resume).

Yup, tonight I will try it again, I’ll see what happens.

It was checked by very easy and much quicker test. :wink: Both 2 GB modules were combined with one 1GB module and they worked (including suspend/resume).

There is no such thing as a quick test for checking errors in a RAM. What you did says pretty much nothing about the integrity of your RAM, so I strongly recommend again to test them via memtest (just let it run during your sleep so you won’t have to build up patience).

Why do you think so? None of these modules is faulty. The errors would have had to manifest themselves in some way. The only problem occurs when using 2+2 GB. I haven’t experienced any other problems during last 4 years when using the same modules (first 1 GB, then 1 + 1 GB, then 1 + 2 – > (1a + 2a) OK, (1b + 2a) OK, (1a + 2b) OK, (1b + 2b) OK, (2a + 2b) = Problem with suspend).

I did some tests (I have Ubuntu on the second partition for these occasions):

OPENSUSE 11.3 32BIT DESKTOP KERNEL (With Pae)
KD4 suspend: after a resume, black screen, keyboard dead, hard drive seems to work, after a while high CPU usage
Terminal suspend (just a text mode):

  • s2ram -f: the same as above
  • s2ram -s -f: screen “working” after a resume, but only color pixels displayed and with smaller resolution (in a rectangular field, the rest is black), keyboard works.
  • s2ram -a 3 -s -f: the same, but this time “fullscreen” color pixels.
  • – etc.

Ubuntu 10.10 32bit, Kernel WITHOUT Pae

  • Ubuntu sees only ~ 3,3 GB (obviously) but a resume works (but network doesn’t).
  • Suspend from terminal: OK.

Ubuntu with Pae kernel installed

  • 4 GB available as expected, resuming not working (the same problem as in openSUSE).

Seems that there is a problem with PAE. The only way how to verify it is to install openSUSE 64bit, isn’t it? Oh well, that’s just weird.

(And the funny thing is that /var/log/pm-suspend shows no errors, whatsoever. “Success…”)

You are right, it most likely can not be caused by a specific error within a single RAM.

However, I don’t think there’s a problem with the system not using the complete RAM. You could test it by checking the output of ‘free’ after a while of usage. It should look like this:

kalle@hoppers:~> free
             total       used       free     shared    buffers     cached
Mem:       4076112    3812472     263640          0     249984    2765748
-/+ buffers/cache:     796740    3279372
Swap:      1188804          0    1188804

By the way: this is from a 32bit openSUSE 11.4. PAE works fine here.

Unfortunately I do not know much about s2ram, so let’s hope someone with better ideas jumps in. Good luck!

On 2011-05-21 01:36, OlafCZ wrote:
>
> Why do you think so? None of these modules is faulty. The errors would
> have had to manifest themselves in some way. The only problem occurs
> when using 2+2 GB. I haven’t experienced any other problems during last
> 4 years when using the same modules (first 1 GB, then 1 + 1 GB, then 1 +
> 2 – > (1a + 2a) OK, (1b + 2a) OK, (1a + 2b) OK, (1b + 2b) OK, (2a + 2b)
> = Problem with suspend).

Suspend to ram is often harder to get than suspend to disk. You can try
that. You need a swap larger than 4 G.

There is some info in the wiki about suspend, look for it.

> (And the funny thing is that /var/log/pm-suspend shows no errors,
> whatsoever. “Success…”)

Not really. When the system encounter problems, it is at a state where
nothing can be written to the filesystem, just to swap, because the system
itself is already frozen, stopped. Only the section of the kernel that does
the last part is active. If restoration fails, all the log entries since
the system was frozen are lost.

In the suspend log you can only see messages about the preparation, not
about the suspend itself - very unfortunate.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

Sure, it does show 4 GB of RAM. I didn’t say the opposite. :slight_smile: What I meant was that when 4 GB is present and computer is booted into Ubuntu without PAE (which logically shows only 3,3 GB), suspend-to-ram and resume still works. As soon as the system (both Ubuntu and openSUSE) has 4 GB available (PAE), resuming is just a thing of past.

That kind of helped, don’t you think? Because if there was some HW problem Ubuntu with 4 GB (though with only 3,3 visible due to PAE missing) would have the same problem.

By the way: this is from a 32bit openSUSE 11.4. PAE works fine here.

And suspend/resume works for you? I am starting to think that it might depend on the state of installation – if one doesn’t use 4 GB to start with and install openSUSE with PAE, something goes wrong when additional RAM is added. I don’t really have a clue. (Cuz I read somewhere about similar problem – one guy added extra 1 GB and his Debian or whatever that was started to have problems with resuming from sleep, too.)

Hi there,
no, thanks, I don’t need ‘suspened-to-disk’ which is much slower than a proper boot. :wink:

Suspending to RAM and resuming from that sleep works for me. But only with less than 4 GB of RAM. If I use 3 GB of RAM, everything is fine. If I use 4 GB of RAM, resuming doesn’t work anymore. And I guess it has nothing to do with a disk or even with those hooks I tried (see above). Maybe BIOS? I really don’t know (there is no way to upgrade BIOS – I did it 2 years ago or so, no newer version has been released since).

That looks really like a PAE problem.

One example with SuSE here.

Another Ubuntu example (PAE) here.

‘Many’ people complaing here. (I.E.“PAE enabled kernel (2.6.28-11 server) works on Ubuntu 9.04, enabling me to see 4GB RAM, but I lose the ability to suspend/hibernate.”).

On 05/21/2011 07:36 AM, OlafCZ wrote:
> And suspend/resume works for you? I am starting to think that it might
> depend on the state of installation – if one doesn’t use 4 GB to start
> with and install openSUSE with PAE, something goes wrong when additional
> RAM is added. I don’t really have a clue. (Cuz I read somewhere about
> similar problem – one guy added extra 1 GB and his Debian or whatever
> that was started to have problems with resuming from sleep, too.)

This argument is bogus. The kernel evaluates the memory every time it is booted
and does not keep that kind of information. If you look at the e820 lines found
in the first part of the output of dmesg, you will see the details.

The usual sources of difficulty that surface when adding more memory are (1) bad
memory, (2) BIOS errors, (3) motherboard errors.

With your 4 GB of RAM installed, please post the output of ‘dmesg | grep e820’.

On 2011-05-21 14:36, OlafCZ wrote:

> Hi there,
> no, thanks, I don’t need ‘suspened-to-disk’ which is much slower than a
> proper boot. :wink:

Not here, it is way faster. And it helps to learn more.

Anyway, I think you have to report your findings in a Bugzilla.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

The usual sources of difficulty that surface when adding more memory are (1) bad
memory, (2) BIOS errors, (3) motherboard errors.

With your 4 GB of RAM installed, please post the output of ‘dmesg | grep e820’.

Is there any way to test what went wrong? I was thinking of a limit how much memory can kernel use – I mean there is probably no HW problem becuase when 4 GB of RAM is present and kernel without PAE sees only 3,2-3,3 GB everything works. As soon as 4 GB are available for the kernel things screw up. Let’s say I would tell Linux kernel “use 3,9 GB of RAM”. Is it possible?

Here is the output of dmesg | grep e820. The first part is for 4 GB of RAM, second one for 3 GB.


**4GB**

# dmesg | grep e820
    0.000000]  BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)
    0.000000]  BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
    0.000000]  BIOS-e820: 00000000000d2000 - 0000000000100000 (reserved)
    0.000000]  BIOS-e820: 0000000000100000 - 00000000cfe80000 (usable)
    0.000000]  BIOS-e820: 00000000cfe80000 - 00000000cfe92000 (ACPI data)
    0.000000]  BIOS-e820: 00000000cfe92000 - 00000000cfe94000 (ACPI NVS)
    0.000000]  BIOS-e820: 00000000cfe94000 - 00000000d0000000 (reserved)
    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
    0.000000]  BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
    0.000000]  BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
    0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved)
    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
    0.000000] e820 update range: 00000000d0000000 - 0000000100000000 (usable) ==> (reserved)


**3GB **
# dmesg | grep e820
    0.000000]  BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)
    0.000000]  BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
    0.000000]  BIOS-e820: 00000000000d2000 - 0000000000100000 (reserved)
    0.000000]  BIOS-e820: 0000000000100000 - 00000000bfe80000 (usable)
    0.000000]  BIOS-e820: 00000000bfe80000 - 00000000bfe92000 (ACPI data)
    0.000000]  BIOS-e820: 00000000bfe92000 - 00000000bfe94000 (ACPI NVS)
    0.000000]  BIOS-e820: 00000000bfe94000 - 00000000c0000000 (reserved)
    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
    0.000000]  BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
    0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved)
    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)

On 05/24/2011 08:06 AM, OlafCZ wrote:
>
>>
>>
>> The usual sources of difficulty that surface when adding more memory
>> are (1) bad
>> memory, (2) BIOS errors, (3) motherboard errors.
>>
>> With your 4 GB of RAM installed, please post the output of ‘dmesg |
>> grep e820’.
>
> Is there any way to test what went wrong? I was thinking of a limit how
> much memory can kernel use – I mean there is probably no HW problem
> becuase when 4 GB of RAM is present and kernel without PAE sees only
> 3,2-3,3 GB everything works. As soon as 4 GB are available for the
> kernel things screw up. Let’s say I would tell Linux kernel “use 3,9 GB
> of RAM”. Is it possible?
>
> Here is the output of dmesg | grep e820. The first part is for 4 GB of
> RAM, second one for 3 GB.
>
>
> Code:
> --------------------
>
> 4GB
>
> # dmesg | grep e820
> 0.000000] BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)

The above region is 0 - 640 KB

> 0.000000] BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
> 0.000000] BIOS-e820: 00000000000d2000 - 0000000000100000 (reserved)
> 0.000000] BIOS-e820: 0000000000100000 - 00000000cfe80000 (usable)

1 MB - 3.488 GB

> 0.000000] BIOS-e820: 00000000cfe80000 - 00000000cfe92000 (ACPI data)
> 0.000000] BIOS-e820: 00000000cfe92000 - 00000000cfe94000 (ACPI NVS)
> 0.000000] BIOS-e820: 00000000cfe94000 - 00000000d0000000 (reserved)
> 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
> 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
> 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> 0.000000] BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
> 0.000000] BIOS-e820: 0000000100000000 - 0000000130000000 (usable)

4.294 GB - 5.1000 GB

> 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
> 0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved)
> 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> 0.000000] e820 update range: 00000000d0000000 - 0000000100000000 (usable) ==> (reserved)

Your BIOS is mapping memory with extra holes, which seems to be screwing up the
save to memory.

If you want to limit the memory, it appears that you should use “mem=3.4G” on
the GRUB options line.

Your BIOS is mapping memory with extra holes, which seems to be screwing up the
save to memory.

If you want to limit the memory, it appears that you should use “mem=3.4G” on
the GRUB options line.

Thanks for an interesting suggestion. I have opened a new bug report, anyway – it might relate to Phoenix BIOS and kernel.

0.000000]  BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
0.000000] NX (Execute Disable) protection: active
0.000000] DMI present.
0.000000] **Phoenix BIOS detected: BIOS may corrupt low RAM, working around

it.**
0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable)
==> (reserved)
0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable)
==> (reserved)
0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
0.000000] last_pfn = 0x130000 max_arch_pfn = 0x1000000

More on this: [patch 03/49] x86: reserve low 64K on AMI and Phoenix BIOS boxen](http://fixunix.com/kernel/557785-[patch-03-49]-x86-reserve-low-64k-ami-phoenix-bios-boxen.html)

I tried mem=xx but it didn’t work. I mean system didn’t boot at all. I guess that must be something with GRUB2 (which is used due to Ubuntu on the second partition – will remove it soon).

Is it possible to get around those “bad” memory blocks? I think there were grub parametr “badram”. Aha, there we go:

badram - GNU GRUB Manual 1.99

So in this case, what could I do with that?

On 05/25/2011 11:06 AM, OlafCZ wrote:
>
>>
>>
>> Your BIOS is mapping memory with extra holes, which seems to be
>> screwing up the
>> save to memory.
>>
>> If you want to limit the memory, it appears that you should use
>> “mem=3.4G” on
>> the GRUB options line.
>
> Thanks for an interesting suggestion. I have opened a new bug report,
> anyway – it might relate to Phoenix BIOS and kernel.
>
> 0.000000] BIOS-e820: 0000000100000000 - 0000000130000000
> (usable)
> 0.000000] NX (Execute Disable) protection: active
> 0.000000] DMI present.
> 0.000000] Phoenix BIOS detected: BIOS may corrupt low RAM,
> working around
> it.

> 0.000000] e820 update range: 0000000000000000 - 0000000000010000
> (usable)
> ==> (reserved)
> 0.000000] e820 update range: 0000000000000000 - 0000000000001000
> (usable)
> ==> (reserved)
> 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000
> (usable)
> 0.000000] last_pfn = 0x130000 max_arch_pfn = 0x1000000
>
> More on this: ‘[patch 03/49] x86: reserve low 64K on AMI and Phoenix
> BIOS boxen’ (http://tinyurl.com/3hb2lp7)
>
> I tried mem=xx but it didn’t work. I mean system didn’t boot at all. I
> guess that must be something with GRUB2 (which is used due to Ubuntu on
> the second partition – will remove it soon).
>
> Is it possible to get around those “bad” memory blocks? I think there
> were grub parametr “badram”. Aha, there we go:
>
> ‘badram - GNU GRUB Manual 1.99’
> (http://www.gnu.org/software/grub/manual/html_node/badram.html)
>
> So in this case, what could I do with that?

I know nothing of GRUB2. You are on your own there.

That link probably won’t help as your kernel is getting its memory map from the
BIOS, not from GRUB.