[PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Russell King - ARM Linux
linux at arm.linux.org.uk
Tue Mar 10 11:54:38 PDT 2015
On Tue, Mar 10, 2015 at 09:31:01PM +0300, Stas Sergeev wrote:
> 10.03.2015 20:38, Russell King - ARM Linux пишет:
> > On Tue, Mar 10, 2015 at 08:27:34PM +0300, Stas Sergeev wrote:
> >> Please also find the same crash here:
> >> http://lists.linaro.org/pipermail/kernel-build-reports/2014-June/003872.html
> > Hmm, looks like from the exynos5420-arndale-octa failure in that, we
> > don't dump the page table entries. We should do. Sorry about my
> > previous mail.
> > If you can reproduce this, please do so with this patch so that we
> > can get the page table entries associated with the problem. Thanks.
> > arch/arm/mm/fault.c | 1 +
> > 1 file changed, 1 insertion(+)
> > diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> > index a982dc3190df..6333d9c17875 100644
> > --- a/arch/arm/mm/fault.c
> > +++ b/arch/arm/mm/fault.c
> > @@ -552,6 +552,7 @@ do_DataAbort(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
> > pr_alert("Unhandled fault: %s (0x%03x) at 0x%08lx\n",
> > inf->name, fsr, addr);
> > + show_pte(current->mm, addr);
> > info.si_signo = inf->sig;
> > info.si_errno = 0;
> [ 5.383283] Unhandled fault: external abort on non-linefetch (0x808)
> at 0xf00d3018
> [ 5.390871] pgd = c0004000
> [ 5.393583] [f00d3018] *pgd=2d404811, *pte=efc1e65f, *ppte=efc1e45f
This is interesting.
So, the L1 page table entry is:
Pointing at physical address 0x2f404800
L2 page table entry:
Physical address 0xefc1e000
That corresponds with L_PTE_MT_WRITEALLOC, so that's a memory type mapping
with cacheable, write-back, write-allocate attributes.
The thing which has me wondering though is the difference in physical
addresses - that looks /very/ wrong - unless you have close to 4GB of
Let's see whether we can get some debug from vmalloc to work out what's
going on - can you also apply the patch below.
Also, if you could include details about how much memory your platform
has, and where it's located, that would be useful - passing memblock=debug
should allow us to see what's going on at the memblock level.
Also, the full kernel boot log would be useful to see.
(Patch isn't tested.)
mm/vmalloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 35b25e1340ca..3379bcd6d280 100644
@@ -129,6 +129,8 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr,
+printk("vmalloc: mapping page %p (0x%08lx000) at 0x%08lx\n",
+ page, page_to_pfn(page), addr);
set_pte_at(&init_mm, addr, pte, mk_pte(page, prot));
} while (pte++, addr += PAGE_SIZE, addr != end);
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
More information about the linux-arm-kernel