Re: kmem command problem (bug ofdump_mem_map_SPARSEMEM?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Takao Indoh wrote:
On Tue, 06 Feb 2007 13:52:37 -0500, Dave Anderson wrote:

>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 FLAGS

It 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 600200080000

However, page_to_phys returns 0x100000000. I think page_to_phys does not
support sparsemem system.

Takao Indoh

Yeah, something's not right.  I tested the patch on an x86_64,
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

[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux