Dave Anderson wrote:
Ken'ichi Ohmichi wrote:
Hi Dave,
This patch fixes the problem that the crash utility cannot display
"struct page" information about SPARSEMEM (not SPARSEMEM_EXTREME)
properly.
The symbol mem_section is defined as the pointer array in
SPARSEMEM_EXTREME.
On the other hand, SPARSEMEM's one is defined as the array of structure
mem_section like the following:
linux-2.6.23/mm/sparse.c:18L
#ifdef CONFIG_SPARSEMEM_EXTREME
struct mem_section *mem_section[NR_SECTION_ROOTS]
____cacheline_internodealigned_in_smp;
#else
struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]
____cacheline_internodealigned_in_smp;
#endif
EXPORT_SYMBOL(mem_section);
The crash utility considers SPARSEMEM's one to be the pointer array,
but it is wrong. This patch fixes it.
Interesting, I've never seen this problem before on any
SPARSEMEM kernels. But perhaps the original contributor
of this patch, and myself, have never run a kernel configured
with CONFIG_SPARSEMEM (i.e., only with CONFIG_SPARSEMEM_EXTREME)?
(I don't have any dumpfiles to check)
Hi Ken'ichi,
I take that back -- I do have several x86_64 RHEL5 dumpfiles, and
as I suspected, all of them are CONFIG_SPARSEMEM_EXTREME. So it
appears that the CONFIG_SPARSEMEM configuration was never tested?
Also, when I was looking at your patch without the full context,
I did not see that the code already has an if-else for the two
configurations, and that you are only changing the CONFIG_SPARSEMEM
section. Sorry for the confusion...
I appreciate your fixing this -- it's queued for the next release.
Thanks again,
Dave
In any case, can you confirm that this patch work for both cases?
In other words, there is a differentiation between the _EXTREME and
the non-EXTREME cases in the crash utility. Should the patch be an
if-else situation?
Dave
The following results are this patch effects.
* Before applying this patch
crash> kmem -p
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
100 0 ------- ----- 0 0
120 1000 ------- ----- 0 0
140 2000 ------- ----- 0 0
160 3000 ------- ----- 0 0
180 4000 ------- ----- 0 0
1a0 5000 ------- ----- 0 0
1c0 6000 ------- ----- 0 0
1e0 7000 ------- ----- 0 0
200 8000 ------- ----- 0 0
[snip]
crash>
* After applying this patch
crash> kmem -p
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
c5000000 0 ------- ----- 1 400
c5000020 1000 ------- ----- 1 400
c5000040 2000 ------- ----- 1 400
c5000060 3000 ------- ----- 1 400
c5000080 4000 ------- ----- 1 400
c50000a0 5000 ------- ----- 1 400
c50000c0 6000 ------- ----- 1 400
c50000e0 7000 ------- ----- 1 400
c5000100 8000 ------- ----- 0 80000
[snip]
crash>
Thanks
Ken'ichi Ohmichi
---
Signed-off-by: Ken'ichi Ohmichi <oomichi@xxxxxxxxxxxxxxxxx>
---
diff -rpuN crash-4.0-4.8.org/memory.c crash-4.0-4.8/memory.c
--- crash-4.0-4.8.org/memory.c 2007-10-31 11:49:16.000000000 +0900
+++ crash-4.0-4.8/memory.c 2007-11-01 10:28:15.000000000 +0900
@@ -12229,7 +12229,9 @@ nr_to_section(ulong nr)
addr = mem_sec[SECTION_NR_TO_ROOT(nr)] + (nr &
SECTION_ROOT_MASK()) * SIZE(mem_section);
else
- addr = mem_sec[0] + (nr & SECTION_ROOT_MASK()) *
SIZE(mem_section);
+ addr = symbol_value("mem_section") +
+ (SECTIONS_PER_ROOT() * SECTION_NR_TO_ROOT(nr) +
+ (nr & SECTION_ROOT_MASK())) * SIZE(mem_section);
if (!IS_KVADDR(addr))
return 0;
_
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility