Messages in this thread | | | Date | Thu, 12 Jun 2008 10:40:29 -0400 | From | Vivek Goyal <> | Subject | Regarding CONFIG_PHYSICAL_START=16MB in linux-next tree |
| |
Hi Ingo,
I just noticed that configs/i386_defconfig now contains the CONFIG_PHYSICAL_START=0x1000000 (16MB) instead of 1MB.
This change has been introduced by following commit in linux-next tree.
commit 5cb04df8d3f03e37a19f2502591a84156be71772 Author: Ingo Molnar <mingo@elte.hu> Date: Sun May 4 19:49:04 2008 +0200
x86: defconfig updates refresh 32-bit defconfig too, and update the 64-bit configs as well, the defconfig should be much more useful by default, so most of the updates are the enabling of various options.
I think this will break kdump on i386. Now kernel will be compiled for physical address 16MB but effectively it will run from physical address 2MB. Boot loader will load kernel at 1MB and due to alignment restriction of 2MB, kernel will move itself to 2MB address.
Now run time virtual addresses for kernel symbols will be different from compile time virtual address and gdb and crash utilities will not be able to open kernel dumps.
What's the reason that we want to compile the kernel for 16MB address? I guess, probably the intention must have been that we want to run kernel from 16MB physical address by default so that lower memory addresses are available for DMA etc?
If that's the case, we probably also need to change CONFIG_PHYSICAL_ALIGN=16MB, so that first kernel is compiled for 16MB and it runs from 16MB address and kdump is not broken.
The side effect of this will be when same kernel is loaded in reserved memory for kdump operation, it will look for 16MB aligned addresses as compared to 2MB. Asking for 16MB aligned addresses as compared to 2MB aligned addresses is more strict a requirement when second kernel is running in a constrained memory environment.
If that's not the intention, then CONFIG_PHYSICAL_START=1MB should be good. Thanks Vivek
| |