Hi,
On Fri, Apr 7, 2017 at 5:22 PM, Denys Zagorui
wrote:
> Hello,
>
> I was testing kexec/kdump on ls2085ardb using kexec-tools from:
>
> https://git.linaro.org/people/takahiro.akashi/kexec-tools.git/log/?h=arm64/kdump
>
> and kernel from:
>
> https://git.linaro.org/people/takahiro.akashi/linux-a
Hi,
It seems the latest upstream kexec-tools does support a complete man
page for kdump yet:
DESCRIPTION
kdump does not have a man page yet.
I would propose having a propose having a man page for kdump (as the
feature is quite useful and has matured over time).
I can work to cook up a pa
Hi Ard, James
On Fri, Jun 2, 2017 at 3:25 PM, Ard Biesheuvel
wrote:
> On 2 June 2017 at 08:23, James Morse wrote:
>> Hi Pratyush,
>>
>> On 23/05/17 06:02, Pratyush Anand wrote:
>>> It takes more that 2 minutes to verify SHA in purgatory when vmlinuz image
>>> is around 13MB and initramfs is arou
1f3c0 code 30001
Segmentation fault
Signed-off-by: Bhupesh Sharma
---
makedumpfile.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/makedumpfile.h b/makedumpfile.h
index 7d81bbcf2234..142753d84e8d 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -684,8 +684,9 @@ uns
Hi Sunil,
On Fri, Sep 8, 2017 at 5:20 PM, Sunil Kumar wrote:
> Hi ,
>
> Thanks for replying Pratyush.
>
> I have also seen the zImage support is present for the ppc64, earlier
> my plan was to take this source as reference and port it for ppc.
> But in zImage_ppc64_usage() its clearly written tha
el version is not supported.
>> The makedumpfile operation may be incomplete.
>> [ 1196.252094] makedumpfile[2367]: unhandled signal 11 at
>> 0100f7011ca8 nip 00001001eecc lr 1001f3c0 code 30001
>> Segmentation fault
>>
>>Signed-off-by: Bhupesh Sharma
>>
Hi Hari,
On Mon, Sep 11, 2017 at 2:29 PM, Hari Bathini
wrote:
>
> On Monday 11 September 2017 07:05 AM, Dave Young wrote:
>>
>> Cc more people.
>>
>> On 09/08/17 at 10:10am, Bhupesh Sharma wrote:
>>>
>>> Kernel commit 2f18d533757da3899f4bedab0b2c
1f3c0 code 30001
Segmentation fault
Signed-off-by: Bhupesh Sharma
---
Changes since v1:
- As per Atsushi's comments introduced macros for 4_11 directly
in v2 and use them in arch/ppc64.c
arch/ppc64.c | 8 +++-
makedumpfile.h | 5 +
2 files changed, 12 insertions(+), 1 deletion(-
Hello Yang Shunyong,
On Fri, Nov 10, 2017 at 3:52 PM, Yang Shunyong wrote:
> Hi, All,
> I am trying to enable kdump on ARM64, based on 4.14 kernel. I met
> EFI reserved memory(eg. ACPI tables) being released issue, in function
> arm64_memblock_init() . It will cause the memory attribute inco
Hi Dave,
Cc: arm kernel mailing list for wider distribution
On 11/13/2017 11:13 AM, Dave Young wrote:
In parse_crashkernel_mem, it silently return in case we get zero
bytes in the parsing function. It is useful for debugging for
adding a warning message especially sometimes kernel can not boot
les are only
declared for archs != powerpc.
Signed-off-by: Bhupesh Sharma
---
makedumpfile.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index 6d5fc8b95415..7ce0c6d648aa 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@
165446 yes Free pages
KERN_DATA 6738no Dumpable kernel
data
page size: 65536
Total pages on system: 247808
Total size on system: 16240345088 Byte
Signed-off-by: Bhupesh Sharma
---
makedumpfile.c |
Hi Anil,
On Wed, Nov 29, 2017 at 2:44 PM, Gurumurthy, Anil
wrote:
> Thanks. That did help getting kexec to work.
> However I still do not get a crash dump -
> echo c > /proc/sysrq-trigger does not get a crash dump.
>
> Any thoughts?
Cam you share the console messages you see when the crash kern
On Wed, Nov 29, 2017 at 3:36 PM, Gurumurthy, Anil
wrote:
>
>
> -Original Message-
> From: Bhupesh Sharma [mailto:bhsha...@redhat.com]
> Sent: 29 November 2017 15:16
> To: Gurumurthy, Anil
> Cc: Dave Young ; kexec@lists.infradead.org
> Subject: Re: kdump issues
essage-
> From: Gurumurthy, Anil
> Sent: 29 November 2017 16:02
> To: 'Bhupesh Sharma'
> Cc: Dave Young ; kexec@lists.infradead.org
> Subject: RE: kdump issues with 4.11 kernel
>
>
>
> -Original Message-
> From: Bhupesh Sharma [mailto:bhsha...@r
Thank you.
>
>> On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
>> > On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
>> > wrote:
>> > > On 15 December 2017 at 09:59, AKASHI Takahiro
>> > > wrote:
>> > >> On Wed, Dec 13, 201
Hi Dave,
On Mon, Dec 18, 2017 at 10:46 AM, Dave Young wrote:
> kexec@fedoraproject... is for Fedora kexec scripts discussion, changed it
> to kexec@lists.infradead.org
>
> Also add linux-acpi list
> On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
>> On Fri, Dec 15, 2017 at 3:
On Mon, Dec 18, 2017 at 4:48 PM, AKASHI Takahiro
wrote:
> Bhupesh,
>
> On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote:
>> On Mon, Dec 18, 2017 at 11:24 AM, AKASHI Takahiro
>> wrote:
>> > On Mon, Dec 18, 2017 at 01:16:57PM +0800, Dave Young wrote:
&
On Tue, Dec 19, 2017 at 10:31 AM, AKASHI Takahiro
wrote:
> On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote:
>>
>> [snip..]
>>
>> [0.00] linux,usable-memory-range base e80, size 2000
>> [0.00] - e80 , 2000
>> [
y
> exporting them via usable-memory-range.
> (I still have to figure out what the side-effect of this patch is.)
>
> Thanks,
> -Takahiro AKASHI
>
> On Thu, Dec 21, 2017 at 01:30:43AM +0530, Bhupesh Sharma wrote:
>> On Tue, Dec 19, 2017 at 6:39 PM, Ard Biesheuvel
>>
On Fri, Dec 22, 2017 at 2:03 PM, AKASHI Takahiro
wrote:
> On Thu, Dec 21, 2017 at 05:36:30PM +0530, Bhupesh Sharma wrote:
>> Hello Akashi,
>>
>> On Thu, Dec 21, 2017 at 4:04 PM, AKASHI Takahiro
>> wrote:
>> > Bhupesh,
>> >
>> > Can you
On Mon, Dec 25, 2017 at 8:55 AM, AKASHI Takahiro
wrote:
> On Sun, Dec 24, 2017 at 01:21:02AM +0530, Bhupesh Sharma wrote:
>> On Fri, Dec 22, 2017 at 2:03 PM, AKASHI Takahiro
>> wrote:
>> > On Thu, Dec 21, 2017 at 05:36:30PM +0530, Bhupesh Sharma wrote:
>> >> H
On Tue, Dec 26, 2017 at 7:58 AM, AKASHI Takahiro
wrote:
> On Tue, Dec 26, 2017 at 09:35:17AM +0800, Dave Young wrote:
>> [snip]
>> > > > Well, we may be able to change pr_warn() to pr_warn_once() here, but
>> > > > I hope that adding "numa=off" to kernel command line should also work.
>> > >
>> >
Hello Akashi,
On Tue, Dec 26, 2017 at 8:26 AM, Bhupesh Sharma wrote:
> On Tue, Dec 26, 2017 at 7:58 AM, AKASHI Takahiro
> wrote:
>> On Tue, Dec 26, 2017 at 09:35:17AM +0800, Dave Young wrote:
>>> [snip]
>>> > > > Well, we may be able to change pr_warn()
On Tue, Jan 9, 2018 at 10:12 AM, AKASHI Takahiro
wrote:
> Bhupesh,
>
> On Tue, Jan 09, 2018 at 01:30:07AM +0530, Bhupesh Sharma wrote:
>> Hello Akashi,
>>
>> On Tue, Dec 26, 2017 at 8:26 AM, Bhupesh Sharma wrote:
>> > On Tue, Dec 26, 2017 at 7:58 AM, AKASH
Hi Poonam, James
On Sat, Jan 13, 2018 at 8:37 AM, Poonam Aggrwal wrote:
> Hi James
>
> Regards
> Poonam
>
>> -Original Message-
>> From: James Morse [mailto:james.mo...@arm.com]
>> Sent: Friday, January 12, 2018 11:29 PM
>> To: Poonam Aggrwal
>> Cc: linux-arm-ker...@lists.infradead.org;
6
>
Tested this patchset on a x86_64 RHEL machine (please find my test
summary below), so:
Tested-by: Bhupesh Sharma
Test Summary
---
1. I was running into the following issue while trying to run
'--mem-usage' option with makedumpfile on a RHEL machine with KASLR
ena
Hi,
On Fri, Jan 19, 2018 at 5:46 PM, James Morse wrote:
> Hello,
>
> On 16/01/18 07:07, takahiro.aka...@linaro.org wrote:
>> On Mon, Jan 15, 2018 at 10:14:05AM +0530, Bhupesh SHARMA wrote:
>>> On Sat, Jan 13, 2018 at 8:37 AM, Poonam Aggrwal
>>> wrote:
>&g
pgprot_t __acpi_get_mem_attribute(phys_addr_t addr)
>> {
>> /*
>> * According to "Table 8 Map: EFI memory types to AArch64 memory
>> @@ -261,4 +259,3 @@ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
>> return __pgprot(PROT_NORMAL_NC);
>> return __pgprot(PROT_DEVICE_nGnRnE);
>> }
>> -#endif
>> diff --git a/init/main.c b/init/main.c
>> index a8100b954839..a479ece2bae9 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -674,6 +674,10 @@ asmlinkage __visible void __init start_kernel(void)
>> debug_objects_mem_init();
>> setup_per_cpu_pageset();
>> numa_policy_init();
>> +#if defined(CONFIG_ARM64) && defined(CONFIG_EFI)
>> + efi_memmap_init_late(efi.memmap.phys_map,
>> + efi.memmap.nr_map * efi.memmap.desc_size);
>> +#endif
>> acpi_early_init();
>> if (late_time_init)
>> late_time_init();
>> --
>> 2.15.1
>>
I tested Ard's patch (on top of Akashi's proposed changes) on the
huawei taishan machine (where I originally found the problem) and I
can confirm that I am able to boot the kdump kernel properly and also
save the crashcore dump on local disk.
Also as Ard mentioned, 'efi_enter_virtual_mode' is probably not the
best name for the proposed function as we have already called
'SetVirtualAddressMap', but I cannot think of anything better. If
there are other opinions we can consider the same, otherwise may be we
can formalize this and queue it up as crashkernel is bricked on arm64
machines which support acpi boot machines without the same (and
several kdump users are affected because of the same).
Please feel free to add:
Tested-by: Bhupesh Sharma
Regards,
Bhupesh
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
yes Free pages
KERN_DATA 14243 no Dumpable kernel data
page size: 65536
Total pages on system: 1562310
Total size on system: 102387548160 Byte
Cc: Masaki Tachibana
Cc: Takuya Nakayama
Hello,
On Fri, Feb 9, 2018 at 7:24 PM, Gioh Kim wrote:
> Hello,
>
> "echo c > /proc/sysrq-trigger" generates the kernel dump but it
> reboots the system.
> I'd like to generate kernel dump without system reboot.
>
> I think it is possible to jump to the kdump kernel and generate kernel
> dump, an
On Tue, Feb 13, 2018 at 8:52 PM, Gioh Kim wrote:
> Jumping between the system kernel and the dump-capture kernel
> has been supported for long time but there is no description
> how to use it. This patch adds the description how to use kexec tool
> to jump to the dump-capture kernel and jump back
On Tue, Feb 13, 2018 at 8:15 PM, Gioh Kim wrote:
> On Tue, Feb 13, 2018 at 3:36 PM, Gioh Kim wrote:
>> On Tue, Feb 13, 2018 at 11:06 AM, Gioh Kim wrote:
>>> On Mon, Feb 12, 2018 at 7:56 AM, Bhupesh SHARMA
>>> wrote:
>>>> Hello,
>>>>
&
On Wed, Feb 14, 2018 at 2:32 PM, Gi-Oh Kim wrote:
> On Wed, Feb 14, 2018 at 2:43 AM, Dave Young wrote:
>> Hi,
>> On 02/13/18 at 04:22pm, Gioh Kim wrote:
>>> Jumping between the system kernel and the dump-capture kernel
>>> has been supported for long time but there is no description
>>> how to us
On Wed, Feb 14, 2018 at 2:24 PM, Gioh Kim wrote:
> On Tue, Feb 13, 2018 at 8:06 PM, Bhupesh SHARMA
> wrote:
>> On Tue, Feb 13, 2018 at 8:15 PM, Gioh Kim wrote:
>>> On Tue, Feb 13, 2018 at 3:36 PM, Gioh Kim wrote:
>>>> On Tue, Feb 13, 2018 at 11:06 AM, Gioh
Hi,
Some nitpicks inline..
On Thu, Feb 15, 2018 at 5:14 PM, Gioh Kim wrote:
> "--load-preserve-context", "--load-jump-back-helper" and "--entry"
> options are described separately but there is not any description
> how to use them.
>
> Signed-off-by: Gioh Kim
> ---
> kexec/kexec.8 | 30 +++
Hello,
On Fri, Feb 9, 2018 at 3:06 PM, Bhupesh Sharma wrote:
> Its good to have the makedumpfile '--mem-usage' support
> for arm64 architecture as well, as it allows one to see the page numbers
> of current system (1st kernel) in different use.
>
> Using this we ca
Hi Masaki Tachibana,
On Tue, Feb 20, 2018 at 4:42 PM, Masaki Tachibana
wrote:
> Hi Bhupesh,
>
> Sorry for the late reply.
> I'll reply by the end the next week.
Sure. Thanks for your mail.
Regards,
Bhupesh
> Thanks
> tachibana
>
>> -Original Mess
rned on and off)
[1]. https://elixir.bootlin.com/linux/v4.9/source/arch/arm64/Kconfig#L518
Regards,
Bhupesh
> Thanks
> Tachibana
>
>> -Original Message-
>> From: kexec [mailto:kexec-boun...@lists.infradead.org] On Behalf Of Bhupesh
>> SHARMA
>> Sent: Thursda
e that '--mem-usage' option is
supported not only on x86_64, but also on ppc64, s390x and arm64
platforms.
Signed-off-by: Bhupesh Sharma
---
makedumpfile.8 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/makedumpfile.8 b/makedumpfile.8
index 15db7947d62f..3ccfc6
User process pages
FREE1450569 yes Free pages
KERN_DATA 14243 no Dumpable kernel data
page size: 65536
Total pages on system: 1562310
Total size on system: 102387548160 Byte
Cc: Masaki Tach
bols like '_stext', we can read the
'/proc/kallsyms' file which contains these symbols and
works even in case of KASLR enabled arm64 kernels, as in those cases,
the '_stext' symbol will end up being randomized and hence
cannot be c
n.com/linux/v4.9/source/arch/arm64/Kconfig#L906
[2]. https://github.com/torvalds/linux/blob/master/arch/x86/lib/kaslr.c#L49
[3].
https://github.com/bhupesh-sharma/edk2-platforms/tree/master/Silicon/Openmoko/ChaosKeyDxe
[4].
https://elixir.bootlin.com/linux/v4.12.9/source/arch/arm64/kernel/kaslr.
on, Mar 12, 2018 at 08:58:00PM +, Ard Biesheuvel wrote:
>> > > > On 12 March 2018 at 20:14, Bhupesh Sharma wrote:
>> >
>> > > More importantly, neither arm64 _kexec_ supports kaslr.
Sorry if my earlier email was not clear on this, but I meant both the
kdump
'
On Wed, Mar 14, 2018 at 7:40 AM, AKASHI Takahiro
wrote:
> On Wed, Mar 14, 2018 at 01:18:47AM +0530, Bhupesh Sharma wrote:
>> On Tue, Mar 13, 2018 at 4:50 PM, Mark Rutland wrote:
>> > On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
>> >>
On Wed, Mar 14, 2018 at 11:54 PM, Mark Rutland wrote:
> On Wed, Mar 14, 2018 at 11:10:53AM +0900, AKASHI Takahiro wrote:
>> If kaslr-seed has a critical value in terms of security, is kexec-tools
>> a right place? It is exposed to user space albeit for a short time of period.
>
> The kernel zeroes
ues.
This can be specially useful for the arm64 case, where
kexec_load() or kdump passes important information like
'linux,usable-memory' ranges to the second kernel, and
the correctness of the ranges can be verified by
looking at the device-tree dump with '-d' flag specified.
n.
Signed-off-by: Bhupesh Sharma
Merge with 2nd patch
Signed-off-by: Bhupesh Sharma
---
kexec/arch/arm64/kexec-arm64.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 62f37585b788..c304c3775ada 100644
-
ues.
This can be specially useful for the arm64 case, where
kexec_load() or kdump passes important information like
'linux,usable-memory' ranges to the second kernel, and
the correctness of the ranges can be verified by
looking at the device-tree dump with '-d' flag specified.
n.
Signed-off-by: Bhupesh Sharma
---
kexec/arch/arm64/kexec-arm64.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 62f37585b788..1b54718465b9 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/a
On Mon, Mar 19, 2018 at 3:55 PM, Bhupesh Sharma wrote:
> At several occasions it would be useful to dump the fdt
> blob being passed to the second (kexec/kdump) kernel
> when '-d' flag is specified while invoking kexec/kdump.
>
> This allows one to look at the device-tr
On Mon, Mar 19, 2018 at 3:55 PM, Bhupesh Sharma wrote:
> Since during the arm64 kexec_load()/kdump invocation,
> the dtb is passed to the second kernel, it is sometimes useful
> to dump the dtb contents (to verify the correctness
> of the same).
>
> This patch adds this featur
On Mon, Mar 19, 2018 at 8:15 PM, AKASHI Takahiro
wrote:
> On Mon, Mar 19, 2018 at 04:05:38PM +0530, Bhupesh Sharma wrote:
>> At several occasions it would be useful to dump the fdt
>> blob being passed to the second (kexec/kdump) kernel
>> when '-d' flag is speci
On 03/14/2018 01:59 PM, AKASHI Takahiro wrote:
In the last couples of months, there were some problems reported [1],[2]
around arm64 kexec/kdump. Where those phenomenon look different,
the root cause would be that kexec/kdump doesn't take into account
crucial "reserved" regions of system memory a
Hi Akashi,
On Tue, Mar 20, 2018 at 12:36 AM, Bhupesh Sharma wrote:
> On Mon, Mar 19, 2018 at 8:15 PM, AKASHI Takahiro
> wrote:
>> On Mon, Mar 19, 2018 at 04:05:38PM +0530, Bhupesh Sharma wrote:
>>> At several occasions it would be useful to dump the fdt
>>> b
Hi James,
Sorry for the delay, I had a long weekend last week.
On Tue, Mar 27, 2018 at 7:01 PM, James Morse wrote:
> Hi Akashi, Bhupesh,
>
> On 27/03/18 10:04, AKASHI Takahiro wrote:
>> On Mon, Mar 26, 2018 at 02:29:31PM +0530, Bhupesh Sharma wrote:
>>> On Tue, Mar 20, 2
Hi Akashi,
On Fri, Apr 6, 2018 at 7:39 AM, AKASHI Takahiro
wrote:
> Bhupesh,
>
> On Fri, Mar 16, 2018 at 03:05:10PM +0530, Bhupesh Sharma wrote:
>> On Wed, Mar 14, 2018 at 11:54 PM, Mark Rutland wrote:
>> > On Wed, Mar 14, 2018 at 11:10:53AM +0900, AKASHI Takahiro wrote:
On 04/05/2018 04:35 PM, Petr Tesarik wrote:
On Wed, 28 Mar 2018 15:15:16 +0200
Michal Suchanek wrote:
It is parsed separately to save a few CPU cycles when setting up other
options but it just complicates the code. So fold it back and set up all
flags for both KEXEC_LOAD and KEXEC_FILE_LOAD
S
ed this fix
on my arm64 board, so:
Tested-by: Bhupesh Sharma
Regards,
Bhupesh
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Hi Ard,
On Mon, Apr 9, 2018 at 2:58 PM, Ard Biesheuvel
wrote:
> On 9 April 2018 at 06:31, AKASHI Takahiro wrote:
>> Hi,
>>
>> On Mon, Apr 09, 2018 at 09:31:34AM +0530, Bhupesh Sharma wrote:
>>> Hi Akashi,
>>>
>>> On Fri, Apr 6, 2018 at 7:
every successive boot:
[root@qualcomm-amberwing]# cat /proc/modules
sunrpc 524288 1 - Live 0x0307db190000
vfat 262144 1 - Live 0x0307db11
fat 262144 1 vfat, Live 0x0307db09
crc32_ce 262144 0 - Live 0x0307d8c7
...
Signed-off-by: Bhupesh Sharma
---
kexec/
Hi Ard,
On Tue, Mar 13, 2018 at 2:28 AM, Ard Biesheuvel
wrote:
> On 12 March 2018 at 20:14, Bhupesh Sharma wrote:
>> Hi Ard,
>>
>> I remember we had a discussion on this topic some time ago, but I was
>> working on enabling KASLR support on arm64 boards internally
Hello,
On Tue, Apr 3, 2018 at 7:28 PM, Bhupesh Sharma wrote:
> Hi James,
>
> Sorry for the delay, I had a long weekend last week.
>
> On Tue, Mar 27, 2018 at 7:01 PM, James Morse wrote:
>> Hi Akashi, Bhupesh,
>>
>> On 27/03/18 10:04, AKASHI Takahiro wrote:
>&
Hi Dave,
On Mon, Apr 16, 2018 at 1:43 PM, Dave Young wrote:
> Hi Bhupesh,
>
> On 04/03/18 at 07:28pm, Bhupesh Sharma wrote:
>> Hi James,
>>
>> Sorry for the delay, I had a long weekend last week.
>>
>> On Tue, Mar 27, 2018 at 7:01 PM, James Morse wrote:
&
Hello Akashi,
Thanks for the review comments.
On Mon, Apr 16, 2018 at 8:00 AM, AKASHI Takahiro
wrote:
> Bhupesh,
>
> On Sun, Apr 15, 2018 at 01:49:40AM +0530, Bhupesh Sharma wrote:
>> This patch adds the support to supply 'kaslr-seed' to secondary kernel,
>> whe
Hi,
I was working on improving documentation/structure of the upstream
kexec-tools and I was wondering what is the purpose of the 'kdump'
directory inside the kexec-tools.
This kdump utility seems to cause confusion with the 'kdump' utility
present inside some distributions (for e.g. '/usr/sbin/
On Tue, Apr 17, 2018 at 2:31 PM, Russell King wrote:
> On Tue, Apr 17, 2018 at 10:20:08AM +0530, Bhupesh Sharma wrote:
>> Hi,
>>
>> I was working on improving documentation/structure of the upstream
>> kexec-tools and I was wondering what is the purpose of the
On Tue, Apr 17, 2018 at 6:21 PM, Russell King wrote:
> On Tue, Apr 17, 2018 at 04:20:00PM +0530, Bhupesh Sharma wrote:
>> For e.g I use this tool on my arm64 board as follows:
>>
>> a. Read out the 'elfcorehdr' env variable passed to the crash kernel
>> an
form postmortem analysis with tools like
gdb/crash:
# gdb vmlinux
Accordingly, this patch removes the obsolete kdump tool from
'kexec-tools'.
Cc: Russell King
Cc: Simon Horman
Cc: Dave Young
Cc: Vivek Goyal
Cc: AKASHI Takahiro
Signed-off-by: Bhupesh Sharma
---
Makefile.in
ail/kexec/2018-April/020483.html
Cc: Russell King
Cc: Simon Horman
Cc: Dave Young
Cc: Vivek Goyal
Cc: AKASHI Takahiro
Bhupesh Sharma (2):
Makefile.in: Add uninstall rule
Remove obsolete kdump tool
Makefile.in | 92 +--
kdump/Makefile | 30 -
kdump
same.
Signed-off-by: Bhupesh Sharma
---
Makefile.in | 83 +++--
1 file changed, 81 insertions(+), 2 deletions(-)
diff --git a/Makefile.in b/Makefile.in
index 54c206fd649c..273d06ebea55 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -182,10 +1
56c5f 0x7175616c 0x636f6d6d 0x2d616d62
0x65727769 0x6e672d72 0x65702d31 0x352f7377 0x6170>;
linux,initrd-end = <0x 0x05e8a7a1>;
linux,initrd-start = <0x 0x04b49000>;
};
};
<..snip..>
Bhupesh Sharma (2):
dt-ops: Add helper API to dump fdt blo
n.
Signed-off-by: Bhupesh Sharma
---
kexec/arch/arm64/kexec-arm64.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 62f37585b788..1b54718465b9 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/a
ues.
This can be specially useful for the arm64 case, where
kexec_load() or kdump passes important information like
'linux,usable-memory' ranges to the second kernel, and
the correctness of the ranges can be verified by
looking at the device-tree dump with '-d' flag specified.
On Tue, Apr 17, 2018 at 10:47 AM, Dave Young wrote:
> On 04/16/18 at 08:39pm, Bhupesh Sharma wrote:
>> Hi Dave,
>>
>> On Mon, Apr 16, 2018 at 1:43 PM, Dave Young wrote:
>> > Hi Bhupesh,
>> >
>> > On 04/03/18 at 07:28pm, Bhupesh Sharma wrote:
>&g
Hello Akashi,
On Tue, Apr 17, 2018 at 12:35 AM, Bhupesh Sharma wrote:
> Hello Akashi,
>
> Thanks for the review comments.
>
> On Mon, Apr 16, 2018 at 8:00 AM, AKASHI Takahiro
> wrote:
>> Bhupesh,
>>
>> On Sun, Apr 15, 2018 at 01:49:40AM +0530, Bhupesh S
Hi Mark,
On Wed, Apr 18, 2018 at 5:22 PM, Mark Rutland wrote:
> On Sun, Apr 15, 2018 at 01:44:16AM +0530, Bhupesh Sharma wrote:
>> 4. Accordingly, I wanted to get opinions on whether arm64 timer count is a
>> good
>> entropy source on platforms which indeed support EFI_RNG
Hi Akashi,
Thanks for the review.
On Thu, Apr 26, 2018 at 1:26 PM, AKASHI Takahiro
wrote:
> Bhupesh,
>
> On Mon, Apr 23, 2018 at 03:56:10PM +0530, Bhupesh Sharma wrote:
>> Changes since v1:
>>
>> - v1 can be viewed here:
>> http://lists.i
every successive boot:
[root@qualcomm-amberwing]# cat /proc/modules
sunrpc 524288 1 - Live 0x0307db190000
vfat 262144 1 - Live 0x0307db11
fat 262144 1 vfat, Live 0x0307db09
crc32_ce 262144 0 - Live 0x0307d8c7
...
Signed-off-by: Bhupesh Sharma
---
Cha
inux,uefi-mmap-start = <0x 0x07a81018>;
linux,uefi-system-table = <0x 0x17fc0018>;
bootargs = "root=/dev/mapper/rhel_qualcomm--amberwing--rep--15-root ro
rd.lvm.lv=rhel_qualcomm-amberwing-rep-15/root
rd.lvm.lv=rhel_qualcomm-amberwing-rep-15/swap"
ues.
This can be specially useful for the arm64 case, where
kexec_load() or kdump passes important information like
'linux,usable-memory' ranges to the second kernel, and
the correctness of the ranges can be verified by
looking at the device-tree dump with '-d' flag specified.
n.
Signed-off-by: Bhupesh Sharma
---
kexec/arch/arm64/kexec-arm64.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 62f37585b788..1b54718465b9 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/a
Hello Akashi,
On Thu, Apr 26, 2018 at 2:27 PM, Bhupesh Sharma wrote:
> This patch adds the support to supply 'kaslr-seed' to secondary kernel,
> when we do a 'kexec warm reboot to another kernel' (although the
> behaviour remains the same for the 'kdump' c
Hello Russell, Simon,
On Mon, Apr 23, 2018 at 10:30 AM, Bhupesh Sharma wrote:
> This patchset contains two patches:
>
> [1/2] - Adds a missing uninstall rule to 'Makefile.in' to allow easier
> uninstallation of executables and man pages installed via
>
Hi Dave,
Thanks for the review.
On Mon, May 21, 2018 at 11:53 AM, Dave Young wrote:
> Hi Bhupesh,
> On 04/23/18 at 10:30am, Bhupesh Sharma wrote:
>> This patchset contains two patches:
>>
>> [1/2] - Adds a missing uninstall rule to 'Makefile.in' to allow
form postmortem analysis with tools like
gdb/crash:
# gdb vmlinux
Accordingly, this patch removes the obsolete kdump tool from
'kexec-tools'.
Cc: Russell King
Cc: Simon Horman
Cc: Dave Young
Cc: Vivek Goyal
Cc: AKASHI Takahiro
Signed-off-by: Bhupesh Sharma
---
Changes sinc
same.
Cc: Russell King
Cc: Simon Horman
Cc: Dave Young
Cc: Vivek Goyal
Cc: AKASHI Takahiro
Signed-off-by: Bhupesh Sharma
---
Changes since v1:
- As per Dave's suggestion, seperated the two patches included in the
patchset in v1 as individual patches in v2.
- Another patch sent
Thanks Bao for adding me to the Cc list.
Hi Yanjiang Jin,
Thanks for the patch. I have a few queries, please see them inline:
On 05/11/2018 11:30 AM, Yanjiang Jin wrote:
Now, according to the kernel's memory.h, converting a virtual address to
a physical address should be done like below:
Hi ARM64 maintainers,
I am confused about the PAGE_OFFSET value (or the start of the linear
map) on a KASLR enabled ARM64 kernel that I am seeing on a board which
supports a compatible EFI firmware (with EFI_RNG_PROTOCOL support).
1. 'arch/arm64/include/asm/memory.h' defines PAGE_OFFSET as:
/*
Hello Simon,
On Fri, May 25, 2018 at 3:32 PM, Simon Horman wrote:
> On Fri, May 25, 2018 at 04:00:33PM +0800, Dave Young wrote:
>> On 05/24/18 at 01:08pm, Bhupesh Sharma wrote:
>> > The kdump tool presently allows one to generate an ELF file containing
>> > the ELF
Hi Yanjiang,
On 05/30/2018 01:09 PM, Jin, Yanjiang wrote:
-Original Message-
From: Pratyush Anand [mailto:pratyush.an...@gmail.com]
Sent: 2018年5月30日 12:16
To: Jin, Yanjiang
Cc: kexec@lists.infradead.org; jinyanji...@gmail.com; ho...@verge.net.au
Subject: Re: [PATCH] arm64: update PHY
On 05/30/2018 03:50 PM, Jin, Yanjiang wrote:
-Original Message-
From: Bhupesh Sharma [mailto:bhsha...@redhat.com]
Sent: 2018年5月30日 16:39
To: Jin, Yanjiang ; Pratyush Anand
Cc: kexec@lists.infradead.org; jinyanji...@gmail.com; ho...@verge.net.au;
Zheng, Joey
Subject: Re: [PATCH
Hi Ard,
Sorry I was out for most of the day yesterday. Please see my responses inline.
On Mon, May 28, 2018 at 12:16 PM, Ard Biesheuvel
wrote:
> On 27 May 2018 at 23:03, Bhupesh Sharma wrote:
>> Hi ARM64 maintainers,
>>
>> I am confused about the PAGE_OFFSET value (or th
Hi Pratyush,
Thanks for your reply. Please see my replies inline:
On Wed, May 30, 2018 at 8:05 AM, Pratyush Anand
wrote:
> Hi Bhupesh,
>
>
> On Mon, May 28, 2018 at 2:33 AM, Bhupesh Sharma wrote:
>> Hi ARM64 maintainers,
>
> [...]
>
>>
>> 4. Since
On 05/31/2018 10:21 AM, Bhupesh Sharma wrote:
Hi Ard,
Sorry I was out for most of the day yesterday. Please see my responses inline.
On Mon, May 28, 2018 at 12:16 PM, Ard Biesheuvel
wrote:
On 27 May 2018 at 23:03, Bhupesh Sharma wrote:
Hi ARM64 maintainers,
I am confused about the
dr = memblock_start_of_DRAM();
Let's wait for an update from the ARM64 kernel maintainers, because I
think this change might be needed in other user-space tools (if we
decide to make the change in the user-space side) e.g. makedumpfile in
addition to kexec-tools to correctly handle this unique
On Sat, Jun 2, 2018 at 3:20 AM, Bhupesh Sharma wrote:
> Hi Yanjiang,
>
> Thanks, the description of the issue is more clear now.
>
> Also I managed to fix my qualcomm board to reproduce this issue.
> Please see more comments inline:
>
> On Thu, May 31, 2018 at 11:01 AM
On Sat, Jun 2, 2018 at 3:11 AM, Bhupesh Sharma wrote:
> On 05/31/2018 10:21 AM, Bhupesh Sharma wrote:
>>
>> Hi Ard,
>>
>> Sorry I was out for most of the day yesterday. Please see my responses
>> inline.
>>
>> On Mon, May 28, 2018 at 12:16 PM, Ard Bi
Hello Petr,
On Tue, Jun 5, 2018 at 1:31 PM, Petr Tesarik wrote:
> Hi all,
>
> I have observed hangs after crash on a Raspberry Pi 3 Model B+ board
> when a panic kernel is loaded. I attached a hardware debugger and found
> out that all CPU cores were stopped except one which was stuck in the
> id
d
Cc: Will Deacon
Cc: AKASHI Takahiro
Cc: James Morse
Signed-off-by: Bhupesh Sharma
---
arch/arm64/include/asm/memory.h | 3 +++
arch/arm64/kernel/arm64ksyms.c | 1 +
arch/arm64/mm/init.c| 3 +++
3 files changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm
1 - 100 of 440 matches
Mail list logo
