> -----Original Message----- > From: linux-ia64-owner@xxxxxxxxxxxxxxx > [mailto:linux-ia64-owner@xxxxxxxxxxxxxxx] On Behalf Of Magnus Damm > Sent: 2007年2月14日 19:47 > To: Zou, Nanhai > Cc: vgoyal@xxxxxxxxxx; Horms; fastboot@xxxxxxxxxxxxxx; > linux-ia64@xxxxxxxxxxxxxxx > Subject: Re: Zero size /proc/vmcore on ia64 > > On 2/14/07, Zou, Nanhai <nanhai.zou@xxxxxxxxx> wrote: > > > From: Magnus Damm [mailto:magnus.damm@xxxxxxxxx] > > > On 2/8/07, Vivek Goyal <vgoyal@xxxxxxxxxx> 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. > > Maybe that's a good idea. But that would make ia64 a special case and > I'd like to avoid that as long as possible. > > > Align that buffer to 16M will solve the issue but that seems to be a waste > of the useful memory? > > Right. We could require one granule per segment or something, but at > load time we don't really know if the secondary kernel is using 16M or > 64M granules. A safe bet would be to always use 64M, but that would > require us to use quite a lot of memory for the secondary kernel. > > > Another way is append this elf header to command line in purgatory, like > we append the ummy efi function, maybe this is too hacky? > > Hm. I think that sounds a bit too hackish. =) > > What about the option of marking the ELF headers as EFI_LOADER_DATA > and let the secondary kernel allocate new space and copy the data > early during boot? > Ah yes, I think vmcore.c has already done this, parse and store elf core header structure at kernel init, so mark that area as EFI_CONVENTIONAL_MEMORY should be safe. This can be done by remove the reserved = 1 setting in crashdump-ia64.c Thanks Zou Nan hai > Thanks! > > / magnus > - > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|