Re: New pmap status update

Jason Thorpe <[email protected]> Sun, 14 Dec 2025 18:15:56 -0500
Newsgroups gmane.os.netbsd.ports.m68k
Message-ID <[email protected]>
> On Dec 14, 2025, at 4:55=E2=80=AFPM, Jason Thorpe <[email protected]> =
wrote:
>=20
>> On Dec 14, 2025, at 9:25=E2=80=AFAM, Izumi Tsutsui =
<[email protected]> wrote:
>>=20
>> I've tried SMALL020 kernel (i.e. traditional pmap) around 20251207
>> (via netboot) and unfortunately it gets panic() due to another
>> TAS instruction in _kernel_lock() (maybe __cpu_simple_lock_try()?):
>=20
> Yes, looks like it=E2=80=99s __cpu_simple_lock() and/or =
__cpu_simple_lock_try().  I=E2=80=99ll add a __HAVE_M68K_BROKEN_RMC =
check in <m68k/lock.h> and make it use _atomic_cas_32() in that case.

Ok, this one is a little annoying because __cpu_simple_lock_t is 8-bit, =
and I need a 32-bit datum for the kernel restartable atomic sequence.

    https://www.netbsd.org/~thorpej/m68k-simple-lock-rmc-fix.txt

I=E2=80=99m not entirely satisfied with that solution, if only because =
it feels a little gross.

__cpu_simple_lock_t is exported to user-space, too (used by libpthread), =
so this patch can=E2=80=99t quite go in 100% as-is; at the very least, =
I=E2=80=99ll need to conditionalize it on _KERNEL and fix up libpthread =
another day.  (Actually, this applies to the other user-space atomic(3) =
ops, as well.)

-- thorpej