----- Original Message -----
> root@odroid64-pre:~/crash-7.1.4# ./crash --minimal
> crash> rd linux_banner 30
> ffffffc00186a090: 0000001600000102 0000000000005018 .........P......
> ffffffc00186a0a0: 00000000000115f9 0000001600000102 ................
> ffffffc00186a0b0: 0000000000003e11 0000000000011606 .>..............
> ffffffc00186a0c0: 0000001600000102 00000000000048d4 .........H......
> ffffffc00186a0d0: 0000000000011614 0000001600000102 ................
> ffffffc00186a0e0: 000000000000c2f1 0000000000011648 ........H.......
> ffffffc00186a0f0: 0000001600000102 00000000000048d4 .........H......
> ffffffc00186a100: 0000000000011656 0000001600000102 V...............
> ffffffc00186a110: 0000000000009225 000000000001167d %.......}.......
> ffffffc00186a120: 0000001600000102 000000000000080f ................
> ffffffc00186a130: 0000000000011688 0000001600000102 ................
> ffffffc00186a140: 0000000000006e9f 0000000000011695 .n..............
> ffffffc00186a150: 0000001600000102 000000000000619c .........a......
> ffffffc00186a160: 00000000000116a2 0000001600000102 ................
> ffffffc00186a170: 000000000000574a 00000000000116af JW..............
> crash>
> crash> help -m | grep -e page_offset -e phys_offset
> page_offset: ffffffc000000000
> phys_offset: 1000000
>
> debug: 4
> crash> rd linux_banner
> <addr: ffffffc00186a090 count: 1 flag: 490 (KVADDR)>
> <readmem: ffffffc00186a090, KVADDR, "64-bit KVADDR", 8, (FOE), 7ff6123398>
> <read_dev_mem: addr: ffffffc00186a090 paddr: 286a090 cnt: 8>
> ffffffc00186a090: 0000001600000102 ........
> crash>
>
>
> >Are there more than one "System RAM" sections in your /proc/iomem?
> Just one, the specs on this arm64 board are 2gb of ram
> sparse memory is configured.
> root@odroid64-pre:~/linux# grep -i sparse .config
> CONFIG_SPARSE_IRQ=y
> CONFIG_ARCH_SPARSEMEM_ENABLE=y
> CONFIG_ARCH_SPARSEMEM_DEFAULT=y
> CONFIG_SPARSEMEM_MANUAL=y
> CONFIG_SPARSEMEM=y
> CONFIG_SPARSEMEM_EXTREME=y
> CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
> CONFIG_SPARSEMEM_VMEMMAP=y
> # CONFIG_INPUT_SPARSEKMAP is not set
> # CONFIG_SPARSE_RCU_POINTER is not set
>
> root@odroid64-pre:~/crash-7.1.4# cat /proc/iomem
> 01000000-0fffffff : System RAM
> 01080000-01b21e83 : Kernel code
> 01bff000-01ffefff : Kernel data
> 10200000-77ffffff : System RAM
> c11084c0-c11084d3 : c11084c0.serial
> c1108500-c110851f : /i2c@c1108500
> c1108680-c11086af : c1108680.saradc
> c11087c0-c11087df : /i2c@c11087c0
> c1109880-c110988f : /pinmux
> c8013000-c80137ff : /mhu@c883c400
> c8100014-c810001b : mux
> c8100024-c810002b : gpio
> c810002c-c810002f : pull
> c81004c0-c81004d3 : c81004c0.serial
> c8834120-c8834133 : pull-enable
> c8834430-c883446f : gpio
> c88344b0-c88344d7 : mux
> c88344e8-c88344fb : pull
> c8834540-c8834547 : /ethernet@0xc9410000
> c8838000-c88383ff : c8838000.canvas
> c883c3d8-c883c3df : c1108680.saradc
> c883c400-c883c44b : /mhu@c883c400
> c9410000-c941ffff : /ethernet@0xc9410000
>
> I backported about 15 arm64 patches from upstream to the 3.14 kernel we are on and
> while doing so noticed a few patches regarding PTE calculations
> (I would have to go back and see if any would apply)
> Most appeared to be part of bigger changes to the memory layout
>
> So should I focus on those arm64 PTE and virt patches? I wondered about that but
> why would the kernel boot if those were screwed up...

For the simple unity-mapped kernel virtual addresses that we're dealing with
at this early stage of the crash session, any PTE stuff wouldn't be involved.
That would only come into play later on when translating kernel module and vmalloc()
addresses.  I don't know how any virt patches would affect anything at this early
stage.

Anyway, everything looks "normal" above, except of course, the data that gets
read.  Did you try "crash /proc/kcore"?

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility