]> pilppa.com Git - linux-2.6-omap-h63xx.git/commitdiff
x86: reserve low 64K on AMI and Phoenix BIOS boxen
authorIngo Molnar <mingo@elte.hu>
Tue, 16 Sep 2008 07:58:02 +0000 (09:58 +0200)
committerIngo Molnar <mingo@elte.hu>
Tue, 16 Sep 2008 07:58:02 +0000 (09:58 +0200)
there's multiple reports about suspend/resume related low memory
corruption in this bugzilla:

  http://bugzilla.kernel.org/show_bug.cgi?id=11237

the common pattern is that the corruption is caused by the BIOS,
and that it affects some portion of the first 64K of physical RAM.

So add a DMI quirk

This will waste 64K RAM on 'good' systems too, but without knowing
the exact nature of this BIOS memory corruption this is the safest
approach.

This might as well solve a wide range of suspend/resume breakages
under Linux.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
arch/x86/kernel/setup.c

index 3109ca37a67c57cc25241b75a9992188705d4dfe..33719544a2244f477fb669f2eb32ec006735e809 100644 (file)
@@ -732,10 +732,10 @@ void start_periodic_check_for_corruption(void)
 static int __init dmi_low_memory_corruption(const struct dmi_system_id *d)
 {
        printk(KERN_NOTICE
-               "%s detected: BIOS corrupts 0xc000, working it around.\n",
+               "%s detected: BIOS may corrupt low RAM, working it around.\n",
                d->ident);
 
-       reserve_early(0xc000, 0xc400, "BIOS quirk");
+       reserve_early(0x0, 0x10000, "BIOS quirk");
 
        return 0;
 }
@@ -749,6 +749,13 @@ static struct dmi_system_id __initdata bad_bios_dmi_table[] = {
                        DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."),
                },
        },
+       {
+               .callback = dmi_low_memory_corruption,
+               .ident = "Phoenix BIOS",
+               .matches = {
+                       DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"),
+               },
+       },
        {}
 };