Re: earmhf issues on Beaglebone Black

[Matt Thomas <matt%3am-software.com@localhost>]

On Jul 22, 2014, at 1:50 PM, Manuel Bouyer <bouyer%antioche.eu.org@localhost> 
wrote:

> On Tue, Jul 22, 2014 at 01:46:06PM -0700, Matt Thomas wrote:
>> 
>> On Jul 22, 2014, at 1:43 PM, Manuel Bouyer 
>> <bouyer%antioche.eu.org@localhost> wrote:
>> 
>>> On Tue, Jul 22, 2014 at 01:17:29PM +0200, Manuel Bouyer wrote:
>>>> 
>>>> So it looks like the fault happens inside the execve(), but before the
>>>> new executable has actually been loaded (which could explain
>>>> why there's no core dump). 
>>> 
>>> I tracked this down to an error in copyin() or copyout() (which is not
>>> so surprising, given the data_aborts message).
>>> 
>>> I used the attached patch to try to find the associated physical address.
>>> To my surprise, pmap_extract() returned NULL, which would mean that
>>> this address is actually not mapped (several samples of the same problem):
>>> data_abort_handler: data_aborts fsr=0x183e far=0x40062000
>>> dab_buserr far 0x40062000 -> NULL
>>> copyin_vmspace: copyin 0x40062000 0xc8f94000 372 return 14
>>> 
>>> data_abort_handler: data_aborts fsr=0x180e far=0x7fffcb80
>>> 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)

>>> 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?