port-powerpc/56818: oea: system trapped in pgdaemon under high memory pressure

[rokuyama.rk%gmail.com@localhost]

>Number:         56818
>Category:       port-powerpc
>Synopsis:       oea: system trapped in pgdaemon under high memory pressure
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-powerpc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat May 07 09:35:01 +0000 2022
>Originator:     Rin Okuyama
>Release:        9.99.96
>Organization:
Department of Physics, Meiji University
>Environment:
NetBSD  9.99.96 NetBSD 9.99.96 (KUROBOX) #4: Sat May  7 16:18:45 JST 2022  rin@latipes:/build/src/sys/arch/sandpoint/compile/KUROBOX sandpoint
>Description:
For 128MB-RAM 603e-based sandpoint machine, the system gets frozen
with some high-memory-pressure operations, e.g., simultaneous runs of
fc-cache(1) and makemandb(1), ATF like ones in lib/libc/db, etc..

It is trapped into pgdaemon, and no operation other than entering
DDB is possible.

Typical backtrace is like:

---
db> bt
0x00b44c20: at intr_deliver+0x98
0x00b44c60: at pic_handle_intr+0x108
0x00b44cc0: at trapstart+0x690
0x00b44d90: at 0xb44e74
0x00b44db0: at pmap_query_bit+0x90
0x00b44dd0: at uvmpdpol_selectvictim+0x1c8
0x00b44e20: at uvm_pageout+0x298
0x00b44f20: at cpu_lwp_bootstrap+0xc
saved LR(0xfffffefb) is invalid.
---

or

---
db> bt
0x00b44c60: at intr_deliver+0x98
0x00b44ca0: at pic_handle_intr+0x108
0x00b44d00: at trapstart+0x690
0x00b44dd0: at uvmpdpol_selectvictim+0x3dc
0x00b44e20: at uvm_pageout+0x298
0x00b44f20: at cpu_lwp_bootstrap+0xc
saved LR(0xfffffefb) is invalid.
---

or it is at some other functions called from uvm_pageout().

Even for 1GB-RAM Mac Mini G4, a similar failure has been observed;
gem(4) claimed memory shortage forever. Unfortunately, I couldn't get
backtrace for this case.

This is not observed for booke and ibm4xx as far as I can see;
even 64MB-RAM EXPLORA451 survives tests in lib/libc/db.

Therefore, I guess something wrong with oea's pmap.

This should be a recent (~ 6 months or so) regression. This failure
occurs even if PV-tracking is disabled by PMAP_PV_TRACK_ONLY_STUBS
option.

This may or may not be related to instabilities reported on
port-macppc@:

https://mail-index.netbsd.org/port-macppc/2022/03/29/msg002954.html
>How-To-Repeat:
Run ATF on sandpoint (or low-memory powerpc/oea) machine.
>Fix:
N/A