> On Mar 8, 2017, at 4:33 AM, Pratyush Anand <[email protected]> wrote:
> 
> 
> 
> On Wednesday 08 March 2017 05:04 AM, Philip Prindeville wrote:
>> 
> 
> [...]
> 
>> 
>> Tried something like that:
>> 
>> root@PowercodeBMU:/# kexec -p /boot/vmlinuz --reuse-cmdline 
>> --append="irqpoll maxcpus=1 reset_devices 1"
>> Cannot get kernel page_offset_base symbol address
> 
> That you can ignore.
> Following patch will change this error message into warning:
> http://lists.infradead.org/pipermail/kexec/2017-March/018299.html


Done.  Thanks!


> 
>> Cannot load /boot/vmlinuz
> 
> Humm..can you pl run with -d and share debug output.

Sure thing:

root@PowercodeBMU:/# file /tmp/boot/boot/vmlinuz 
/tmp/boot/boot/vmlinuz: Linux kernel x86 boot executable bzImage, version 
4.4.14 (philipp@ubuntu16) #10 Wed Mar 8 17:19:10 UTC 2017, RO-rootFS, swap_dev 
0x2, Normal VGA
root@PowercodeBMU:/# 
root@PowercodeBMU:/# kexec -d -p /tmp/boot/boot/vmlinuz --reuse-cmdline 
--append="irqpoll maxcpus=1 reset_devices 1"
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on /tmp/boot/boot/vmlinuz of 65536 bytes failed
kernel: 0x7f18b2596020 kernel_size: 0x27af20
MEMORY RANGES
0000000000000100-0000000000099bff (0)
0000000000099c00-000000000009ffff (1)
00000000000e0000-00000000000fffff (1)
0000000000100000-00000000cc309fff (0)
00000000cc30a000-00000000cc310fff (3)
00000000cc311000-00000000cc946fff (0)
00000000cc947000-00000000ccb5bfff (1)
00000000ccb5c000-00000000db8b4fff (0)
00000000db8b5000-00000000db957fff (1)
00000000db958000-00000000db96dfff (2)
00000000db96e000-00000000dbac3fff (3)
00000000dbac4000-00000000dbffefff (1)
00000000dbfff000-00000000dbffffff (0)
00000000dd000000-00000000df1fffff (1)
00000000f8000000-00000000fbffffff (1)
00000000fec00000-00000000fec00fff (1)
00000000fed00000-00000000fed03fff (1)
00000000fed1c000-00000000fed1ffff (1)
00000000fee00000-00000000fee00fff (1)
00000000ff000000-00000000ffffffff (1)
0000000100000000-000000041fdfffff (0)
CRASH MEMORY RANGES
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (0)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (0)
0000000000000005-ffffffffffffffff (3)
0000000000000005-ffffffffffffffff (0)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (0)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (2)
0000000000000005-ffffffffffffffff (3)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (0)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (0)
0000000000000130-00007f18b2a21938 (0)
Cannot get kernel page_offset_base symbol address
kernel symbol _stext vaddr =      a0000000005
kernel vaddr = 0xffffffff81000000 size = 0x818000
Memmap after adding segment
0000000000000000-000000000009ffff (0)
Cannot load /tmp/boot/boot/vmlinuz
root@PowercodeBMU:/# 

-Philip



> 
>> root@PowercodeBMU:/#
>> 
> 
> [...]
> 
>>> "crashkernel=" *must* *not* be passed to crash kernel. It is only for the 
>>> primary kernel.
>> 
>> 
>> Okay.  And --reuse-cmdline takes care of stripping that out for you, it 
>> looks like.  That option isn’t discussed in Documentation/kdump/ but it 
>> might be handy to add something about it.
> 
> You should see about it in kexec-tools doc.
> 
> man kexec
> 
>> 
>> 
>> 
>>> 
>>>> 
> 
> [...]
> 
>>>> And assuming that you’re using the same kernel, etc. how does the init.d 
>>>> scripting on the crashdump (2nd instance of the kernel) know that it’s not 
>>>> the nominal kernel?  Do we use /sys/kernel/kexec_loaded for this purpose?  
>>>> Or do we just look for the existence of /proc/vmcore?
>>> 
>>> Yep, you can find /proc/vmcore in 2nd kernel but not in 1st kernel.
>>> /sys/kernel/kexec_crash_loaded  should have 1 in 1st kernel while 0 in 
>>> crash kernel.
>> 
>> 
>> So far I’m seeing the opposite:
>> 
>> root@PowercodeBMU:/# cat /proc/cmdline
>> BOOT_IMAGE=/boot/vmlinuz block2mtd.block2mtd=/dev/sda2,65536,rootfs,5 
>> root=/dev/mtdblock0 rootfstype=squashfs rootwait console=tty0 
>> console=ttyS0,115200n8r noinitrd crashkernel=64M
>> root@PowercodeBMU:/# cat /sys/kernel/kexec_crash_loaded
>> 0
> 
> Because your kexec -p did not succeed yet.
> 
> ~Pratyush


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Reply via email to