On 03/09/2026 20:07, Jiaxun Yang wrote:
> On Thu, 3 Sep 2026, at 7:47 PM, Alexander Schreiber wrote:
> [...]
>> Does anybody have any ideas what might be going on here? Am I just holding
>> it wrong in a particularly weird way?
> Hi Alex,
> I was hunting another swap issue on 11.0 which end up being a pmap dirty tracking
> issue. Haven't got a chance to send-pr as I'm not 100% sure about my conclution.
> Your symptom seems to be a dirty tracking issue as well.
> Can you try to pull-up those two commits and see if it fix your problem:
> https://github.com/NetBSD/src/commit/f3dc7bd2ff5ac5ae49ed4bd4869fad0802d7c6a0
> https://github.com/NetBSD/src/commit/020b2df9f010c1882cd3ac0a4eb142d377ea02e
I created a diff (and a draft pull-up) for this (refmod.diff)
To test it I’ve created another diff (pmap.refmod.debug.diff) which can be run by
sysctl -w debug.crashme_enable=1
sysctl -w debug.crashme.ddb=1
And calling pmap_test_mod_ref from ddb
e.g.
arm64# sysctl -w debug.crashme_enable=1
debug.crashme_enable: 0 -> 1
arm64# sysctl -w debug.crashme.ddb=1
[ 99.8666043] crashme_sysctl_forwarder:210: invoking "ddb" (enter ddb directly)
Stopped in pid 2805.2805 (sysctl) at netbsd:cpu_Debugger+0xc: ldp x29, x30, [sp],#16
db{0}> !pmap_test_mod_ref
...
- Attachment:
refmod.diff
Description: Binary data
Attachment:
pmap.refmod.debug.diff
Description: Binary data