Re: [Crash-utility] determining a "valid" vmcore

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 :