[Crash-utility] SPARSEMEM, node_online_map, node_data etc...

[Dave Anderson]

> 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
>
>
To avoid any duplication of efforts, I'm starting work on getting
the various "kmem" command options working again for RHEL5-alpha
x86_64 kernels, into which CONFIG_SPARSEMEM was recently introduced,
and CONFIG_NUMA is also configured.  So that particular kernel uses
node_online_map and node_data.  There are going to be some variances
among the different architectures in this area, but we have to start
somewhere.  Expect fairly frequent version updates so that we can
all be on the same page...

Note that the first thing I ran into was a problem with the SPARSEMEM
support patch that I accepted into 4.0-2.22 -- which requires this fix:


--- memory.c    2006-08-22 14:27:51.000000000 -0400
+++ ../next/memory.c    2006-08-24 14:51:25.000000000 -0400
@@ -11374,13 +11374,16 @@ ulong
 pfn_to_map(ulong pfn)
 {
        ulong section, page_offset;
+       ulong section_nr;

-       section = pfn_to_section_nr(pfn);
+       section_nr = pfn_to_section_nr(pfn);
+       if (!(section = valid_section_nr(section_nr)))
+               return 0;

        if (section_has_mem_map(section)) {
-               page_offset = pfn - section_nr_to_pfn(section);
+               page_offset = pfn - section_nr_to_pfn(section_nr);
                return (section_mem_map_addr(section) +
-                       (page_offset * PAGESIZE()));
+                       (page_offset * SIZE(page)));
        }

        return 0;

This SPARSEMEM-only primitive could never have worked
since it was passing a section number into a function
expecting a section address (and even it did work, the
page address calculation was incorrect).  So it always
returned 0, and therefore all of its consumers fail.

Dave


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20060824/0edb4647/attachment.htm>