[Bug 297598] armv7: repeatable kernel panic in cache_drain_safe_cpu / uma_reclaim_worker on 15.1-RELEASE-p2

[email protected]
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297598

            Bug ID: 297598
           Summary: armv7: repeatable kernel panic in cache_drain_safe_cpu
                    / uma_reclaim_worker on 15.1-RELEASE-p2
           Product: Base System
           Version: 15.1-STABLE
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: [email protected]
          Reporter: [email protected]

System: FreeBSD 15.1-RELEASE-p2, armv7
Hardware: FriendlyARM NanoPi NEO, Allwinner H3, 512 MB RAM

After upgrading from FreeBSD 14.4-RELEASE to 15.1-RELEASE-p2, the system
repeatedly panics in the UMA reclaim path.

The panic is reproducible under different workloads, especially during heavier
I/O/memory activity. It has occurred during ZFS operations and during a large
git fetch to a ZFS dataset.

The ZFS pool on the USB SSD was completely destroyed, old ZFS labels were
cleared, GPT and the pool were recreated from scratch under 15.1, but the same
panic still occurred.

Typical backtrace:

Fatal kernel mode data abort: 'Translation Fault (L1)' on write

#0  kdb_backtrace
#1  vpanic
#2  vpanic
#3  abort_align
#4  abort_handler
#5  exception_exit
#6  cache_drain_safe_cpu
#7  pcpu_cache_drain_safe
#8  uma_reclaim_domain
#9  uma_reclaim_worker
#10 fork_exit
#11 swi_exit

Physical memory: 491 MB
Swap: 2 GB

The fault address varies between crashes, but the backtrace consistently ends
in cache_drain_safe_cpu / pcpu_cache_drain_safe / uma_reclaim_domain /
uma_reclaim_worker.

The machine was previously stable on FreeBSD 14.4-RELEASE.

-- 
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.