Hi Vivek!
On 11/15/06, Vivek Goyal <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 15, 2006 at 08:48:41PM +0900, Magnus Damm wrote:
> > kexec-tools: Don't create hardcoded PT_LOAD header on old kernels (x86_64)
> >
> > This patch improves the kexec binary to avoid creating a PT_LOAD program
> > header
> > for the kernel if enough information cannot be gathered through /proc/kcore.
> > This to avoid avoid hardcoded values and the limitation of only supporting
> > 2MB
> > physical start address (kernel config option CONFIG_PHYSICAL_START).
> >
> > The patch also solves the kexec-tools-testing regression introduced by
> > commit
> > 103c946e39eb9dd57ccbda20ac12ccb01f883c17 - with this patch it is now
> > possible
> > to copy /proc/vmcore on 2.6.18.
> >
>
> Hi Magnus,
>
> Thanks for the patch. My bad that I assumed that first kernel will be
> compiled for address 2MB and hardcoded it if one can not read /proc/kcore.
You are welcome! Thanks for the config! Sorry for not reviewing your
patch earlier and commenting more at that time. I guess getting
everything to work properly is an interative process.
> I had few thoughts
>
> - You mentioned that in previous mail that you changed your compile address
> to 2MB and still problem was not resolved. That means problem should not
> be related to hardcoding the address to 2MB.
Right. After bisecting and finding the problematic commit my first
idea was to comment out the PT_LOAD program header like this:
--- 0001/kexec/arch/x86_64/crashdump-x86_64.c
+++ work/kexec/arch/x86_64/crashdump-x86_64.c 2006-11-15
17:55:18.000000000 +0900
@@ -664,6 +664,7 @@ static int prepare_crash_memory_elf64_he
#endif
}
+#if 0
/* Setup an PT_LOAD type program header for the region where
* Kernel is mapped.
*/
@@ -684,6 +685,8 @@ static int prepare_crash_memory_elf64_he
phdr->p_vaddr, phdr->p_filesz, phdr->p_memsz);
#endif
+#endif
+
/* Setup PT_LOAD type program header for every system RAM chunk.
* A seprate program header for Backup Region*/
for (i = 0; i < CRASH_MAX_MEMORY_RANGES; i++) {
This happened to solve my problem. I retested using 1 MB physical
start address and that seemed to work well too.
I suspect that the hardcoded PT_LOAD program header conflicted with
the kernel command line argument [EMAIL PROTECTED] that I happen to
use. That's my theory.
> Anyway if kernel is compiled for 2MB and user space is hardcoding it to 2MB
> then there is no incompatibility. Secondly, even if incompatibility was
> there I would have expected a trouble while opening the dump using gdb
> instead of while copying the vmcore.
But are you hardcoding it correctly? I must confess that I don't
understand why certain values are hardcoded, especially
KERNEL_TEXT_SIZE. Why is it set to 40M?
> - I think this patch will break compatibility with gdb as we are not mapping
> kernel in virtual address space. All the physical chunks are being mapped
> to linearly mapped region in virtual address space and none is being mapped
> to kernel text virtual address region.
Yes, gdb will not work with the vmcore from kernels that doesn't have
parsable /proc/kcore. But isn't that better than hardcoding and not
being sure that we will be able to transfer the /proc/vmcore file?
My patch makes older kernels behave as they do in the latest
kexec-tools git tree - no PT_LOAD program header for the kernel. And
this is exactly how i386 works at the moment if I'm not mistaken.
> I think there are two options to maintain backward compatibility with
> older kernels.
>
> a) we map 1MB to 40MB physical region in kernel text virtual address space
> instead of kernel linearly mapped region.
>
> b) we relax the elf note check in kexec-tools so that older kernels are
> not incompatible at all and /proc/kcore is readable. What I mean is that
> kexec-tools check for presense of a NULL being present in elf note name
> string. Instead of returning error there, we can print a warning that
> a null character is not present and continue processing kcore. This way
> older kernels will not require any special processing and ELF header
> creation logic will also be very neat.
>
> IMHO, we should go by the second option. What do you think?
Yes, the second option sounds fine. But I see that as an enhancement
for older kernels that can go on top of my patch.
And until someone cooks up such an enhancement I think the best is to
not provide a kernel PT_LOAD program header on old kernels. That
should keep kexec-tools-testing on x86_64 on the same level as
kexec-tools for old kernels which I think is the best way to deal with
backwards compatibility.
/ magnus
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
