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