Created attachment 168752 [details] session log of many kernel panics. I'm installing xfce on a beaglebone black running FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r296898M: Wed Mar 16 23:52:02 BRT 2016 ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) Target: armv6--freebsd11.0-gnueabi Thread model: posix InstalledDir: /usr/bin All times I getting a kernel panic on /usr/src/sys/arm/arm/pmap-v6.c:1890 [51/87] Extracting libgsf-1.14.36: 40%panic: pmap_fault: pm_pt1 abort KDB: enter: panic dbg_check_slot_free: Invalid slot number 0, max -1 dbg_check_slot_free: Invalid slot number 1, max -1 [ thread pid 933 tid 100091 ] Stopped at $d.6:panic: _mtx_lock_sleep: recursed on non-recursive mutex pmap @ /usr/src/sys/arm/arm/pmap-v6.c:1890 Attached is a session log of many sessions trying install xfce and triggering the kernel panic.
(1) The panic reported in subject is invoked by the following panic -> panic: pmap_fault: pm_pt1 abort, which happened before. It's unhappy that panics from guts of pmap code may invoke another panic, but let be clear in that. (2) We known that the "panic: pmap_fault: pm_pt1 abort" can happen now on Cortex A8 platforms - i.e. beaglebone. If this is the known case, temporary solution is to disable promotions in pmap code: sp_enabled = 0 in pmap-v6.c file, or it's tunable and can be set as vm.pmap.sp_enabled=0 before kernel boots.
A commit references this bug: Author: skra Date: Fri Apr 22 06:42:50 UTC 2016 New revision: 298460 URL: https://svnweb.freebsd.org/changeset/base/298460 Log: Fix duplicate TLB entries issue during section promotion/demotion. Such situation is defined as UNPREDICTABLE by arm arm manual. This patch fixes all explicit TLB fetches which could cause this issue and speculative TLB fetches for sections mapped in user address space. Speculative TLB fetches for sections mapped in kernel address space are not fixed yet as the break-before-make approach must be implemented for kernel mappings too. This means that promoted/demoted section will be unmapped for a while. Either kernel stack the promotion/demotion is being done on or L1 page table(s) which must be modified may be mapped by this section. Thus the fix will not be so simple like for userland mappings. The issue was detectable only on Cortex-A8 platforms and only very rarely. It was reported few times. First, it was by Mikael Urankar in June 2015. He helped to identify the mechanism of this issue, but we were not sure how to fix it correctly until now. PR: 208381 Reported by: Mikael Urankar (mikael.urankar at gmail.com) Reviewed by: kib Changes: head/sys/arm/arm/pmap-v6.c