lkml.org 
[lkml]   [2015]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
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;
> >
> >

Thanks.

> [ 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:
PMD_TYPE_TABLE
PMD_BIT4
PMD_DOMAIN(0)
Pointing at physical address 0x2f404800

L2 page table entry:
PTE_EXT_XN
PTE_BUFFERABLE
PTE_CACHEABLE
PTE_EXT_AP_UNO_SRW
PTE_EXT_TEX(1)
PTE_EXT_SHARED
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
memory.

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.

Thanks.

(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
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -129,6 +129,8 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr,
return -EBUSY;
if (WARN_ON(!page))
return -ENOMEM;
+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));
(*nr)++;
} while (pte++, addr += PAGE_SIZE, addr != end);
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.


\
 
 \ /
  Last update: 2015-03-10 20:01    [W:0.338 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site