Re: earmhf issues on Beaglebone Black

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

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
> 
> data_abort_handler: data_aborts fsr=0x18be far=0x40062000
> dab_buserr far 0x40062000 -> NULL
> copyin_vmspace: copyin 0x40062000 0xc923c000 372 return 14
> 
> 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 ?

0x[89]xxxxxxx is fine for a VA on the bbone black.  It's just a
direct-mapped VA.  pmap_extract should be working for that.
what pmap is being pass to pmap_extract that it is failing on?