2:30 p.m.
root@odroid64-pre:~/crash-7.1.4# ./crash /proc/kcore
crash 7.1.4
Copyright (C) 2002-2015 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute
it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-unknown-linux-gnu"...
crash: seek error: kernel virtual address: ffffffc000ffe000 type: "pmd
page"
On Tue, Mar 8, 2016 at 2:27 PM, Dave Anderson <anderson(a)redhat.com> wrote:
> ----- 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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility