https://bugzilla.novell.com/show_bug.cgi?id=695758 https://bugzilla.novell.com/show_bug.cgi?id=695758#c4 --- Comment #4 from Oldrich Klimanek <oldrich.klimanek@gmail.com> 2011-05-25 14:20:06 UTC ---
What does it mean "won't resume"? Could you boot with no_console_suspend kernel parameter?
With 3 GB (2+1 modules) everything works. With 3.2 GB available, too (when PAE is disabled, RAM 2x2 GB). With 4 GB available, it looks like that: System is in a sleep mode (no problem suspending to RAM). When trying to resume, during the first 2 or 3 seconds everything looks fine. A hard drive wakes up, keyboard works, backlight turns on. However, then the backlight turns off, keyboard doesn't respond and the fan seems to run too fast (ACPI problem?) I've tried no_console_suspend with no luck. One person from openSUSE forum suggested that it might be BIOS problem (or BIOS vs kernel), namely the way BIOS is maping my RAM. Here is what he wrote: ****************************
# 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. ************************* I guess some would say to upgrade the BIOS. Unfortunately I am using the latest BIOS, there has not been any upgrade for past few years. This bug seems to affect more users (according to various forum posts from around the web). I don't know whether the argument about BIOS is right -- if so, is there any way not to use the certain range in RAM? That would confirm it. And, if you look at the dmesg output you see the following (about Phoenix BIOS) [ 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 "Phoenix BIOS detected: BIOS may corrupt low RAM, working around" -- I found this about a kernel patch which seems important: [patch 03/49] x86: reserve low 64K on AMI and Phoenix BIOS boxen http://fixunix.com/kernel/557785-%5Bpatch-03-49%5D-x86-reserve-low-64k-ami-p... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.