Re: earmhf issues on Beaglebone Black

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Jul 22, 2014 at 02:32:32PM -0700, Matt Thomas wrote:
> 
> On Jul 22, 2014, at 2:21 PM, Manuel Bouyer <bouyer%antioche.eu.org@localhost> 
> wrote:
> 
> > On Tue, Jul 22, 2014 at 02:07:49PM -0700, Matt Thomas wrote:
> >>>>> dab_buserr far 0x7fffcb80 -> NULL
> >>>>> copyargs, 1620: copyout @0x7fffcb80 4
> >>>>> copyoutargs: copyargs failed 14
> >> 
> >> That fsr is weird.  The domain is right but the reason is very
> >> strange: Synchronous external abort on translation table walk (2nd level)
> > 
> > It seems that the reason is always this one.
> > 
> >> 
> >>>>> data_abort_handler: data_aborts fsr=0x18be far=0x40062000
> >>>>> dab_buserr far 0x40062000 -> NULL
> >>>>> copyin_vmspace: copyin 0x40062000 0xc923c000 372 return 14
> >> 
> >> Again the fsr is strange because the domain should be 1, not 0xb.
> >> 
> >>>>> Does the patch below to print the PA makes sense ?
> >>>>> If so, could it be that the CPU, on some conditions, returns the
> >>>>> wrong fault type ?
> >> 
> >> I wonder what the l1pt has for the entry that corresponds to the address.
> >> Can out also print pm->pm_l1[far >> L1_S_SHIFT]?
> >> Is it getting corrupted somehow?
> > 
> > it's easy, here's a few outputs:
> > data_abort_handler: data_aborts fsr=0x180e far=0x7fffcb70
> > dab_buserr far 0x7fffcb70 -> NULL pm->pm_l1[far >> L1_S_SHIFT] = 0x0
> > copyargs, 1620: copyout @0x7fffcb70 4
> > copyoutargs: copyargs failed 14
> > 
> > data_abort_handler: data_aborts fsr=0x180e far=0x7fffcba8
> > dab_buserr far 0x7fffcba8 -> NULL pm->pm_l1[far >> L1_S_SHIFT] = 0x0
> > copyargs, 1620: copyout @0x7fffcba8 4
> > copyoutargs: copyargs failed 14
> > 
> > data_abort_handler: data_aborts fsr=0x180e far=0x7fffcb88
> > dab_buserr far 0x7fffcb88 -> NULL pm->pm_l1[far >> L1_S_SHIFT] = 0x0
> > copyargs, 1620: copyout @0x7fffcb88 4
> > copyoutargs: copyargs failed 14
> > 
> > data_abort_handler: data_aborts fsr=0x182e far=0x40062000
> > dab_buserr far 0x40062000 -> NULL pm->pm_l1[far >> L1_S_SHIFT] = 0x0
> > copyin_vmspace: copyin 0x40062000 0xc8f0a000 372 return 14
> 
> So why is uvm_fault returning an error for those address instead of
> fixing them up?  

AFAIK uvm_fault() is not called.
we enter data_abort_handler() with (fsr & FAULT_TYPE_MASK) == 0xe.
At line 278, data_aborts[fsr & FAULT_TYPE_MASK].func is not NULL
(it's dab_buserr() ) so we call it and goto to either do_trapsignal or out.

I just checked, both freebsd and linuxn handle fsr & FAULT_TYPE_MASK) == 0xe
as we do, I didn't see anything special.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--