Bug 461658

nhorman, FYI -- this was the issue that anderson was talking about on RHKL after I posted my one-line followup patch for 450244.

P.

Ok, thanks.  Just out of curiousity, have you checked to see if the -97.el5 kernel has this problem as well?  I figure I'll start this with a bisection, just as before to see where it broke, since I have known good cores from the -92 kernel

Prarit, Vivek, I just tested 2.6.18-97.el5 on nec-em16.rhts.bos.redhat.com, and crashing it produces a working vmcore file, so something else between -98 and -109 is causing this to happen.

I've got a kernel with your memmap parsing patch removed prarit, and I'll try that next, although for the life of me, I cant see how that is going to cause a malformed vmcore header.

/proc/xen on bare-metal kernels?

> Hi Dave,
>
> Following code in kexec-tools, prepares the elf header for kernel text
> region. (kexec-tools-2.0.0/kexec/crashdump-elf.c). You might want to
> just do gdb and see if we are preparing this header or not at the time of
> loading crashdump kernel.
>
>         /* Setup an PT_LOAD type program header for the region where
>          * Kernel is mapped if info->kern_size is non-zero.
>          */
>
>         if (info->kern_size && !xen_present()) {
>                 phdr = (PHDR *) bufp;
>                 bufp += sizeof(PHDR);
>                 phdr->p_type    = PT_LOAD;
>                 phdr->p_flags   = PF_R|PF_W|PF_X;
>                 phdr->p_offset  = phdr->p_paddr = info->kern_paddr_start;
>                 phdr->p_vaddr   = info->kern_vaddr_start;
>                 phdr->p_filesz  = phdr->p_memsz = info->kern_size;
>                 phdr->p_align   = 0;
>                 (elf->e_phnum)++;
>                 dbgprintf_phdr("Kernel text Elf header", phdr);
>         }
>
> Thanks
> Vivek
>

Well, given kexec-tool's xen_present() is this:

int xen_present(void)
{
        struct stat buf;

        return stat("/proc/xen", &buf) == 0;
}

Then xen_present() would return TRUE on my -109 bare-metal kernel:

  # uname -r
  2.6.18-109.el5.prarit
  # file /proc/xen
  /proc/xen: directory
  #

So it skips the segment...

Is this /proc/xen addition fairly new?

Dave

On an unrelated note, I keep bumping into this error on my test box
with a freshly-installed kexec-tools kexec-tools-1.102pre-36.el5

/etc/init.d/kdump: line 134: [: too many arguments

here:
        if [ -n "$FORCE_REBUILD" -a $modified_files != " " ]
        then
                modified_files="force_rebuild"
        fi

It's because $modified_files is empty.  I'm not sure if it's
symptomatic of some other issue such that $modified_file should
either be a list of files or a space, but I keep getting an
empty string.  So it seems like it should be:

        if [ -n "$FORCE_REBUILD" -a "$modified_files" != " " ]

Dang it!  yes, its rather recent.  The xen people updated the layout of their /proc tree so that all kernels now have a /proc/xen.  I've got another bug on this in the kdump initscript.    Thats probably it

/me is so tired of people changing things in the kernel without testing kdump.

Thats likely it, I'll try write a patch tomorrow.

The modified files thing is queued to be fixed, I've just not checked it in yet.  Sorry about that

*** Bug 461784 has been marked as a duplicate of this bug. ***

As discussed on rhkernel-list and IRC, this is actually a Xen kernel bug, so it
will be fixed there.  Don Dutile is working on it (this is a public announcement for others who happen by here).

*** Bug 461785 has been marked as a duplicate of this bug. ***

Actually, since I'm fairly certain this is because the /proc/xen badness, I'm going to close this one as a dup of 461532.  That just explains the issue in a little more detail, and this should naturally be fixed once that is fixed.

Chris Lalancette

*** This bug has been marked as a duplicate of bug 461532 ***