> -----Original Message----- > From: Magnus Damm [mailto:[EMAIL PROTECTED] > Sent: 2007年2月14日 16:28 > To: [EMAIL PROTECTED] > Cc: Horms; Zou, Nanhai; [email protected]; [email protected] > Subject: Re: Zero size /proc/vmcore on ia64 > > Vivek, everyone, > > On 2/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote: > > I think we should not remove this check because even to parse the info > > passed in ELF headers, you need to first read the ELF headers from crashed > > kernel's memory. So if some programming error has passed wrong location of > > ELF headers (elfcoreheader= invalid location) then we might try reading the > > elf header from a non-existing physical page frame. > > Are you saying that the ELF header is located in the memory space of > the first kernel? > > The way I read the code the ELF header is put into the reserved memory > space for the secondary kernel. At least on ia64 that is true, and I > think the same goes for i386. > > And the fact that the ELF header is put in to the secondary kernel > brings me memory setup problems on ia64. > > Basically the ELF header is marked as EFI_UNUSABLE_MEMORY by the EFI > mangling code in purgatory. The secondary kernel detects this while > parsing the EFI tables and refuses to use/map the other memory present > in the same 16M granule. And in my case the initramfs happens to be > located in the same granule... boom! No good. =) > > So I'm wondering about the reason why we put the ELF header in the > secondary kernel. Can't we just put it in the first kernel and be done > with it? We still point it out using the kernel command line, don't > we?
My first design is that putting data in second kernel is easy and safer. We could put it in the first kernel if we provide an interface to reserve this area at the time of kexec -p so that nobody will touch it even at the time of crash. Align that buffer to 16M will solve the issue but that seems to be a waste of the useful memory? Another way is append this elf header to command line in purgatory, like we append the ummy efi function, maybe this is too hacky? Thanks Zou Nan hai > > Thanks, > > / magnus
_______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
