Re: [RFC] arm64: extra entries in /proc/iomem for kexec

James, On Wed, Apr 25, 2018 at 02:22:07PM +0100, James Morse wrote: > Hi Akashi, > > On 25/04/18 10:20, AKASHI Takahiro wrote: > > On Tue, Apr 24, 2018 at 05:08:57PM +0100, James Morse wrote: > >> On 16/04/18 11:08, AKASHI Takahiro wrote: > >>> On Thu, Apr

Re: [RFC] arm64: extra entries in /proc/iomem for kexec

On Tue, Apr 24, 2018 at 05:08:57PM +0100, James Morse wrote: > Hi Akashi, > > On 16/04/18 11:08, AKASHI Takahiro wrote: > > On Thu, Apr 12, 2018 at 05:01:52PM +0100, James Morse wrote: > >> On 05/04/18 03:42, AKASHI Takahiro wrote: > >>> On Mon, Apr 02, 2018

Re: [RFC] arm64: extra entries in /proc/iomem for kexec

On Thu, Apr 12, 2018 at 05:01:52PM +0100, James Morse wrote: > Hi Akashi, > > Sorry I've been sluggish on this issue, > > On 05/04/18 03:42, AKASHI Takahiro wrote: > > On Mon, Apr 02, 2018 at 10:53:32AM +0900, AKASHI Takahiro wrote: > >> On Tue, Mar 27, 2018 at

Re: [RFC] arm64: extra entries in /proc/iomem for kexec

On Mon, Apr 02, 2018 at 10:53:32AM +0900, AKASHI Takahiro wrote: > James, > > My apologies for slow response. I had a long weekend. > > On Tue, Mar 27, 2018 at 02:32:49PM +0100, James Morse wrote: > > Hi Akashi, > > > > On 27/03/18 11:16, AKASHI Takahiro wrote:

Re: [RFC] arm64: extra entries in /proc/iomem for kexec

James, My apologies for slow response. I had a long weekend. On Tue, Mar 27, 2018 at 02:32:49PM +0100, James Morse wrote: > Hi Akashi, > > On 27/03/18 11:16, AKASHI Takahiro wrote: > > On Tue, Mar 20, 2018 at 01:18:34AM +0530, Bhupesh Sharma wrote: > >> On 03/14/2018 0

Re: [RFC] arm64: extra entries in /proc/iomem for kexec

Ard, Bhupesh, Thank you for your comments. On Tue, Mar 20, 2018 at 01:18:34AM +0530, Bhupesh Sharma wrote: > 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

Re: [RFC] arm64: extra entries in /proc/iomem for kexec

On Wed, Mar 14, 2018 at 08:39:23AM +, Ard Biesheuvel wrote: > On 14 March 2018 at 08:29, AKASHI Takahiro <takahiro.aka...@linaro.org> wrote: > > In the last couples of months, there were some problems reported [1],[2] > > around arm64 kexec/kdump. Where those phen

[RFC] arm64: extra entries in /proc/iomem for kexec

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 and unintentionally corrupts them. Given that

Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel

Ard, On Wed, Mar 07, 2018 at 07:55:34PM +, Ard Biesheuvel wrote: > (+ James) > > Hello Akashi, > > On 6 March 2018 at 09:00, AKASHI Takahiro <takahiro.aka...@linaro.org> wrote: > > Tyler, Jeffrey, > > > > On Fri, Mar 02, 2018 at 08:27:11AM -0500, Tyl

Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel

