Confusions with reserve_early, reserve_bootmem, e820, efi, ... onx86_64

[Paul Jackson]

Bernhard, Johannes, Huang, and Yinghai:

I am running into some complications with reserve_bootmem vs
reserve_early, and a reserve_early of "EFI memmap" in the
efi_reserve_early() routine conflicting with reserve_early of
"BIOS reserved" in reserve_ebda_region().

This is on x86_64 arch, using Ingo's x86-latest, with possibly
still buggy EFI firmware in a lab system I'm helping to develop.

I have three concerns:

 1) The find_overlapped_early() check called from reserve_early is
    failing on my lab system , causing panic, when it tries to
    register "EFI memmap" at addresses <0xe0660, 0xe0778> that
    overlaps with the "BIOS reserved" early reserve at addresses
    <0x9f000, 0x100000>

 2) I'm a bit puzzled and concerned when I notice that what had been
    two separate reserve_ebda_region() routines, one for x86 32 and
    one for x86 64 have now become one routine -- the problem being
    that the earlier pair of these two reserve_ebda_region() routines
    were not the same.  They differed by their last line:

	--- /tmp/pj32   2008-06-12 02:09:03.414709042 -0700
	+++ /tmp/pj64   2008-06-12 02:08:42.458348590 -0700
	@@ -33,5 +33,5 @@ static void __init reserve_ebda_region(v
	                lowmem = 0x9f000;
	
	        /* reserve all memory between lowmem and the 1MB mark */
	-       reserve_bootmem(lowmem, 0x100000 - lowmem, BOOTMEM_DEFAULT);
	+       reserve_early(lowmem, 0x100000, "BIOS reserved");
	 }

    Perhaps this is fine ... I was just surprised to see what was
    essentially a change for the x86 32 side from reserve_bootmem(),
    to what is now called in both cases, reserve_early()

 3) Most likely my real problem is with my the EFI firmware on my
    lab system that is still under development.  It might be setting
    up addresses incorrectly.  However I am unable to make sense of
    the several patches in this area over the last week.

    I am unsure if what is there now should work, or whether my
    concern (1) above might indicate a still outstanding issue with
    the current code.

If anything I stated as fact above is incorrect, then I apologize.
I'm not entirely sure I have my details correct here.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@xxxxxxx> 1.940.382.4214
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/