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.
Update to 2026b, previous was 2026a
Release 2026b - 2026-04-22 23:06:43 -0700
Changes to code
zic no longer mishandles a last transition to a new time type.
zic no longer overflows a buffer when generating a TZ string like
"PST-167:59:58PDT-167:59:59,M11.5.6/-167:59:59,M12.5.6/-167:59:59",
which can occur with adversarial input. (Thanks to Naveed Khan.)
zic no longer generates a longer TZif file than necessary when
an earlier time zone abbreviation is a suffix of a later one.
As a nice side effect, zic no longer overflows a buffer when given
a long series of abbreviations, each a suffix of the next.
(Buffer overflow reported by Arthur Chan.)
zic no longer overflows an int when processing input like `Zone
[4 lines not shown]
For machines where the real time clock is off or not existing:
- offer a config menu to set date and time
- at build time burn the unix time of the build into the binary (or the
reproducable build timestamp)
- when the current clock claims we have a date older than two days before
the embedded build time, show an error message and go to the date and
time setup step automatically
