VM_KERNEL_PT_PAGES is an old-pmap parameter, so segregate it to
the old-pmap, and default it there to a common value that individual
platforms can override if desired.
Fix riscv sqlite3 builds
It appears that with our gcc, there's no int128_t defined for
the riscv architecture, so comment out the "|| defined(__riscv)"
(2 places) which enables it.
This should fix the riscv builds of HEAD after the recent sqlite3
update.
__HAVE_PMAP_PHYSSEG an old-68k-pmap construct, so put it and associated
declarations into <m68k/pmap_motorola.h>, and remove it from all of the
m68k vmparam.h's.
Centralize the definitions of MAXTSIZ, DFLDSIZ, MAXDSIZ, DFLSSIZ,
an MAXSSIZ across all m68k platforms. Notable callouts:
- default values for 68010 come directly from sun2, but will be suitable
for any additional 68010 systems that may appear in the future.
- Sun3 MMU dictates more conservative limits than the rest of the 68020+
crowd.
- Amiga is odd-one-out and keeps the previous values (it has an odd-ball
USRSTACK, too).
macekbc: fix byte transmit to properly inhibit clock line first
The PS/2 "specification" requires the controller to inhibit
the clock line for 100uS before trying to transmit. This tells
the device (in this case a bunch of ps/2 mice) to stop transmitting,
get ready for receive and get ready to send the clock out to the
controller to send said bits.
The mice in question work fine on the O2 PROM, so it's not a
hardware issue per se.
After staring at traces with a logic analyser it looks like the
controller is NOT doing this in hardware - it immediately attempts
to transmit bytes and if the ps/2 device doesn't handle that,
it will simply never send out clock pulses for the controller to
clock the byte out.
So:
[10 lines not shown]
old malloc(3): Use mutex_init, not mutex_unlock, in child post-fork.
Using mutex_unlock may try to wake a thread that doesn't exist in the
child, which could lead to trouble such as crash or deadlock. But
since the child is single-threaded, it is safe to just reinitialize
the mutex memory anyway.
PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
osnet libuutil: Use mutex_init, not mutex_unlock, in child post-fork.
Using mutex_unlock may try to wake a thread that doesn't exist in the
child, which could lead to trouble such as crash or deadlock. But
since the child is single-threaded, it is safe to just reinitialize
the mutex memory anyway.
PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
libbsdmalloc: Use mutex_init, not mutex_unlock, in child post-fork.
Using mutex_unlock may try to wake a thread that doesn't exist in the
child, which could lead to trouble such as crash or deadlock. But
since the child is single-threaded, it is safe to just reinitialize
the mutex memory anyway.
PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
arc4random(3): Use mutex_init, not mutex_unlock, in child post-fork.
Using mutex_unlock may try to wake a thread that doesn't exist in the
child, which could lead to trouble such as crash or deadlock. But
since the child is single-threaded, it is safe to just reinitialize
the mutex memory anyway.
PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
workaround a crash on m68k native buiding libnbcompat.
use -O1 when building tree-vect-slp.cc which avoids a crash in this
file when it compiles a bunch of not very complex things at -O2.
this seems to make GCC 14 m68k stable for me. at least, i'm able
to build tcsh and perl5 now, and a few more things.
