* Problem: crashkernel boots at 512MB address in RAM with kexec -l/-e but not with kexec -p
@ 2015-11-12 13:33 HECKEL, Hans (Hans)
2015-11-16 5:35 ` Pratyush Anand
0 siblings, 1 reply; 3+ messages in thread
From: HECKEL, Hans (Hans) @ 2015-11-12 13:33 UTC (permalink / raw)
To: kexec@lists.infradead.org
[-- Attachment #1.1: Type: text/plain, Size: 6150 bytes --]
Dear kexec team,
I hope it is okay to ask you as my public problem description has not
yielded any replies so far. My problem is posted here:
http://unix.stackexchange.com/questions/237580/boot-rescue-kernel-at-high-me
mory-address-using-kexec-on-arm
and also copied below (without the formatting). Update: Same result when
using kernel 4.3 and kexec-tools 2.0.11.
Any help is highly appreciated, and thanks for the work you are putting into
kexec!
Best regards,
Hans Heckel (Alcatel-Lucent, IP Routing and Transport)
Summary: Crashkernel boots at 512MB address in RAM with kexec -l/-e but not
with kexec -p - why?
Embedded platform with Marvell Armada XP (MV78460) (ARMv7 with 4 cores) and
1GB of RAM.
production kernel: customized Linux 3.4.91
rescue kernel: clean kernel.org-Linux (4.2.3) (I am aware that it uses
device trees but that works fine by appending DTB to zImage)
in user-space, I am using the latest kexec-tools (2.0.10)
History: Using kexec -l (with ramdisk and command line params from
3.4.91-kernel, and --atags) and kexec -e, the rescue kernel boots just fine
and seems to place itself in the beginning of RAM (according to /proc/iomem)
regardless of what is being set via --mem-min and --mem-max. When reserving
space in RAM using the boot-option crashkernel, I have to use a high memory
address because otherwise it tells me the requested area is already in use.
So we set crashkernel=128M@512M. The kernel does not boot with kexec -p.
Current status: I understand that relocatable kernels
(CONFIG_AUTO_ZRELADDR=y) must reside within the top 128MB which is not
possible for us. So I have worked around the standard kernel configuration
and forced CONFIG_ARM_PATCH_PHYS_VIRT to no and CONFIG_PHYS_OFFSET to
0x20000000. I had to add a Makefile.boot for the machine where I set
zreladdr-y := 0x20008000, params_phys-y := 0x20000100, initrd_phys-y :=
0x20800000. Now the kernel still boots fine using kexec -l and kexec -e and
according to --mem-min. I can see it is placed at 512MB. However,
configuring it with -p and causing a panic, the console says "Loading
crashdump kernel... Bye!" and remains silent forever.
All files and everything is only located in RAM.
What could I be doing wrong? Should I worry about the decompression errors
(even in the good case)?
From dmesg:
Reserving 128MB of memory at 512MB for crashkernel (System RAM: 760MB)
root@host:~# cat /proc/iomem
00000000-3bff9fff : System RAM
00008000-00724f43 : Kernel code
0076e000-0087553f : Kernel data
20000000-27ffffff : Crash kernel
(some RAM at the end is reserved for persistent storage, that's why it
doesn't add up to 1GB)
Successful case:
root@host:~# kexec -l -t zImage --command-line="console=ttyS0,38400
earlyprintk=ttyS0 root=/dev/ram rdinit=/sbin/init rw irqpoll maxcpus=1
reset_devices" --atags --initrd=./initramfs.cpio.gz -d --mem-min=0x20000000
--mem-max=0x28000000 ./zImage_fixed_addr
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on ./zImage_fixed_addr of 65536 bytes failed
kernel: 0xb6c06008 kernel_size: 0x3db659
kexec_load: entry = 0x20008000 flags = 0x280000
nr_segments = 3
segment[0].buf = 0x40e98
segment[0].bufsz = 0x3f0
segment[0].mem = 0x20001000
segment[0].memsz = 0x1000
segment[1].buf = 0xb6c06008
segment[1].bufsz = 0x3db659
segment[1].mem = 0x20008000
segment[1].memsz = 0x3dc000
segment[2].buf = 0xb5ade008
segment[2].bufsz = 0x1127516
segment[2].mem = 0x20f6e000
segment[2].memsz = 0x1128000
root@host:~# kexec -e
Starting new kernel
Booting Linux on physical CPU 0x0
...
After boot:
root@vanilla:~# cat /proc/iomem
20000000-3fffffff : System RAM
20008000-206dd237 : Kernel code
20720000-2078f54f : Kernel data
Unsuccessful case:
root@host:~# kexec -p -t zImage --command-line="console=ttyS0,38400
earlyprintk=ttyS0 root=/dev/ram rdinit=/sbin/init rw irqpoll maxcpus=1
reset_devices" --atags --initrd=./initramfs.cpio.gz -d ./zImage_fixed_addr
Try gzip decompression
Try LZMA decompression.
lzma_decompress_file: read on ./zImage_fixed_addr of 65536 bytes failed
kernel: 0xb6b69008 kernel_size: 0x3db659
phys_offset: 0
kernel symbol _stext vaddr = c0008240
page_offset is set to c0000000
get_crash_notes_per_cpu: crash_notes addr = 10f525c, size = 1024
Elf header: p_type = 4, p_offset = 0x10f525c p_paddr = 0x10f525c p_vaddr =
0x0 p_filesz = 0x400 p_memsz = 0x400
get_crash_notes_per_cpu: crash_notes addr = 10ff25c, size = 1024
Elf header: p_type = 4, p_offset = 0x10ff25c p_paddr = 0x10ff25c p_vaddr =
0x0 p_filesz = 0x400 p_memsz = 0x400
get_crash_notes_per_cpu: crash_notes addr = 110925c, size = 1024
Elf header: p_type = 4, p_offset = 0x110925c p_paddr = 0x110925c p_vaddr =
0x0 p_filesz = 0x400 p_memsz = 0x400
get_crash_notes_per_cpu: crash_notes addr = 111325c, size = 1024
Elf header: p_type = 4, p_offset = 0x111325c p_paddr = 0x111325c p_vaddr =
0x0 p_filesz = 0x400 p_memsz = 0x400
vmcoreinfo header: p_type = 4, p_offset = 0x7f1330 p_paddr = 0x7f1330
p_vaddr = 0x0 p_filesz = 0x1000 p_memsz = 0x1000
Elf header: p_type = 1, p_offset = 0x0 p_paddr = 0x0 p_vaddr = 0xc0000000
p_filesz = 0x20000000 p_memsz = 0x20000000
Elf header: p_type = 1, p_offset = 0x28000000 p_paddr = 0x28000000 p_vaddr =
0xe8000000 p_filesz = 0x13ffa000 p_memsz = 0x13ffa000
elfcorehdr: 0x27f00000
crashkernel: [0x20000000 - 0x27ffffff] (128M)
memory range: [0 - 0x1fffffff] (512M)
memory range: [0x28000000 - 0x3bff9fff] (319M)
kernel command line: "console=ttyS0,38400 earlyprintk=ttyS0 root=/dev/ram
rdinit=/sbin/init rw irqpoll maxcpus=1 reset_devices elfcorehdr=0x27f00000
mem=130048K"
kexec_load: entry = 0x20008000 flags = 0x280001
nr_segments = 4
segment[0].buf = 0x416e0
segment[0].bufsz = 0x410
segment[0].mem = 0x20001000
segment[0].memsz = 0x1000
segment[1].buf = 0xb6b69008
segment[1].bufsz = 0x3db659
segment[1].mem = 0x20008000
segment[1].memsz = 0x3dc000
segment[2].buf = 0xb5a41008
segment[2].bufsz = 0x1127516
segment[2].mem = 0x20f6e000
segment[2].memsz = 0x1128000
segment[3].buf = 0x412a0
segment[3].bufsz = 0x400
segment[3].mem = 0x27f00000
segment[3].memsz = 0x1000
<cause crash via SysRq>
Loading crashdump kernel...
Bye!
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5215 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Problem: crashkernel boots at 512MB address in RAM with kexec -l/-e but not with kexec -p
2015-11-12 13:33 Problem: crashkernel boots at 512MB address in RAM with kexec -l/-e but not with kexec -p HECKEL, Hans (Hans)
@ 2015-11-16 5:35 ` Pratyush Anand
2015-11-18 7:59 ` HECKEL, Hans (Hans)
0 siblings, 1 reply; 3+ messages in thread
From: Pratyush Anand @ 2015-11-16 5:35 UTC (permalink / raw)
To: HECKEL, Hans (Hans); +Cc: kexec@lists.infradead.org
On 12/11/2015:01:33:18 PM, HECKEL, Hans (Hans) wrote:
> Dear kexec team,
> I hope it is okay to ask you as my public problem description has not
> yielded any replies so far. My problem is posted here:
> http://unix.stackexchange.com/questions/237580/boot-rescue-kernel-at-high-me
> mory-address-using-kexec-on-arm
> and also copied below (without the formatting). Update: Same result when
> using kernel 4.3 and kexec-tools 2.0.11.
> Any help is highly appreciated, and thanks for the work you are putting into
> kexec!
> Best regards,
> Hans Heckel (Alcatel-Lucent, IP Routing and Transport)
>
>
> Summary: Crashkernel boots at 512MB address in RAM with kexec -l/-e but not
> with kexec -p - why?
>
> Embedded platform with Marvell Armada XP (MV78460) (ARMv7 with 4 cores) and
> 1GB of RAM.
> production kernel: customized Linux 3.4.91
> rescue kernel: clean kernel.org-Linux (4.2.3) (I am aware that it uses
> device trees but that works fine by appending DTB to zImage)
> in user-space, I am using the latest kexec-tools (2.0.10)
>
> History: Using kexec -l (with ramdisk and command line params from
> 3.4.91-kernel, and --atags) and kexec -e, the rescue kernel boots just fine
> and seems to place itself in the beginning of RAM (according to /proc/iomem)
> regardless of what is being set via --mem-min and --mem-max. When reserving
> space in RAM using the boot-option crashkernel, I have to use a high memory
> address because otherwise it tells me the requested area is already in use.
> So we set crashkernel=128M@512M. The kernel does not boot with kexec -p.
>
> Current status: I understand that relocatable kernels
> (CONFIG_AUTO_ZRELADDR=y) must reside within the top 128MB which is not
> possible for us. So I have worked around the standard kernel configuration
> and forced CONFIG_ARM_PATCH_PHYS_VIRT to no and CONFIG_PHYS_OFFSET to
> 0x20000000. I had to add a Makefile.boot for the machine where I set
> zreladdr-y := 0x20008000, params_phys-y := 0x20000100, initrd_phys-y :=
> 0x20800000. Now the kernel still boots fine using kexec -l and kexec -e and
> according to --mem-min. I can see it is placed at 512MB. However,
> configuring it with -p and causing a panic, the console says "Loading
> crashdump kernel... Bye!" and remains silent forever.
>
> All files and everything is only located in RAM.
>
> What could I be doing wrong? Should I worry about the decompression errors
> (even in the good case)?
>
> >From dmesg:
> Reserving 128MB of memory at 512MB for crashkernel (System RAM: 760MB)
>
> root@host:~# cat /proc/iomem
> 00000000-3bff9fff : System RAM
> 00008000-00724f43 : Kernel code
> 0076e000-0087553f : Kernel data
> 20000000-27ffffff : Crash kernel
> (some RAM at the end is reserved for persistent storage, that's why it
> doesn't add up to 1GB)
>
> Successful case:
>
> root@host:~# kexec -l -t zImage --command-line="console=ttyS0,38400
> earlyprintk=ttyS0 root=/dev/ram rdinit=/sbin/init rw irqpoll maxcpus=1
> reset_devices" --atags --initrd=./initramfs.cpio.gz -d --mem-min=0x20000000
> --mem-max=0x28000000 ./zImage_fixed_addr
> Try gzip decompression.
> Try LZMA decompression.
> lzma_decompress_file: read on ./zImage_fixed_addr of 65536 bytes failed
> kernel: 0xb6c06008 kernel_size: 0x3db659
> kexec_load: entry = 0x20008000 flags = 0x280000
> nr_segments = 3
> segment[0].buf = 0x40e98
> segment[0].bufsz = 0x3f0
> segment[0].mem = 0x20001000
> segment[0].memsz = 0x1000
> segment[1].buf = 0xb6c06008
> segment[1].bufsz = 0x3db659
> segment[1].mem = 0x20008000
> segment[1].memsz = 0x3dc000
> segment[2].buf = 0xb5ade008
> segment[2].bufsz = 0x1127516
> segment[2].mem = 0x20f6e000
> segment[2].memsz = 0x1128000
> root@host:~# kexec -e
> Starting new kernel
> Booting Linux on physical CPU 0x0
> ...
>
> After boot:
>
> root@vanilla:~# cat /proc/iomem
> 20000000-3fffffff : System RAM
> 20008000-206dd237 : Kernel code
> 20720000-2078f54f : Kernel data
>
> Unsuccessful case:
>
> root@host:~# kexec -p -t zImage --command-line="console=ttyS0,38400
> earlyprintk=ttyS0 root=/dev/ram rdinit=/sbin/init rw irqpoll maxcpus=1
> reset_devices" --atags --initrd=./initramfs.cpio.gz -d ./zImage_fixed_addr
> Try gzip decompression
> Try LZMA decompression.
> lzma_decompress_file: read on ./zImage_fixed_addr of 65536 bytes failed
> kernel: 0xb6b69008 kernel_size: 0x3db659
> phys_offset: 0
> kernel symbol _stext vaddr = c0008240
> page_offset is set to c0000000
> get_crash_notes_per_cpu: crash_notes addr = 10f525c, size = 1024
> Elf header: p_type = 4, p_offset = 0x10f525c p_paddr = 0x10f525c p_vaddr =
> 0x0 p_filesz = 0x400 p_memsz = 0x400
> get_crash_notes_per_cpu: crash_notes addr = 10ff25c, size = 1024
> Elf header: p_type = 4, p_offset = 0x10ff25c p_paddr = 0x10ff25c p_vaddr =
> 0x0 p_filesz = 0x400 p_memsz = 0x400
> get_crash_notes_per_cpu: crash_notes addr = 110925c, size = 1024
> Elf header: p_type = 4, p_offset = 0x110925c p_paddr = 0x110925c p_vaddr =
> 0x0 p_filesz = 0x400 p_memsz = 0x400
> get_crash_notes_per_cpu: crash_notes addr = 111325c, size = 1024
> Elf header: p_type = 4, p_offset = 0x111325c p_paddr = 0x111325c p_vaddr =
> 0x0 p_filesz = 0x400 p_memsz = 0x400
> vmcoreinfo header: p_type = 4, p_offset = 0x7f1330 p_paddr = 0x7f1330
> p_vaddr = 0x0 p_filesz = 0x1000 p_memsz = 0x1000
> Elf header: p_type = 1, p_offset = 0x0 p_paddr = 0x0 p_vaddr = 0xc0000000
> p_filesz = 0x20000000 p_memsz = 0x20000000
> Elf header: p_type = 1, p_offset = 0x28000000 p_paddr = 0x28000000 p_vaddr =
> 0xe8000000 p_filesz = 0x13ffa000 p_memsz = 0x13ffa000
> elfcorehdr: 0x27f00000
> crashkernel: [0x20000000 - 0x27ffffff] (128M)
> memory range: [0 - 0x1fffffff] (512M)
> memory range: [0x28000000 - 0x3bff9fff] (319M)
> kernel command line: "console=ttyS0,38400 earlyprintk=ttyS0 root=/dev/ram
> rdinit=/sbin/init rw irqpoll maxcpus=1 reset_devices elfcorehdr=0x27f00000
> mem=130048K"
> kexec_load: entry = 0x20008000 flags = 0x280001
> nr_segments = 4
> segment[0].buf = 0x416e0
> segment[0].bufsz = 0x410
> segment[0].mem = 0x20001000
> segment[0].memsz = 0x1000
> segment[1].buf = 0xb6b69008
> segment[1].bufsz = 0x3db659
> segment[1].mem = 0x20008000
> segment[1].memsz = 0x3dc000
> segment[2].buf = 0xb5a41008
> segment[2].bufsz = 0x1127516
> segment[2].mem = 0x20f6e000
> segment[2].memsz = 0x1128000
> segment[3].buf = 0x412a0
> segment[3].bufsz = 0x400
> segment[3].mem = 0x27f00000
> segment[3].memsz = 0x1000
>
> <cause crash via SysRq>
>
> Loading crashdump kernel...
> Bye!
Although not sure, it might happen that your first kernel is corrupting crash
kernel and so you do not see any print even with earlyprintk enabled. [it seems
you are not using purgatory for sha256 verification].
Can you please try to limit memory visible to first kernel(pass mem=512M to 1st
kenrel command line) and see if it improves?
~Pratyush
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: Problem: crashkernel boots at 512MB address in RAM with kexec -l/-e but not with kexec -p
2015-11-16 5:35 ` Pratyush Anand
@ 2015-11-18 7:59 ` HECKEL, Hans (Hans)
0 siblings, 0 replies; 3+ messages in thread
From: HECKEL, Hans (Hans) @ 2015-11-18 7:59 UTC (permalink / raw)
To: Pratyush Anand, kexec@lists.infradead.org
[-- Attachment #1.1: Type: text/plain, Size: 10016 bytes --]
Hi Pratyush,
thanks a lot for looking into my issue.
How do I enable purgatory for the SHA-256 verification?
With respect to limiting the kernel RAM: it oopses if I give only the first
512MB to the production kernel and then 256MB to the crash kernel ("mem=512M
crashkernel=128M@512M"). See details below. Seems like the crash kernel must
be *part* of the system RAM. Using "mem=768M crashkernel=128M@512M" I have
the same behavior as in my original post.
Do the segments from the kexec debug output look correct to you? In the
kexec -l/-e case there are only 3 while in the -p case I have 4 segments.
Details are in my original post.
Any other idea as to what to investigate? How could I check for corruption
of the crash kernel?
Again, thanks a lot. Best regards, Hans
[...]
boot_prep_linux commandline=console=ttyS0,38400 earlyprintk=ttyS0
root=/dev/ram rdinit=/sbin/init rw mem=512M crashkernel=128M@512M
[...]
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
------------[ cut here ]------------
kernel BUG at
/vol/1830sdw/users/hheckel/maxbcm/linux-3.4-ng/mm/bootmem.c:351!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 Not tainted (3.4.91-wr5 #"maxbcm_V01.00.00")
PC is at mark_bootmem+0xd8/0xec
LR is at reserve_bootmem+0x2c/0x30
pc : [<c0737e08>] lr : [<c0738290>] psr: 600001d3
sp : c076ff18 ip : 00000001 fp : c076ff54
r10: c074d5a4 r9 : 00028000 r8 : c0752370
r7 : 00020000 r6 : 00020000 r5 : 00020000 r4 : c075235c
r3 : 00000000 r2 : 00000001 r1 : c0752370 r0 : c0752370
Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
Control: 38c53c7d Table: 00003000 DAC: fffffffd
Process swapper (pid: 0, stack limit = 0xc076e2f0)
Stack: (0xc076ff18 to 0xc0770000)
ff00: c076ff64
c076ff28
ff20: c0731f94 00000001 c076ff4c 20000000 c0785cb0 c0868900 c0785cb0
c074d5a4
ff40: 00000000 c074d5a4 c076ff64 c076ff58 c0738290 c0737d3c c076ffbc
c076ff68
ff60: c0729868 c0738270 c076ff80 c076ff88 20000000 00000000 ffffffff
ffffffff
ff80: 08000000 00000000 20000000 00000000 00000000 00000001 00000000
c074ecb8
ffa0: c0785be4 00007000 562f5842 00000000 c076fff4 c076ffc0 c0725620
c0728f88
ffc0: 00000000 00000000 00000000 00000000 00000000 c074ecbc 00000000
38c73c7d
ffe0: c0780308 c074ecb8 00000000 c076fff8 00008054 c0725598 00000000
00000000
[<c0737e08>] (mark_bootmem+0xd8/0xec) from [<c0738290>]
(reserve_bootmem+0x2c/0x30)
[<c0738290>] (reserve_bootmem+0x2c/0x30) from [<c0729868>]
(setup_arch+0x8ec/0x9e8)
[<c0729868>] (setup_arch+0x8ec/0x9e8) from [<c0725620>]
(start_kernel+0x94/0x3a4)
[<c0725620>] (start_kernel+0x94/0x3a4) from [<00008054>] (0x8054)
Code: e2404014 e2841014 e1580001 1affffd7 (e7f001f2)
---[ end trace 1b75b31a2719ed1c ]---
Kernel panic - not syncing: Fatal exception
-----Original Message-----
From: Pratyush Anand [mailto:panand@redhat.com]
Sent: Montag, 16. November 2015 06:35
To: HECKEL, Hans (Hans)
Cc: kexec@lists.infradead.org
Subject: Re: Problem: crashkernel boots at 512MB address in RAM with kexec
-l/-e but not with kexec -p
On 12/11/2015:01:33:18 PM, HECKEL, Hans (Hans) wrote:
> Dear kexec team,
> I hope it is okay to ask you as my public problem description has not
> yielded any replies so far. My problem is posted here:
> http://unix.stackexchange.com/questions/237580/boot-rescue-kernel-at-h
> igh-me
> mory-address-using-kexec-on-arm
> and also copied below (without the formatting). Update: Same result
> when using kernel 4.3 and kexec-tools 2.0.11.
> Any help is highly appreciated, and thanks for the work you are
> putting into kexec!
> Best regards,
> Hans Heckel (Alcatel-Lucent, IP Routing and Transport)
>
>
> Summary: Crashkernel boots at 512MB address in RAM with kexec -l/-e
> but not with kexec -p - why?
>
> Embedded platform with Marvell Armada XP (MV78460) (ARMv7 with 4
> cores) and 1GB of RAM.
> production kernel: customized Linux 3.4.91 rescue kernel: clean
> kernel.org-Linux (4.2.3) (I am aware that it uses device trees but
> that works fine by appending DTB to zImage) in user-space, I am using
> the latest kexec-tools (2.0.10)
>
> History: Using kexec -l (with ramdisk and command line params from
> 3.4.91-kernel, and --atags) and kexec -e, the rescue kernel boots just
> fine and seems to place itself in the beginning of RAM (according to
> /proc/iomem) regardless of what is being set via --mem-min and
> --mem-max. When reserving space in RAM using the boot-option
> crashkernel, I have to use a high memory address because otherwise it
tells me the requested area is already in use.
> So we set crashkernel=128M@512M. The kernel does not boot with kexec -p.
>
> Current status: I understand that relocatable kernels
> (CONFIG_AUTO_ZRELADDR=y) must reside within the top 128MB which is not
> possible for us. So I have worked around the standard kernel
> configuration and forced CONFIG_ARM_PATCH_PHYS_VIRT to no and
> CONFIG_PHYS_OFFSET to 0x20000000. I had to add a Makefile.boot for the
> machine where I set zreladdr-y := 0x20008000, params_phys-y :=
> 0x20000100, initrd_phys-y := 0x20800000. Now the kernel still boots
> fine using kexec -l and kexec -e and according to --mem-min. I can see
> it is placed at 512MB. However, configuring it with -p and causing a
> panic, the console says "Loading crashdump kernel... Bye!" and remains
silent forever.
>
> All files and everything is only located in RAM.
>
> What could I be doing wrong? Should I worry about the decompression
> errors (even in the good case)?
>
> >From dmesg:
> Reserving 128MB of memory at 512MB for crashkernel (System RAM: 760MB)
>
> root@host:~# cat /proc/iomem
> 00000000-3bff9fff : System RAM
> 00008000-00724f43 : Kernel code
> 0076e000-0087553f : Kernel data
> 20000000-27ffffff : Crash kernel
> (some RAM at the end is reserved for persistent storage, that's why it
> doesn't add up to 1GB)
>
> Successful case:
>
> root@host:~# kexec -l -t zImage --command-line="console=ttyS0,38400
> earlyprintk=ttyS0 root=/dev/ram rdinit=/sbin/init rw irqpoll maxcpus=1
> reset_devices" --atags --initrd=./initramfs.cpio.gz -d
> --mem-min=0x20000000
> --mem-max=0x28000000 ./zImage_fixed_addr Try gzip decompression.
> Try LZMA decompression.
> lzma_decompress_file: read on ./zImage_fixed_addr of 65536 bytes
> failed
> kernel: 0xb6c06008 kernel_size: 0x3db659
> kexec_load: entry = 0x20008000 flags = 0x280000 nr_segments = 3
> segment[0].buf = 0x40e98
> segment[0].bufsz = 0x3f0
> segment[0].mem = 0x20001000
> segment[0].memsz = 0x1000
> segment[1].buf = 0xb6c06008
> segment[1].bufsz = 0x3db659
> segment[1].mem = 0x20008000
> segment[1].memsz = 0x3dc000
> segment[2].buf = 0xb5ade008
> segment[2].bufsz = 0x1127516
> segment[2].mem = 0x20f6e000
> segment[2].memsz = 0x1128000
> root@host:~# kexec -e
> Starting new kernel
> Booting Linux on physical CPU 0x0
> ...
>
> After boot:
>
> root@vanilla:~# cat /proc/iomem
> 20000000-3fffffff : System RAM
> 20008000-206dd237 : Kernel code
> 20720000-2078f54f : Kernel data
>
> Unsuccessful case:
>
> root@host:~# kexec -p -t zImage --command-line="console=ttyS0,38400
> earlyprintk=ttyS0 root=/dev/ram rdinit=/sbin/init rw irqpoll maxcpus=1
> reset_devices" --atags --initrd=./initramfs.cpio.gz -d
> ./zImage_fixed_addr Try gzip decompression Try LZMA decompression.
> lzma_decompress_file: read on ./zImage_fixed_addr of 65536 bytes
> failed
> kernel: 0xb6b69008 kernel_size: 0x3db659
> phys_offset: 0
> kernel symbol _stext vaddr = c0008240
> page_offset is set to c0000000
> get_crash_notes_per_cpu: crash_notes addr = 10f525c, size = 1024 Elf
> header: p_type = 4, p_offset = 0x10f525c p_paddr = 0x10f525c p_vaddr =
> 0x0 p_filesz = 0x400 p_memsz = 0x400
> get_crash_notes_per_cpu: crash_notes addr = 10ff25c, size = 1024 Elf
> header: p_type = 4, p_offset = 0x10ff25c p_paddr = 0x10ff25c p_vaddr =
> 0x0 p_filesz = 0x400 p_memsz = 0x400
> get_crash_notes_per_cpu: crash_notes addr = 110925c, size = 1024 Elf
> header: p_type = 4, p_offset = 0x110925c p_paddr = 0x110925c p_vaddr =
> 0x0 p_filesz = 0x400 p_memsz = 0x400
> get_crash_notes_per_cpu: crash_notes addr = 111325c, size = 1024 Elf
> header: p_type = 4, p_offset = 0x111325c p_paddr = 0x111325c p_vaddr =
> 0x0 p_filesz = 0x400 p_memsz = 0x400
> vmcoreinfo header: p_type = 4, p_offset = 0x7f1330 p_paddr = 0x7f1330
> p_vaddr = 0x0 p_filesz = 0x1000 p_memsz = 0x1000 Elf header: p_type =
> 1, p_offset = 0x0 p_paddr = 0x0 p_vaddr = 0xc0000000 p_filesz =
> 0x20000000 p_memsz = 0x20000000 Elf header: p_type = 1, p_offset =
> 0x28000000 p_paddr = 0x28000000 p_vaddr =
> 0xe8000000 p_filesz = 0x13ffa000 p_memsz = 0x13ffa000
> elfcorehdr: 0x27f00000
> crashkernel: [0x20000000 - 0x27ffffff] (128M) memory range: [0 -
> 0x1fffffff] (512M) memory range: [0x28000000 - 0x3bff9fff] (319M)
> kernel command line: "console=ttyS0,38400 earlyprintk=ttyS0
> root=/dev/ram rdinit=/sbin/init rw irqpoll maxcpus=1 reset_devices
> elfcorehdr=0x27f00000 mem=130048K"
> kexec_load: entry = 0x20008000 flags = 0x280001 nr_segments = 4
> segment[0].buf = 0x416e0
> segment[0].bufsz = 0x410
> segment[0].mem = 0x20001000
> segment[0].memsz = 0x1000
> segment[1].buf = 0xb6b69008
> segment[1].bufsz = 0x3db659
> segment[1].mem = 0x20008000
> segment[1].memsz = 0x3dc000
> segment[2].buf = 0xb5a41008
> segment[2].bufsz = 0x1127516
> segment[2].mem = 0x20f6e000
> segment[2].memsz = 0x1128000
> segment[3].buf = 0x412a0
> segment[3].bufsz = 0x400
> segment[3].mem = 0x27f00000
> segment[3].memsz = 0x1000
>
> <cause crash via SysRq>
>
> Loading crashdump kernel...
> Bye!
Although not sure, it might happen that your first kernel is corrupting
crash kernel and so you do not see any print even with earlyprintk enabled.
[it seems you are not using purgatory for sha256 verification].
Can you please try to limit memory visible to first kernel(pass mem=512M to
1st kenrel command line) and see if it improves?
~Pratyush
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5215 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-11-18 7:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-11-12 13:33 Problem: crashkernel boots at 512MB address in RAM with kexec -l/-e but not with kexec -p HECKEL, Hans (Hans)
2015-11-16 5:35 ` Pratyush Anand
2015-11-18 7:59 ` HECKEL, Hans (Hans)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox