[Crash-utility] Heads up: crash command errors with 2.6.24 kernels

[Ken'ichi Ohmichi]

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 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));
 }
 
_