Re: earmhf issues on Beaglebone Black

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

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

Actually, the VA which is failing for pmap_extract() is 0x40062000,
or 0x7fffcb80. Not in the 0x[89]xxxxxxx range.

> what pmap is being pass to pmap_extract that it is failing on?

the pmap of curlwp. What do you want to know exactly ?

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