Re: [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA

From	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Newsgroups	linux.kernel
Subject	Re: [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA
Date	2017-01-06 13:30 +0100
Message-ID	<sWBOG-1Ry-3@gated-at.bofh.it> (permalink)
References	(5 earlier) <sWf1L-2MX-11@gated-at.bofh.it> <sWf1L-2MX-9@gated-at.bofh.it> <sWBF0-1NR-21@gated-at.bofh.it> <sWBF0-1NR-23@gated-at.bofh.it> <sWBF0-1NR-19@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On 6 January 2017 at 12:03, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Jan 05, 2017 at 08:49:44PM +0100, Robert Richter wrote:
>> On 05.01.17 13:22:00, Robert Richter wrote:
>> > On 05.01.17 12:08:20, Will Deacon wrote:
>> > > I really can't see how the fix causes a crash, and I couldn't reproduce
>> > > it on any of my boards, nor could any of the Linaro folk afaik. Are you
>> > > definitely running mainline with just these two patches from Ard?
>> >
>> > Yes, just both patches applied. Various other solutions were working.
>>
>> I have retested the same kernel (v4.9 based) as before and now it
>> boots fine including rtc-efi device registration (it was crashing
>> there):
>>
>>  rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
>>
>> There could be a difference in firmware and mem setup, though I also
>> downgraded the firmware to test it, but can't reproduce it anymore. I
>> could reliable trigger the crash the first time.
>>
>> FTR the oops.
>
> Hmm, I just can't help but think you were accidentally running with
> additional patches when you saw this oops previously. For example,
> your log looks very similar to this one:
>
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473666.html
>
> but then again, these crashes probably often look alike.
>

These are quite different, in fact. In James's case, the UEFI memory
map was missing some entries, so not all memory regions that the
firmware expected to be there were actually mapped, hence the all-zero
*pte. In Robert's case, it looks like the UEFI runtime services page
tables are corrupted, i.e., *pte has RES0 bits set.

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA Will Deacon <will.deacon@arm.com> - 2017-01-04 14:30 +0100
  Re: [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-01-04 15:00 +0100
    Re: [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA Will Deacon <will.deacon@arm.com> - 2017-01-04 15:10 +0100
      Re: [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA Will Deacon <will.deacon@arm.com> - 2017-01-05 13:10 +0100
        Re: [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA Will Deacon <will.deacon@arm.com> - 2017-01-06 13:20 +0100
          Re: [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-01-06 13:30 +0100

csiph-web