I've pushed this, I can't say I'm particularly happy about it as there's still no resolution upstream as to the best direction. This will need to happen soon because I won't be pushing the patch to 4.9 or later. On Mon, Oct 10, 2016 at 3:52 PM, Robert Richter <robert.richter@xxxxxxxxxx> wrote: > Peter, > > please consider this fix for Fedora 25 and Rawhide. It fixes a boot > issue I have had with ThunderX systems. Now a Fedora 25 kernel boots > without any issues. > > Tested on Fedora 25 (4.8.0-1.thunderx.1.fc26.aarch64, using > devicetree, local fedpkg build), ThunderX crb2s system (dual node), > based on rpms/kernel.git: > > 9510c8110910 Add patch to fix Xorg starting with virtio (rhbz 1366842) > > Upstream thread: > > http://www.spinics.net/lists/arm-kernel/msg535191.html > > Though the solution for the fix is still under discussion upstream, we > should apply it to the kernel package and remove it later once a fix > made it upstream. > > Should I send a patch for rpms/kernel.git? Please let me know patch > logistic and if there is anything else to do to integrate the fix. > > Thanks, > > -Robert > > > ----- Forwarded message from Robert Richter <rrichter@xxxxxxxxxx> ----- > > Subject: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section > Date: Thu, 6 Oct 2016 11:52:07 +0200 > From: Robert Richter <rrichter@xxxxxxxxxx> > To: Catalin Marinas <catalin.marinas@xxxxxxx>, Will Deacon <will.deacon@xxxxxxx> > CC: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>, David Daney <david.daney@xxxxxxxxxx>, Mark Rutland <mark.rutland@xxxxxxx>, Hanjun Guo <hanjun.guo@xxxxxxxxxx>, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, > linux-efi@xxxxxxxxxxxxxxx, Robert Richter <rrichter@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx > Message-ID: <1475747527-32387-1-git-send-email-rrichter@xxxxxxxxxx> > X-Mailer: git-send-email 2.7.0.rc3 > Content-Type: text/plain > Return-Path: Robert.Richter@xxxxxxxxxx > > There is a memory setup problem on ThunderX systems with certain > memory configurations. The symptom is > > kernel BUG at mm/page_alloc.c:1848! > > This happens for some configs with 64k page size enabled. The bug > triggers for page zones with some pages in the zone not assigned to > this particular zone. In my case some pages that are marked as nomap > were not reassigned to the new zone of node 1, so those are still > assigned to node 0. > > The reason for the mis-configuration is a change in pfn_valid() which > reports pages marked nomap as invalid: > > 68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping > > This causes pages marked as nomap being no long reassigned to the new > zone in memmap_init_zone() by calling __init_single_pfn(). > > Fixing this by restoring the old behavior of pfn_valid() to use > memblock_is_memory(). Also changing users of pfn_valid() in arm64 code > to use memblock_is_map_memory() where necessary. This only affects > code in ioremap.c. The code in mmu.c still can use the new version of > pfn_valid(). > > Should be marked stable v4.5.. > > Signed-off-by: Robert Richter <rrichter@xxxxxxxxxx> > --- > arch/arm64/mm/init.c | 2 +- > arch/arm64/mm/ioremap.c | 5 +++-- > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index bbb7ee76e319..25b8659c2a9f 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -147,7 +147,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max) > #ifdef CONFIG_HAVE_ARCH_PFN_VALID > int pfn_valid(unsigned long pfn) > { > - return memblock_is_map_memory(pfn << PAGE_SHIFT); > + return memblock_is_memory(pfn << PAGE_SHIFT); > } > EXPORT_SYMBOL(pfn_valid); > #endif > diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c > index 01e88c8bcab0..c17c220b0c48 100644 > --- a/arch/arm64/mm/ioremap.c > +++ b/arch/arm64/mm/ioremap.c > @@ -21,6 +21,7 @@ > */ > > #include <linux/export.h> > +#include <linux/memblock.h> > #include <linux/mm.h> > #include <linux/vmalloc.h> > #include <linux/io.h> > @@ -55,7 +56,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size, > /* > * Don't allow RAM to be mapped. > */ > - if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr)))) > + if (WARN_ON(memblock_is_map_memory(phys_addr))) > return NULL; > > area = get_vm_area_caller(size, VM_IOREMAP, caller); > @@ -96,7 +97,7 @@ EXPORT_SYMBOL(__iounmap); > void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size) > { > /* For normal memory we already have a cacheable mapping. */ > - if (pfn_valid(__phys_to_pfn(phys_addr))) > + if (memblock_is_map_memory(phys_addr)) > return (void __iomem *)__phys_to_virt(phys_addr); > > return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL), > -- > 2.7.0.rc3 > > > ----- End forwarded message ----- _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
