[Crash-utility] determining a "valid" vmcore

[Dave Anderson]

Andrew Hecox wrote:
> On Thu, 2008-02-07 at 15:38 -0500, Dave Anderson wrote:
>> Andrew Hecox wrote:
>>> I get the same: 
>>>
>>> (/boot/System.map-2.6.9-67.0.1.ELhugemem)
>>>
>>> 02323bd8 d log_buf_len
>>>
>>> (/usr/lib/debug/lib/modules/2.6.9-67.0.1.ELhugemem/vmlinux)
>>>
>>> $1 = (int *) 0x2323bd8
>>>
>>> -Andrew
>> So, as Takao suggested, can you dump the incoming vaddr and
>> resultant pfn values in diskdumpmsg.c:read_buffer()?
>>
> 
> The vaddr value is: 36846552.
> 
> -Andrew
> 
>> Dave
>>
>>
> 

OK, so the incoming vaddr is 36846552 is which is 0x2323bd8.
To get a pfn, that hugemem kernel virtual address is passed
through vtop() and then divided by 4096:

static int read_buffer(DumpFile *dump, addr_t vaddr, size_t len, void *buf)
{
         addr_t paddr;
         int block_size = get_page_size();
         unsigned long pfn;
         int ret;
         size_t copy_len, offs;
         void *page_data;

         paddr = vtop(dump, vaddr);
         pfn = paddr / block_size;
         offs = paddr % block_size;

When 0x2323bd8 is run through vtop(), it simply strips off the
hugemem unity-map identifier:

addr_t vtop(DumpFile *dump, addr_t vaddr)
{
         if (strstr("hugemem", dump->utsname->release))
                 return vaddr - 0x02000000L;
         else
                 return vaddr - 0xc0000000L;
}

leaving 0x323bd8 -- which gets divided by the page size of 4096, leaving
a pfn of 0x323.

But you see that the pfn was 271139 (0x42323).  If that is expanded
to a physical address it would be 0x42323000.  It looks like it's
using the non-hugemem value in vtop(), i,e, subtracting c0000000 from
the incoming vaddr.  In other words, 0x2323bd8 - 0xc000000 is
equal to 0x42323bd8.  If that is divided by 4096, you get
the funky pfn of 271139 (0x42323).

Print out the dump->utsname->release string in vtop().  It must
not contain "hugemem".

Dave









: