[Crash-utility] Heads up: crash command errors with 2.6.24 kernels
Dave Anderson
anderson at redhat.com
Mon Dec 10 15:30:12 UTC 2007
Ken'ichi Ohmichi wrote:
> Hi Dave,
>
> Thank you for crash-4.0-4.11.
>
> Dave Anderson wrote:
>
>>>It should be noted that while version 4.0-4.11 will at least allow
>>>a crash session to initialize, there are several other 2.6.24 related
>>>kernel changes that have broken several key commands. Among them, at
>>>least on x86_64 kernels:
>>>
>>> 1. "kmem -[sS]" fails due to changes in the CONFIG_SLUB code between
>>> 2.6.22 and 2.6.24.
>>> 2. "kmem <address>" doesn't work at all.
>>> 3. "kmem -n" fails to show any pgdat-node related information.
>>> 4. "kmem -f" doesn't work at all.
>>> 5. "kmem -i" doesn't work at all.
>>> 6. "runq" for the CFS scheduler no longer shows any queued tasks,
>>> but only the relevant structure addresses.
>>> 7. The kernel's use of a virtual mem_map array on x86_64 is not
>>> handled, and this may lead to other page struct related errors.
>
>
> This patch fixes #7.
>
Thanks Ken'ichi. I will also add some extra output for the "mach"
command to reflect the VMEMMAP_START virtual memory segment, as
well as for the "help -m" debug output.
I've also got "kmem -n" working again, which required the
recognition of the 2.6.24 kernel's replacement of the singular
"node_online_map" nodemask with its entry in the "node_states[]"
nodemask array. With the two patches combined, "kmem -i" looks
to be working OK.
I'll update the crash.TODO page with the remaining 2.6.24 items.
Presently I'm looking at fixing the CONFIG_SLUB changes, which
are due to the 2.6.24 change of the kmem_cache.cpu_slab[] array
data type, which used to overload the associated page struct:
struct kmem_cache {
...
struct page *cpu_slab[NR_CPUS];
};
to a new kmem_cache_cpu structure:
struct kmem_cache {
...
#ifdef CONFIG_SMP
struct kmem_cache_cpu *cpu_slab[NR_CPUS];
#else
struct kmem_cache_cpu cpu_slab;
#endif
};
Thanks,
Dave
> Thanks
> Ken'ichi Ohmichi
>
> ---
> [PATCH] kmem -p for linux-2.6.24 x86_64.
>
> Since linux-2.6.24, the mem_map (struct page array) is moved to vmalloc space
> called "virtual memory map" on x86_64 like Documentation/x86_64/mm.txt:
>
> Virtual memory map with 4 level page tables:
>
> 0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
> hole caused by [48:63] sign extension
> ffff800000000000 - ffff80ffffffffff (=40 bits) guard hole
> ffff810000000000 - ffffc0ffffffffff (=46 bits) direct mapping of all phys. memory
> ffffc10000000000 - ffffc1ffffffffff (=40 bits) hole
> ffffc20000000000 - ffffe1ffffffffff (=45 bits) vmalloc/ioremap space
> ffffe20000000000 - ffffe2ffffffffff (=40 bits) virtual memory map (1TB)
>
> This patch adds "virtual memory map" to x86_64_IS_VMALLOC_ADDR(), and the sub
> command "kmem -p" can display it properly.
>
>
> Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
> ---
> diff -rpuN a/defs.h b/defs.h
> --- a/defs.h 2007-12-07 00:47:06.000000000 +0900
> +++ b/defs.h 2007-12-07 10:02:13.000000000 +0900
> @@ -2064,6 +2064,8 @@ struct load_module {
> #define PAGE_OFFSET (machdep->machspec->page_offset)
> #define VMALLOC_START (machdep->machspec->vmalloc_start_addr)
> #define VMALLOC_END (machdep->machspec->vmalloc_end)
> +#define VMEMMAP_VADDR (machdep->machspec->vmemmap_vaddr)
> +#define VMEMMAP_END (machdep->machspec->vmemmap_end)
> #define MODULES_VADDR (machdep->machspec->modules_vaddr)
> #define MODULES_END (machdep->machspec->modules_end)
>
> @@ -2084,6 +2086,9 @@ struct load_module {
> #define MODULES_VADDR_2_6_11 0xffffffff88000000
> #define MODULES_END_2_6_11 0xfffffffffff00000
>
> +#define VMEMMAP_VADDR_2_6_24 0xffffe20000000000
> +#define VMEMMAP_END_2_6_24 0xffffe2ffffffffff
> +
> #define USERSPACE_TOP_XEN 0x0000800000000000
> #define PAGE_OFFSET_XEN 0xffff880000000000
> #define VMALLOC_START_ADDR_XEN 0xffffc20000000000
> @@ -3746,6 +3751,8 @@ struct machine_specific {
> ulong page_offset;
> ulong vmalloc_start_addr;
> ulong vmalloc_end;
> + ulong vmemmap_vaddr;
> + ulong vmemmap_end;
> ulong modules_vaddr;
> ulong modules_end;
> ulong phys_base;
> diff -rpuN a/x86_64.c b/x86_64.c
> --- a/x86_64.c 2007-12-07 00:47:06.000000000 +0900
> +++ b/x86_64.c 2007-12-07 10:01:19.000000000 +0900
> @@ -184,6 +184,10 @@ x86_64_init(int when)
> machdep->machspec->modules_vaddr = MODULES_VADDR_2_6_11;
> machdep->machspec->modules_end = MODULES_END_2_6_11;
>
> + /* 2.6.24 layout */
> + machdep->machspec->vmemmap_vaddr = VMEMMAP_VADDR_2_6_24;
> + machdep->machspec->vmemmap_end = VMEMMAP_END_2_6_24;
> +
> machdep->uvtop = x86_64_uvtop_level4;
> break;
>
> @@ -827,6 +831,7 @@ int
> x86_64_IS_VMALLOC_ADDR(ulong vaddr)
> {
> return ((vaddr >= VMALLOC_START && vaddr <= VMALLOC_END) ||
> + (vaddr >= VMEMMAP_VADDR && vaddr <= VMEMMAP_END) ||
> (vaddr >= MODULES_VADDR && vaddr <= MODULES_END));
> }
>
> _
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
More information about the Crash-utility
mailing list