On Sat, Dec 03, 2016 at 01:15:23PM -0800, Sagar Borikar wrote:
> > So the first error should be fixed properly before attempting "mod". What
> > kernel version is this and what page size do to use?
>
> 4.4.20 kernel and page size is 16K
I'd only tested 4K pages before but I've now provisioned a QEMU Malta machine
with 16K pages. I've now sent a patch to the list which fixes the
definition of __PGD_ORDER. With only that patch, the pgd size errors
are gone and "mod" works for my 16K kernel/dump:
crash> sym -n swapper_pg_dir
80540000 (B) swapper_pg_dir
80544000 (B) invalid_pte_table
crash> sys
KERNEL: vmlinux-16k-unload
DUMPFILES: /var/tmp/ramdump_elf_wZxP65 [temporary ELF header]
rawdump-16k-unload
CPUS: 1
DATE: Sun Dec 4 14:46:08 2016
UPTIME: 00:00:21
LOAD AVERAGE: 0.31, 0.07, 0.02
TASKS: 54
NODENAME: buildroot
RELEASE: 4.4.27-dirty
VERSION: #12 SMP Sun Dec 4 14:45:32 CET 2016
MACHINE: mips (unknown Mhz)
MEMORY: 128 MB
PANIC: "Kernel panic - not syncing: Fatal exception"
crash> help -m | grep -A7 pagesize
pagesize: 16384
pageshift: 14
pagemask: ffffffffffffc000
pageoffset: 3fff
pgdir_shift: 26
ptrs_per_pgd: 64
ptrs_per_pte: 4096
stacksize: 16384
crash> mod
MODULE NAME SIZE OBJECT FILE
c01050c0 null_blk 5333 (not loaded) [CONFIG_KALLSYMS]
With the fixed __PGD_ORDER, PGD_ORDER gets the value zero and that is
correct for my kernel. __PGD_ORDER isn't used anywhere else that in
PGD_ORDER, so even your hack of forcing PGD_ORDER to zero would have
fixed "mod" for me.
So there could be some other additional problem in your case besides the
incorrect __PGD_ORDER. Could you please apply the fix and run crash
with the -d8 argument and post the full log? Thanks.
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
