9:06 p.m.
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.
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(a)mxs.nes.nec.co.jp>
---
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;
_
8:13 a.m.
New subject: [PATCH] display information about "struct page" on SPARSEMEM.
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)
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(a)mxs.nes.nec.co.jp>
---
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
11:09 a.m.
New subject: [PATCH] display information about "struct page" on SPARSEMEM.
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(a)mxs.nes.nec.co.jp>
>
> ---
> 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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
8:40 p.m.
New subject: [PATCH] display information about "struct page" on SPARSEMEM.
Hi Dave,
Dave Anderson wrote:
> 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?
I have tested this patch on some i386 SPARSEMEM kernels.
non_EXTREME is represented as SPARSEMEM_STATIC on linux source code,
and SPARSEMEM_STATIC is effective on i386 and mips only:
2.6.18-53.el5/arch/i386/Kconfig:616L
config ARCH_SPARSEMEM_ENABLE
def_bool y
depends on (NUMA || (X86_PC && EXPERIMENTAL))
select SPARSEMEM_STATIC
2.6.18-53.el5/arch/mips/Kconfig:1695L
config ARCH_SPARSEMEM_ENABLE
bool
select SPARSEMEM_STATIC
> 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.
Thank you for applying :-)
Thanks
Ken'ichi Ohmichi
6231
days inactive
6234
days old
devel@lists.crash-utility.osci.io
3 comments
2 participants
participants (2)
-
Dave Anderson -
Ken'ichi Ohmichi