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.
PR/60214: panic: kernel diagnostic assertion "(armreg_ttbcr_read() & TTBCR_S_PD0) != 0" failed
TTBCR.PD[01] are only present in an implementation that includes the Security
Extensions. Relax the KASSERTs so that TTBCR.PD[01] value checks are only done
when security extensions are present
ahcisata(4): disable NCQ for VIA VT8251 integrated SATA controller.
NCQ support is known to be non-compliant or broken on this chipset,
causing timeouts and instability.
The issue is reproducible in NetBSD using 'smartctl -a`.
The workaround is to disable NCQ, which has already been done in other
OS drivers.
Needs pullups to supported branches.
Support non-static mappings, allocating space from kernel_map.
Still TODO: platform-specific hook for a vmem arena that supplies
the VAs for a given bus.
Add bus_space_mmap() to the simple implmentation, and provide a default
implementation that returns failure; if a platform wants to support this,
it will need to provide a _bus_space_mmap() implementation that matches
the address ranges that are to be supported for this operation.
