I've made a significant partial/temporary fix.
I was able to use the memmap= kernel cmdline options to apparently keep
the kernel from using the memory that the suspend/resume process is
erroneously writing to:
kernel /vmlinuz-2.6.24.3-trc ro root=LABEL=/3 memmap=exactmap
memmap=636K@0 memmap=4K$636K memmap=3046M@1M memmap=1682K$3668334K
memmap=64M$3094M memmap=64K$4076M memmap=16K$4174944K
memmap=448K$4174976K memmap=24K$4175488K memmap=64K$4078M
memmap=2M$4094M memmap=511M@4097M x12345678
This results in the following output from the kernel:
...
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
BIOS-e820: 0000000000100000 - 00000000dfe5b800 (usable)
BIOS-e820: 00000000dfe5b800 - 00000000e0000000 (reserved)
BIOS-e820: 00000000f4000000 - 00000000f8000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fed18000 - 00000000fed1c000 (reserved)
BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved)
BIOS-e820: 00000000feda0000 - 00000000feda6000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100002000 - 0000000120000000 (usable)
Entering add_active_range(0, 0, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 917083) 1 entries of 256 used
Entering add_active_range(0, 1048578, 1179648) 2 entries of 256 used
end_pfn_map = 1179648
user-defined physical RAM map:
user: 0000000000000000 - 000000000009f000 (usable)
user: 000000000009f000 - 00000000000a0000 (reserved)
user: 0000000000100000 - 00000000be700000 (usable)
user: 00000000dfe5b800 - 00000000e0000000 (reserved)
user: 00000000c1600000 - 00000000c5600000 (reserved)
user: 00000000fec00000 - 00000000fec10000 (reserved)
user: 00000000fed18000 - 00000000fed1c000 (reserved)
user: 00000000fed20000 - 00000000fed90000 (reserved)
user: 00000000feda0000 - 00000000feda6000 (reserved)
user: 00000000fee00000 - 00000000fee10000 (reserved)
user: 00000000ffe00000 - 0000000100000000 (reserved)
user: 0000000100100000 - 0000000120000000 (usable)
Entering add_active_range(0, 0, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 780032) 1 entries of 256 used
Entering add_active_range(0, 1048832, 1179648) 2 entries of 256 used
end_pfn_map = 1179648
...
With this, I loose near 500MB but my tests pass -- I do not see any
memory corruption after the resume. I could get a lot of the 500MB back
if I did not max out the kernel cmdline.
Apparently the problem area is just after be700000.
My 8 month battle seems to have turned into a linux/linux-acpi success
story. Thanks for the kernel cmdline options. I wonder if Vista could do
this?
Thanks,
Ron
Ron Rechenmacher wrote:
More information on is at
http://fnapcf.fnal.gov/~ron/dell_susp_3.5G_2blocks.txt
and http://fnapcf.fnal.gov/~ron/dell_susp_3.5G_2blocks.dmesg.txt
Is there a way to determine which acpi mapping/allocation is not being
honored or is missing and/or using some memmap= kernel param
to get the kernel to stay away from the memory being changed during
suspend/resume? (any other kernel param that might be useful?)
Thanks,
Ron
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