Tyler, Jeffrey, On Fri, Mar 02, 2018 at 08:27:11AM -0500, Tyler Baicar wrote: > On 3/2/2018 12:53 AM, AKASHI Takahiro wrote: > >Tyler, Jeffrey, > > > >[Note: This issue takes place in kexec, not kdump. So to be precise, > >it is not the same phenomenon as what I add

Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel

Hi, On Wed, Feb 28, 2018 at 08:39:42AM -0700, Jeffrey Hugo wrote: > On 2/27/2018 11:19 PM, AKASHI Takahiro wrote: > >Tyler, > > > ># I missed catching your patch as its subject doesn't contain arm64. > > > >On Fri, Feb 23, 2018 at 12:42:31PM -0700, Tyler Baicar w

Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel

Tyler, # I missed catching your patch as its subject doesn't contain arm64. On Fri, Feb 23, 2018 at 12:42:31PM -0700, Tyler Baicar wrote: > Currently on arm64 ESRT memory does not appear to be properly blocked off. > Upon successful initialization, ESRT prints out the memory region that it >

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

On Tue, Dec 26, 2017 at 02:58:45PM +0800, Dave Young wrote: > On 12/26/17 at 08:26am, Bhupesh Sharma wrote: > > On Tue, Dec 26, 2017 at 7:58 AM, AKASHI Takahiro > > <takahiro.aka...@linaro.org> wrote: > > > On Tue, Dec 26, 2017 at 09:35:17AM +0800, Dave Young wrote: &

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

On Tue, Dec 26, 2017 at 02:56:36PM +0800, Dave Young wrote: > On 12/26/17 at 11:28am, 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

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

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 <bhsha...@redhat.com> wrote: > > On Tue, Dec 26, 2017 at 7:58 AM, AKASHI Takahiro > > <takahiro.aka...@linaro.org> wrote

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

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. > > > > > > Hmm, adding "numa=off" to crashkernel bootargs works, and

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

On Sun, Dec 24, 2017 at 01:21:02AM +0530, Bhupesh Sharma wrote: > On Fri, Dec 22, 2017 at 2:03 PM, AKASHI Takahiro > <takahiro.aka...@linaro.org> wrote: > > On Thu, Dec 21, 2017 at 05:36:30PM +0530, Bhupesh Sharma wrote: > >> Hello Akashi, > >> > >> On

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

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 > <takahiro.aka...@linaro.org> wrote: > > Bhupesh, > > > > Can you test the patch attached below, please? > > > > I

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

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 > <ard.biesheu...@linaro.org> wrote: > > On 19 December 2017 at 07:09, AKASHI Takahiro > > <takahiro.aka...@linaro.org&

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

On Mon, Dec 18, 2017 at 01:40:09PM +0800, Dave Young wrote: > On 12/15/17 at 05:59pm, AKASHI Takahiro wrote: > > On Wed, Dec 13, 2017 at 12:17:22PM +, Ard Biesheuvel wrote: > > > On 13 December 2017 at 12:16, AKASHI Takahiro > > > <takahiro.aka...@linaro.org&

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

> > > Also add linux-acpi list > > On 12/18/17 at 02:31am, Bhupesh Sharma wrote: > >> On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel > >> <ard.biesheu...@linaro.org> wrote: > >> > On 15 December 2017 at 09:59, AKASHI Takahiro > >> &

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

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 > [0.00] linux,usable-memory-range base 396c, size a > [0.00] - 396c , a

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

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 > <takahiro.aka...@linaro.org> wrote: > > On Mon, Dec 18, 2017 at 01:16:57PM +0800, Dave Young wrote: > >> kexec@fedoraproject... is for Fedo

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

2017 at 3:05 PM, Ard Biesheuvel > > <ard.biesheu...@linaro.org> wrote: > > > On 15 December 2017 at 09:59, AKASHI Takahiro > > > <takahiro.aka...@linaro.org> wrote: > > >> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote: > &

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

On Wed, Dec 13, 2017 at 12:17:22PM +, Ard Biesheuvel wrote: > On 13 December 2017 at 12:16, AKASHI Takahiro > <takahiro.aka...@linaro.org> wrote: > > On Wed, Dec 13, 2017 at 10:49:27AM +, Ard Biesheuvel wrote: > >> On 13 December 2017 at 10:26, AKASHI

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

On Wed, Dec 13, 2017 at 10:49:27AM +, Ard Biesheuvel wrote: > On 13 December 2017 at 10:26, AKASHI Takahiro > <takahiro.aka...@linaro.org> wrote: > > Bhupesh, Ard, > > > > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote: > >> Hi Ard,

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

Bhupesh, Ard, On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote: > Hi Ard, Akashi > (snip) > Looking deeper into the issue, since the arm64 kexec-tools uses the > 'linux,usable-memory-range' dt property to allow crash dump kernel to > identify its own usable memory and exclude, at

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

Bhupesh, On Wed, Nov 15, 2017 at 04:28:55PM +0530, Bhupesh Sharma wrote: > (snip) > # dmesg | grep -B 2 -i "ACPI reclaim" > [0.00] efi: 0x3967-0x396b [Runtime Code |RUN| | > | | | | | |WB|WT|WC|UC] > [0.00] efi: 0x396c-0x3970 [Boot

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

Hi, On Fri, Nov 10, 2017 at 05:41:56PM +0530, Bhupesh Sharma wrote: > Resent with Akashi's correct email address. > > On Fri, Nov 10, 2017 at 5:39 PM, Bhupesh Sharma wrote: > > Hi Ard, Akashi > > > > I have met an issue on an arm64 board using the latest master branch from

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

Mimi, On Wed, Nov 08, 2017 at 09:17:37PM -0500, Mimi Zohar wrote: > > > IMHO that should just fail then, ie, a "locked down" kernel should not > > > want to > > > *pass* a firmware signature if such thing could not be done. > > > > > > Its no different than trying to verify a signed module on a

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Wed, Nov 08, 2017 at 08:46:26PM +0100, Luis R. Rodriguez wrote: > On Wed, Nov 08, 2017 at 03:15:54PM +0900, AKASHI, Takahiro wrote: > > Luis, > > > > Thank you for this heads-up. > > > > On Wed, Nov 08, 2017 at 12:07:00AM +0100, Luis R. Rodriguez wrote: &g

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

Luis, Thank you for this heads-up. On Wed, Nov 08, 2017 at 12:07:00AM +0100, Luis R. Rodriguez wrote: > On Thu, Nov 02, 2017 at 06:10:41PM -0400, Mimi Zohar wrote: > > On Thu, 2017-11-02 at 22:04 +, David Howells wrote: > > > Mimi Zohar wrote: > > > > > > > > Only

[PATCH v35 14/14] efi/libstub/arm*: Set default address and size cells values for an empty dtb

esolves the observed issue, and makes the fdt less fragile. Signed-off-by: Sameer Goel <sg...@codeaurora.org> Signed-off-by: Jeffrey Hugo <jh...@codeaurora.org> Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.or

[PATCH v34 14/14] efi/libstub/arm*: Set default address and size cells values for an empty dtb

From: Sameer Goel In cases where a device tree is not provided (ie ACPI based system), an empty fdt is generated by efistub. #address-cells and #size-cells are not set in the empty fdt, so they default to 1 (4 byte wide). This can be an issue on 64-bit systems where

[PATCH v33 14/14] efi/libstub/arm*: Set default address and size cells values for an empty dtb

From: Sameer Goel In cases where a device tree is not provided (ie ACPI based system), an empty fdt is generated by efistub. #address-cells and #size-cells are not set in the empty fdt, so they default to 1 (4 byte wide). This can be an issue on 64-bit systems where