[Crash-utility] crash version 4.0-3.1 is available

Dave Anderson anderson at redhat.com
Mon Aug 21 12:54:02 UTC 2006


Ken'ichi Ohmichi wrote:

> Hi, Dave.
>
> 2006/08/04 13:55:33 -0400, Dave Anderson <anderson at redhat.com> wrote:
> >- Fix to address 2.6.18 and later Fedora 2.6.17-based kernel data
> >  structure name change from "runqueue" to "rq".  This would cause
> >  crash to fail during initialization with a "crash: cannot determine
> >  idle task addresses from init_tasks[] or runqueues[]" message,
> >  followed by a red herring message: "crash: cannot resolve
> >  init_task_union".  (haren at us.ibm.com)
> I tried doing "kmem -p" for the kdump dumpfile of linux-2.6.17 on
> a x86_64smp system. As a result, crash command displayed the
> following log.
>
> -- log ------------------------------------------------------
>  crash> kmem -p
>        PAGE       PHYSICAL      MAPPING       INDEX CNT FLAGS
>  kmem: WARNING: mem_map[] from 0 to 8000 not accessible
>  kmem: WARNING: mem_map[] from 1000 to 8000 not accessible
>  kmem: WARNING: mem_map[] from 2000 to 8000 not accessible
>  kmem: WARNING: mem_map[] from 3000 to 8000 not accessible
>  kmem: WARNING: mem_map[] from 4000 to 8000 not accessible
>  kmem: WARNING: mem_map[] from 5000 to 8000 not accessible
>  kmem: WARNING: mem_map[] from 6000 to 8000 not accessible
>  kmem: WARNING: mem_map[] from 7000 to 8000 not accessible
>  0                       0      -------       -----   0 0
>  40                   1000      -------       -----   0 0
>  80                   2000      -------       -----   0 0
>  c0                   3000      -------       -----   0 0
>  100                  4000      -------       -----   0 0
>  140                  5000      -------       -----   0 0
>  180                  6000      -------       -----   0 0
> -------------------------------------------------------------
>
> This problem occurred on a linux-2.6.18-rc3 system (x86_64smp).
>
> nt->mem_map in dump_mem_map() was zero, because the above-mentioned
> kernel didn't have necessary symbols(mem_map, pgdat_list, mem_section).
> A symbol "pgdat_list" was removed by the following patch.
>  [PATCH] for_each_online_pgdat (take2) [5/5] remove pgdat_list
>  http://lkml.org/lkml/2006/2/25/8
>
> But this kernel had two symbols(node_online_map, node_data).
> Can we get the node_mem_map of each node by using these symbols?
>

Hi Ken'ichi,

Yes, that will have to be done for these non-CONFIG_SPARSEMEM kernels.

Since we (Red Hat) are converting all kernels to CONFIG_SPARSEMEM,
I don't have a test kernel or kernel/vmcore to work with.

Will you be able to possibly look into adapting node_table_init() and
dump_memory_nodes() for this new design?

Dave


>
> Kernel gets the pglist_data of online nodes in next_online_pgdat() by
> the following method.
> 1. get the online NODE-IDs from "node_online_map".
> 2. get "node_data[NODE_ID]" as the pglist_data of online nodes.
>
> Thanks
> Ken'ichi Ohmichi
>
>






More information about the Crash-utility mailing list