Date: Sat, 04 Oct 2025 10:45:33 +0300 From: Sulev-Madis Silber <freebsd-current-freebsd-org111@ketas.si.pri.ee> To: freebsd-current@freebsd.org Subject: Re: armv7 translation fault Message-ID: <BB289369-19DE-43E4-9476-72284CE491E3@ketas.si.pri.ee> In-Reply-To: <57C4730E-2AE7-4BCA-A2B5-4CD8A659AFE5@ketas.si.pri.ee>
index | next in thread | previous in thread | raw e-mail
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... >help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BB289369-19DE-43E4-9476-72284CE491E3>