Re: earmhf issues on Beaglebone Black

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

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

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