[Crash-utility] ARM64 (odroid-c2) crash fails to read live kernel

Tue Mar 8 20:30:11 UTC 2016

root at 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 at redhat.com> wrote:

>
>
> ----- Original Message -----
> > root at 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 at 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 at 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 at c1108500
> > c1108680-c11086af : c1108680.saradc
> > c11087c0-c11087df : /i2c at c11087c0
> > c1109880-c110988f : /pinmux
> > c8013000-c80137ff : /mhu at 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 at 0xc9410000
> > c8838000-c88383ff : c8838000.canvas
> > c883c3d8-c883c3df : c1108680.saradc
> > c883c400-c883c44b : /mhu at c883c400
> > c9410000-c941ffff : /ethernet at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20160308/c15886fb/attachment.htm>