3:37 a.m.
On Wed, May 25, 2016 at 11:44:23AM -0400, Dave Anderson wrote:
----- Original Message -----
> >
> > Are you using a mainline kernel (final v4.6, not -rcX)?
>
> Good point. When I configured my arm64 test system, I installed the latest
> Fedora kernel available at the time (4.6.0-0.rc7.git2.1.fc25), but it is based
> upon linux-4.5.tar.xz. I see now that there is a kernel-4.6.0-1.fc25 available
> that is based upon linux-4.6.tar.xz. I'll update the system.
Here's the output from the updated non-randomized live system:
crash> sys
KERNEL: /usr/lib/debug/lib/modules/4.6.0-1.fc25.aarch64/vmlinux
DUMPFILE: /dev/crash
CPUS: 8
DATE: Wed May 25 11:30:06 2016
UPTIME: 00:18:43
LOAD AVERAGE: 0.01, 0.14, 0.17
TASKS: 200
NODENAME: apm-mustang-ev3-36.khw.lab.eng.bos.redhat.com
RELEASE: 4.6.0-1.fc25.aarch64
VERSION: #1 SMP Mon May 16 23:11:08 UTC 2016
MACHINE: aarch64 (unknown Mhz)
MEMORY: 16 GB
crash> log
... [ cut ] ...
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xfffffc0000000000 - 0xfffffc0008000000 ( 128 MB)
[ 0.000000] vmalloc : 0xfffffc0008000000 - 0xfffffdfedfff0000 ( 2043 GB)
[ 0.000000] .text : 0xfffffc0008080000 - 0xfffffc0008890000 ( 8256 KB)
.rodata : 0xfffffc0008890000 - 0xfffffc0008c10000 ( 3584 KB)
.init : 0xfffffc0008c10000 - 0xfffffc0008d50000 ( 1280 KB)
.data : 0xfffffc0008d50000 - 0xfffffc0008eaac00 ( 1387 KB)
[ 0.000000] vmemmap : 0xfffffdfee0000000 - 0xfffffdffe0000000 ( 4 GB
maximum)
0xfffffdfee0000000 - 0xfffffdfee1000000 ( 16 MB
actual)
[ 0.000000] fixed : 0xfffffdfffe7d0000 - 0xfffffdfffec00000 ( 4288 KB)
[ 0.000000] PCI I/O : 0xfffffdfffee00000 - 0xfffffdffffe00000 ( 16 MB)
[ 0.000000] memory : 0xfffffe0000000000 - 0xfffffe0400000000 ( 16384 MB)
...
The starting addresses are OK, but still the vmemmap range looks suspect:
crash> help -m
... [ cut ] ...
VA_BITS: 42
userspace_top: 0000040000000000
page_offset: fffffe0000000000
vmalloc_start_addr: fffffc0008000000
vmalloc_end: fffffdff5ffeffff
modules_vaddr: fffffc0000000000
modules_end: fffffc0007ffffff
vmemmap_vaddr: fffffdff80000000 ???
vmemmap_end: fffffdffffffffff
kimage_text: fffffc0008080000
kimage_end: fffffc0009070000
kimage_voffset: 0000000000000000
phys_offset: 4000000000
...
In my environment,
Virtual kernel memory layout:
modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000087e0000 ( 7552 KB)
.rodata : 0xffff0000087e0000 - 0xffff000008b10000 ( 3264 KB)
.init : 0xffff000008b10000 - 0xffff000008c00000 ( 960 KB)
.data : 0xffff000008c00000 - 0xffff000008ca1e00 ( 648 KB)
.bss : 0xffff000008ca1e00 - 0xffff000008ce4b38 ( 268 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0000900000 ( 9 MB actual)
memory : 0xffff800000000000 - 0xffff800024000000 ( 576 MB)
and,
$ crash ...
KERNEL: ./vmlinux.0526_64_48_nok
DUMPFILE: vmcore.0526_64_48_nok
CPUS: 8 [OFFLINE: 7]
DATE: Thu May 26 12:04:05 2016
UPTIME: 00:00:49
LOAD AVERAGE: 0.13, 0.04, 0.01
TASKS: 100
NODENAME: buildroot_le
RELEASE: 4.6.0+
VERSION: #1 SMP PREEMPT Thu May 26 12:02:41 JST 2016
MACHINE: aarch64 (unknown Mhz)
MEMORY: 512 MB
PANIC: "sysrq: SysRq : Trigger a crash"
PID: 1050
COMMAND: "sh"
TASK: ffff800020679c00 [THREAD_INFO: ffff8000205fc000]
CPU: 0
STATE: TASK_RUNNING (SYSRQ)
crash> help -m
...
VA_BITS: 48
userspace_top: 0001000000000000
page_offset: ffff800000000000
vmalloc_start_addr: ffff000008000000
vmalloc_end: ffff7fdfdffeffff
modules_vaddr: ffff000000000000
modules_end: ffff000007ffffff
vmemmap_vaddr: ffff7fe000000000
vmemmap_end: ffff7fffffffffff
kimage_text: ffff000008080000
kimage_end: ffff000008de0000
kimage_voffset: fffeffff88000000
phys_offset: 80000000
crash> kmem fffffdff80000000
kmem: WARNING: cannot make virtual-to-physical translation: fffffdff80000000
fffffdff80000000: kernel virtual address not found in mem map
crash>
Yeah, I noticed this issue.
But the current crash doesn't support 4-level translation for 4KB now,
I changed the kernel configuration with 64KB page size and
with 48 bit VA (so 3-level), then confirmed that it just worked on
non-randomized kernel, but not on randomized kernel.
The vmemmap address from the log reads OK:
crash> kmem -p | head -10
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
fffffdfee0000000 4000000000 fffffe03dc99f430 1b 2 4003c
referenced,uptodate,dirty,lru,swapbacked
fffffdfee0000040 4000010000 fffffe03dc99f430 1c 2 4003c
referenced,uptodate,dirty,lru,swapbacked
fffffdfee0000080 4000020000 fffffe03dc99f430 1d 2 4003c
referenced,uptodate,dirty,lru,swapbacked
fffffdfee00000c0 4000030000 fffffe03dc99f430 1e 2 4003c
referenced,uptodate,dirty,lru,swapbacked
fffffdfee0000100 4000040000 fffffe03dc99f430 1f 2 4003c
referenced,uptodate,dirty,lru,swapbacked
fffffdfee0000140 4000050000 fffffe03dc99f430 20 2 40078
uptodate,dirty,lru,active,swapbacked
fffffdfee0000180 4000060000 fffffe03dc99f430 21 2 4003c
referenced,uptodate,dirty,lru,swapbacked
fffffdfee00001c0 4000070000 fffffe03dc99f430 22 2 40078
uptodate,dirty,lru,active,swapbacked
fffffdfee0000200 4000080000 0 0 1 400 reserved
... [ cut ] ...
fffffdfee0fffd80 43fff60000 0 0 1 4000000000000400
reserved
fffffdfee0fffdc0 43fff70000 0 0 1 4000000000000400
reserved
fffffdfee0fffe00 43fff80000 0 0 1 4000000000000400
reserved
fffffdfee0fffe40 43fff90000 0 0 1 4000000000000400
reserved
fffffdfee0fffe80 43fffa0000 0 0 1 4000000000000400
reserved
fffffdfee0fffec0 43fffb0000 0 0 1 4000000000000400
reserved
fffffdfee0ffff00 43fffc0000 0 0 1 4000000000000400
reserved
fffffdfee0ffff40 43fffd0000 0 0 1 4000000000000400
reserved
fffffdfee0ffff80 43fffe0000 0 0 1 4000000000000400
reserved
fffffdfee0ffffc0 43ffff0000 0 0 1 4000000000000400
reserved
crash>
And again, the page_offset is fffffe0000000000 with a kernel VA_BITS configuration of
42:
kernel-4.6.0-aarch64.config:CONFIG_ARM64_VA_BITS_42=y
kernel-4.6.0-aarch64.config:# CONFIG_ARM64_VA_BITS_48 is not set
kernel-4.6.0-aarch64.config:CONFIG_ARM64_VA_BITS=42
I think it looks OK.
Thanks,
-Takahiro AKASHI
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
Thanks,
-Takahiro AKASHI