[Crash-utility] kernel module parsing failure - mips

[Sagar Borikar]

On Sun, Dec 4, 2016 at 8:16 AM, Rabin Vincent <rabin at rab.in> wrote:
> On Sun, Dec 04, 2016 at 07:10:38AM -0800, Sagar Borikar wrote:
>> <readmem: 806d2c68, KVADDR, "modules", 4, (FOE), 868e5ec>
>> <read_kdump: addr: 806d2c68 paddr: 6d2c68 cnt: 4>
>> read_netdump: addr: 806d2c68 paddr: 6d2c68 cnt: 4 offset: 5dac68
>> GETBUF(416 -> 0)
>>
> please wait... (gathering module symbol data)module: c0bc9cc0
>> <readmem: c0bc9cc0, KVADDR, "module struct", 416, (ROE|Q), 86b25e0>
>> <readmem: 82c30000, KVADDR, "pgd page", 16384, (FOE), 948a2a0>
>> <read_kdump: addr: 82c30000 paddr: 2c30000 cnt: 16384>
>> read_netdump: addr: 82c30000 paddr: 2c30000 cnt: 16384 offset: 31f8000
>> <readmem: 3018000, PHYSADDR, "page table", 16384, (FOE), 948e2a8>
>> <read_kdump: addr: 3018000 paddr: 3018000 cnt: 16384>
>> read_netdump: addr: 0 paddr: 3018000 cnt: 16384 offset: 35e0000
>> <read_kdump: addr: c0bc9cc0 paddr: 271e9cc0 cnt: 416>
>> 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.
Are you accounting for high memory?

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

Dave,

>  crash> sym -n swapper_pg_dir
>  806d0000 (B) swapper_pg_dir
> 806d1000 (B) invalid_pte_table
>  crash>
>
> What does the command above on your kernel show?

crash>  sym -n swapper_pg_dir
82c30000 (B) swapper_pg_dir
82c34000 (B) invalid_pte_table

Thanks
Sagar


>
>  crash> vtop c01050c0
>  VIRTUAL   PHYSICAL
>  c01050c0  71550c0
>
>  SEGMENT: ksseg
>  PAGE DIRECTORY: 80540000
>    PGD: 805400c0 => 872b0000
>    PTE: 072b0104 => 071545ef
>   PAGE: 07154000
>
>    PTE    PHYSICAL  FLAGS
>  71545ef   7154000  (PRESENT|READ|WRITE|ACCESSED|MODIFIED|GLOBAL|VALID|NO_READ|DIRTY)
>
>    PAGE    PHYSICAL   MAPPING    INDEX CNT FLAGS
>  81038e60   7154000         0         0  1 40000000
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility