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