On Sun, Dec 4, 2016 at 1:47 PM, Rabin Vincent <rabin@xxxxxx> wrote: > On Sun, Dec 04, 2016 at 01:07:03PM -0800, Sagar Borikar wrote: >> On Sun, Dec 4, 2016 at 8:16 AM, Rabin Vincent <rabin@xxxxxx> wrote: >> >> read_netdump: READ_ERROR: offset not found for paddr: 271e9cc0 >> >> >> >> crash: read error: kernel virtual address: c0bc9cc0 type: "module struct" >> > >> > Here's the error. Either 271e9cc0 is a valid physical address and the dump is >> > incomplete, or it's not and the page table translation is returning a bogus >> > physical address for c0bc9cc0. >> >> crash> vtop c0bc9cc0 >> VIRTUAL PHYSICAL >> c0bc9cc0 271e9cc0 >> >> SEGMENT: ksseg >> PAGE DIRECTORY: 82c30000 >> PGD: 82c300c0 => 83018000 >> PTE: 03018bc8 => 271e87cf >> PAGE: 271e8000 >> >> PTE PHYSICAL FLAGS >> 271e87cf 271e8000 (PRESENT|WRITE|ACCESSED|MODIFIED|GLOBAL|VALID|DIRTY) >> >> PAGE PHYSICAL MAPPING INDEX CNT FLAGS >> 82dc0f40 271e8000 0 0 1 40000000 >> >> 0x271e9cc0 is a valid address but it belongs to high mem(0x20000000 >> onwards for this platform). Also I don't think there is any problem in >> dump as I have done several testing of crash without modules and every >> time I have got correct result. > > Have a look at the segments at the start of the log. The 271e9cc0 > physical address is apparently not included in the dump: > > pt_load_segment[0]: > file_offset: 8000 > phys_start: 100000 > phys_end: 703fff > zero_fill: 0 > pt_load_segment[1]: > file_offset: 60c000 > phys_start: 44000 > phys_end: 144000 > zero_fill: 0 > pt_load_segment[2]: > file_offset: 70c000 > phys_start: 144000 > phys_end: 4300000 > zero_fill: 0 > pt_load_segment[3]: > file_offset: 48c8000 > phys_start: d200000 > phys_end: d200000 Right. Looked at it in more detail. kexec looks for "System RAM" under /proc/iomem to build the memory segments which are passed to crash notes. But for some reason MIPS kernel doesn't add high mem in /proc/iomem resource list. Refer to arch/mips/kernel/setup.c resource_init() function 729 730 start = boot_mem_map.map[i].addr; 731 end = boot_mem_map.map[i].addr + boot_mem_map.map[i].size - 1; 732 if (start >= HIGHMEM_START) 733 continue; 734 if (end >= HIGHMEM_START) 735 end = HIGHMEM_START - 1; 736 Because of which highmem segment is not passed by kexec. Sagar > >> > To check the page table translation, use "vtop <addr>" (example below) >> > to see how crash comes to its result. You'll have to then manually walk >> > the page tables for this particular virtual address and verify that the >> > correct PGD and PTE entries are being read. It could be easier if use >> > vmalloc_to_page() and page_address() first in your kernel to print out >> > the correct physical address for some known vmalloc'd address. >> >> As the driver works fine, I think kernel translation looks ok. Wrong >> physical address translation would have failed the nvme driver to run. >> Stress testing with the driver is fine. But still would go through the >> PTE entries. > > I wasn't implying that the kernel's virt-to-phys translation was wrong, > but rather that the crash utility's translation might be. But if > 271e9cc0 is a valid physical address on your platform then the > translation itself is probably fine. > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
