12:55 p.m.
- 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(a)us.ibm.com)
- Added 4-level pagetable support for ia64. Since this is based
upon whether the kernel was built with CONFIG_PGTABLE_4, the
determination of whether the crash utility uses 4-level page
tables is based upon one of two possibilities: the "automatic"
manner depends upon the kernel also being configured with
CONFIG_IKCONFIG; otherwise it will require the commmand line
option "--machdep vm=4l". (troy.heber(a)hp.com)
- Leveraging Troy Heber's addition of code to dig out and uncompress
in-kernel CONFIG_IKCONFIG data, a new "sys config" command option has
been added, which dumps all of the kernel configuration data.
(anderson(a)redhat.com, troy.heber(a)hp.com)
- Also leveraging the new CONFIG_IKCONFIG data access, the value of HZ
can now be absolutely determined by reading CONFIG_HZ. If the config
data is not available, then the current use of the HZ #define will
be replaced by the use of sysconf(_SC_CLK_TCK) to account for the
upcoming removal of HZ from glibc header files.
(anderson(a)redhat.com, olh(a)suse.de)
- Added a new "--cpus " command line option to work around any
situations where the number of cpus cannot be correctly determined.
This is unlikely to ever be needed, but it was necessary for an ia64
kdexec/kdump development kernel issue that has been addressed.
However it's been left in place as a work around in case the same
thing occurs due to some other circumstance. (anderson(a)redhat.com)
Download from: http://people.redhat.com/anderson
8:26 p.m.
Hi, Dave.
2006/08/04 13:55:33 -0400, Dave Anderson <anderson(a)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(a)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?
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
7:54 a.m.
Ken'ichi Ohmichi wrote:
Hi, Dave.
2006/08/04 13:55:33 -0400, Dave Anderson <anderson(a)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(a)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
6:54 a.m.
Hi Dave.
2006/08/21 08:54:02 -0400, Dave Anderson <anderson(a)redhat.com> wrote:
> 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?
Currently, I'm working on the partial
dump command so that it will work
on SPARSEMEM kernels. Maybe I could work on it after that.
I don't think that this new design is necessary at once. Because
RHEL5-kernel will not have a symbol node_data. I made linux-2.6.18-rc2
of RHEL5-config(from Linda Wang) on i386, x86_64, and ia64 system.
As a result, these kernels didn't have a symbol node_data.
Thanks
Ken'ichi Ohmichi
6671
days inactive
6689
days old
devel@lists.crash-utility.osci.io
3 comments
2 participants
participants (2)
-
Dave Anderson -
Ken'ichi Ohmichi