Heads up: possible 2.6.31 kdump and crash utility failures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



You may have seen this discussion re: 2.6.31 kdump failures on the 
kexec@xxxxxxxxxxxxxxxxxxx mailing list:

  Kdump issue with percpu_alloc=lpage (Was:Re: crash_notes posted to kexec-tools)
  http://lists.infradead.org/pipermail/kexec/2009-October/003587.html

or saw Vivek's subsequent post to LKML to address it:

  [PATCH] Fix kdump failure if booted with percpu_alloc=page
  http://lkml.org/lkml/2009/11/19/214

Basically if a 2.6.31 or later kernel is:

 (1) configured with CONFIG_NEED_MULTIPLE_NODES, and
 (2) the system actually has multiple NUMA nodes,

then it will use vmalloc space for its percpu data.  In that case, the 2.6.31 
kernel uses the "lpage" percpu memory allocator (subsequently renamed the 
"page" allocator) instead of the traditional "embed" percpu memory allocator.

At least on x86_64, this will cause the the crash utility to fail during
initialization, because it tries to read vmalloc memory prior to having
set itself up to be able to walk page tables.

Prior to 4.1.1, it would fail with this error message:

  crash: read error: kernel virtual address: ffffc9000000e2f8  type: cpu number (per_cpu)

With 4.1.1 -- which quietly accepts the readmem failure above -- it fails later on
with these two error messages:

  crash: cannot determine idle task addresses from init_tasks[] or runqueues[]
  crash: cannot resolve "init_task_union"

I believe that this only affects x86_64.  I am testing a fix for it, which
I will put in a new crash release in short order.

Dave

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility

[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux