On Tue, 06 Feb 2007 13:52:37 -0500, Dave Anderson wrote:Yeah, something's not right. I tested the patch on an x86_64,>How about changing section #3 above to something like this?:
>
> * to the section with that page
> */
> if (mi->flags & ADDRESS_SPECIFIED) {
>- ulong pfn = mi->spec_addr >> PAGESHIFT();
>+ ulong pfn;
>+ physaddr_t tmp;
>+
>+ if (pg_spec) {
>+ if (!page_to_phys(mi->spec_addr, &tmp))
>+ return;
>+ pfn = tmp >> PAGESHIFT();
>+ } else
>+ pfn = mi->spec_addr >> PAGESHIFT();
> section_nr = pfn_to_section_nr(pfn);
> }
>Thanks, it looks good, but I found another problem.
I applied your patch and tested kmem command.
crash> kmem -p e000000105090000
PAGE PHYSICAL MAPPING INDEX CNT FLAGSIt seems kmem command entered infinite loop. It is another problem.
I found page_to_phys did not return correct physical address.
When mi->spec_addr is 0xe000000105090000, corresponding physical address
is 0x180000000.> crash> kmem -p | grep e000000105090000
> e000000105090000 180000000 ------- ----- 0 600200080000However, page_to_phys returns 0x100000000. I think page_to_phys does not
support sparsemem system.Takao Indoh
and passed it the page addresses of the first page struct in each
sparsmem section, and it looks like it works OK:
crash> hex
output radix: 16 (hex)
crash> kmem -n
NODE SIZE PGLIST_DATA
BOOTMEM_DATA NODE_ZONES
0 262080 ffff81000000b000
ffffffff804a2e00 ffff81000000b000
ffff81000000bb00
ffff81000000c600
ffff81000000d100
MEM_MAP
START_PADDR START_MAPNR
ffff810009001000 0
0
ZONE NAME
SIZE MEM_MAP
START_PADDR START_MAPNR
0 DMA
4096 ffff810009001000
0 0
1 DMA32 257984
ffff810009039000 1000000
4096
2 Normal
0
0 0
0
3 HighMem
0
0 0
0
-------------------------------------------------------------------
NR SECTION
CODED_MEM_MAP MEM_MAP
PFN
0 ffff810009000000 ffff810009001000 ffff810009001000
0
1 ffff810009000008 ffff810009001000 ffff8100091c1000
8000
2 ffff810009000010 ffff810009001000 ffff810009381000
10000
3 ffff810009000018 ffff810009001000 ffff810009541000
18000
4 ffff810009000020 ffff810009001000 ffff810009701000
20000
5 ffff810009000028 ffff810009001000 ffff8100098c1000
28000
6 ffff810009000030 ffff810009001000 ffff810009a81000
30000
7 ffff810009000038 ffff810009001000 ffff810009c41000
38000
crash>
So for each "MEM_MAP" address above, it should show its physical
address as the "PFN" value shifted into a physical address.
And that seems to work OK:
crash> kmem -p ffff810009001000 ffff8100091c1000 ffff810009381000
ffff810009541000 ffff810009701000 ffff8100098c1000 ffff810009a81000 ffff810009c41000
PAGE
PHYSICAL MAPPING
INDEX CNT FLAGS
ffff810009001000 0
------- ----- 1 400
PAGE
PHYSICAL MAPPING
INDEX CNT FLAGS
ffff8100091c1000 8000000 -------
----- 1 8080000000400
PAGE
PHYSICAL MAPPING
INDEX CNT FLAGS
ffff810009381000 10000000 -------
----- 0 10080000080000
PAGE
PHYSICAL MAPPING
INDEX CNT FLAGS
ffff810009541000 18000000 -------
----- 2 18080000000824
PAGE
PHYSICAL MAPPING
INDEX CNT FLAGS
ffff810009701000 20000000 -------
----- 0 20080000080000
PAGE
PHYSICAL MAPPING
INDEX CNT FLAGS
ffff8100098c1000 28000000 -------
----- 0 28080000080000
PAGE
PHYSICAL MAPPING
INDEX CNT FLAGS
ffff810009a81000 30000000 -------
----- 1 30080000000060
PAGE
PHYSICAL MAPPING
INDEX CNT FLAGS
ffff810009c41000 38000000 -------
----- 1 38080000000000
crash>
But then if I take the last physical address on the machine,
for example:
crash> kmem -p | tail
ffff810009e00dd0 3fff6000 -------
----- 0 0
ffff810009e00e08 3fff7000 -------
----- 0 0
ffff810009e00e40 3fff8000 -------
----- 0 0
ffff810009e00e78 3fff9000 -------
----- 0 0
ffff810009e00eb0 3fffa000 -------
----- 0 0
ffff810009e00ee8 3fffb000 -------
----- 0 0
ffff810009e00f20 3fffc000 -------
----- 0 0
ffff810009e00f58 3fffd000 -------
----- 0 0
ffff810009e00f90 3fffe000 -------
----- 0 0
ffff810009e00fc8 3ffff000 -------
----- 0 0
crash> kmem -p ffff810009e00fc8
PAGE
PHYSICAL MAPPING
INDEX CNT FLAGS
ffff81000922a000 9e00000 -------
----- 1 8080000000400
crash>
...it's incorrect. I don't see any infinite loops though.
But something's out of whack here. I'll take a look and
see what I can find.
Thanks,
Dave
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility