Re: armv7 translation fault

i think my hw, which is even more complex, has intermittent fault unless other ideas come up

i booted old 15-current. even 13.5r. couldn't bring it up. and then i could... on same exact 16-current

but no worries, at least people now can be reminded in which way those errors manifest. in which part the errors are, i don't know, ram, soc, power, sdcard. even i could partially test ram on armv7 eg with uboot, i'm sure that doesn't give any guarantees it'a now always ok forever

i don't know i running current there could also do something to it



On October 3, 2025 10:28:50 AM GMT+03:00, Sulev-Madis Silber <freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote:
>i have allwinner h3 in hw nanopi neo core for which i use own dtb and uboot for nanopi m1 plus to get emmc up and working
>
>and i have those things
>
>Fatal kernel mode data abort: 'Translation Fault (L1)' on write
>
>Fatal kernel mode data abort: 'Translation Fault (L2)' on read
>
>Starting devd.
>panic: acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) pmap @ sys/arm/arm/pmap-v6.c:6476
>
>(last one came from debug kernel)
>
>seems like i get more of them, almost indefinite amount, if i try to mess with uboot and efi loader trying to get update fault tolerant things up
>
>once i get system up into userland (could be single or multi) and then reboot from there, they all disappear and i can boot as much as i want
>
>are those my hw specific or something leaves something in memory which later messes things up? i don't have enough knowledge here and currently didn't try to cold boot from total power off state
>
>is this an error and can it be fixed? if ram or other hw indeed ends up in questionable state, could it be possible for kernel to rectify it somehow
>
>never seen them before too, despite messing around in uboot and loader shell a lot, before. so a recent bug?
>
>tried to look up what that error is and unfortunately i'm not going to learn how mmu works in one day. so any ideas eh...
>