If BUS_DMA_24BIT is defined, clear it from the flags passed to
_bus_dmamem_alloc_common(), since we've already constrained the
allocation based on the window configured for the selected VME
address space.
Merge mvme68k and virt68k bus_dma into the common m68k bus_dma and
remove their local copies. Minor cleanup tweaks to other platforms
that already use the common version.
Pull up following revision(s) (requested by yamt in ticket #241):
etc/etc.amd64/MAKEDEV.conf: revision 1.38
amd64 MAKEDEV: create 8 nvme (nvme0-nvme7) by default
why 8?
- match ld, sd, wd
- my machine has 6 of them
Pull up following revision(s) (requested by skrll in ticket #250):
tests/lib/libc/setjmp/t_sigstack.c: revision 1.26
lib/libc/compat/arch/arm/gen/compat_setjmp.S: revision 1.7
arm: fix PR/57946 for compat
Make longjmp restore stack first before restoring signal mask for
arm/compat.
arm is fixed.
Pull up following revision(s) (requested by yamt in ticket #249):
lib/libkvm/kvm_proc.c: revision 1.102
lib/libkvm/kvm_proc.c: revision 1.103
lib/libkvm/kvm_proc.c: revision 1.104
libkvm _kvm_ureadm: remove a redundant check
libkvm _kvm_ureadm: fix anon address calculation
this has been broken since the initial uvm support in 1998.
libkvm _kvm_ureadm: fix an integer overflow
this has been broken since the initial uvm supporT in 1998.
I suppose it was rare to use >2GB swap in that era.
Pull up following revision(s) (requested by hgutch in ticket #248):
lib/libcurses/addbytes.c: revision 1.71
lib/libcurses/attributes.c: revision 1.37
lib/libcurses/insdelln.c: revision 1.25
lib/libcurses/add_wch.c: revision 1.11
lib/libcurses/touchwin.c: revision 1.36
lib/libcurses/refresh.c: revision 1.131
libcurses: fix wrong NULL guard
Move the NULL guard in _cursesi_waddbytes() out of #ifdef DEBUG .
Delay initialization of all variables that require dereferencing pointers
that might be NULL until after the NULL guards. This is what KNF calls
for anyway.
Fixes PR lib/60153 .
Pull up following revision(s) (requested by mrg in ticket #247):
external/gpl3/gcc.old/dist/gcc/genmatch.cc: revision 1.2
(applied to external/gpl3/gcc/dist/gcc/genmatch.cc)
tools/gcc/gcc-version.mk: revision 1.32 (via patch)
genmatch.cc: bring across several enhancements from mainline GCC.
in my testing this reduces the size of the emitted "gimple-match.cc"
by about 35%, reduces the code section sise about 15%, and reduces
the compile time about 30%. (this file is the largest single compile
for all of GCC.)
this makes it capable of compiling on vax and sparc again, it seems,
where both were already capable for GCC 14 (which in addition to this
set, splits the emitted file into 10 sub parts for compiling both
separately and in parallel.)
(this is part 1, part 2 will be about mergig the split of the output
[25 lines not shown]
Pull up following revision(s) (requested by kre in ticket #246):
bin/sh/expand.c: revision 1.149 (partly, via patch)
While here, fix another, identical land mine, that
has been buried in the absolute wilderness for years.
Someone would have stepped on it one day.
Also fix a field splitting bug handling : or = in
IFS when generated from ${var-string1:string2} type
expansions. This one is even older.
Pull up following revision(s) (requested by yamt in ticket #245):
external/gpl3/gcc.old/dist/gcc/cfgexpand.cc: revision 1.2
(applied to external/gpl3/gcc/dist/gcc/cfgexpand.cc)
PR/59994 gcc/m68k generates bad code for stack protector
Record the alignment of the stack canary before allocating space for
it in a stack frame.
Generate an assignment expression to initialise the canary instead of
emitting a move instruction.
Pull up following revision(s) (requested by yamt in ticket #242):
sys/uvm/uvm_pdaemon.c: revision 1.135
sys/uvm/uvm_pdaemon.c: revision 1.137
sys/uvm/uvm_pdaemon.c: revision 1.138
sys/uvm/uvm_swap.c: revision 1.210
Add more debugging.
To help understand PR 56764 better.
Ok riastradh@
Disable a kassertmsg.
This triggers for me quite reliably over years now, and has been
tracked in PR 56764, with no resolution.
It seems the asserted inequality just is not correct.
uvmpd_scan_queue: remove ENABLE_UNRELIABLE_CHECK_PR_56764 block
while this condition is true in most of times, we can't
[8 lines not shown]
Pull up following revision(s) (requested by yamt in ticket #240):
sys/dev/nvmm/x86/nvmm_x86_vmx.c: revision 1.93
nvmm_x86_vmx.c: fixes tprof stalls
the current implementation of nvmm nmi handling is
simple; just drops them. it interferes other nmi-using
components in the system, including tprof.
this commit makes nvmm try to dispatch nmis by itself.
while this is imperfect, it's good enough to give
tprof a chance to unmask LAPIC_LVT_PCINT.
i guess svm VMCB_EXITCODE_NMI needs something similar.
but i have no hardware. if someone wants to test a patch,
please let me know.
reproduce recipe:
1. run "tprof top" in a terminal. leave it running.
[2 lines not shown]
Pull up following revision(s) (requested by yamt in ticket #239):
sys/uvm/uvm_mmap.c: revision 1.189
sys_mincore: stop locking potentially huge amount of user memory
the current implementation performs uvm_vslock() on the
user-specified amount of memory. it isn't safe in general.
some might even consider it as a security issue.
this commit fixes it by splitting the user-specified range into
small ones which a temporary kernel buffer can cover. it's ok to
report potentially stale values as the mincore() api is inherently
racy in the first place.
while we still ought to invent a proper "lock user memory for
direct i/o" infrastructue, in this particular use case, it isn't
necessary or appropriate.
Pull up following revision(s) (requested by yamt in ticket #238):
sys/uvm/uvm_mmap.c: revision 1.188
uvm_mmap.c: fix overflow check
this is my best guess of the intention of the original code,
where "*addr + *size < *addr" seems always false because "*size" is 0.
Pull up following revision(s) (requested by yamt in ticket #236):
sys/kern/kern_time.c: revision 1.232
make posix timer family functions reject itimer timer ids
we provide two sets of similar apis:
* BSD itimer api (setitimer, ITIMER_xxx, and friends)
* posix timer api (timer_create and friends)
for some reason, some of posix timer functions
(namely timer_settime, timer_gettime, timer_getoverrun,
timer_delete) are allowed to operate on timer_id=2,
which actually belongs to the BSD itimer. (ITIMER_PROF)
it seems that it has always been this way since they were
introduced on the nathanw_sa branch in 2001.
10 years later, in 2011, it got a bit worse by the addition
of ITIMER_MONOTONIC, which is also accepted by the posix
[5 lines not shown]
Pull up following revision(s) (requested by yamt in ticket #235):
sys/kern/kern_proc.c: revision 1.281
lib/libkvm/kvm_proc.c: revision 1.101
sysctl_doeproc: fix an argument check
this commit fixes a regression in 2015, which made
kvm_getprocs(KERN_PROC_ALL) always fail.
("implementation of KERN_PROC_PATHNAME, some refactoring for KERN_PROC.")
libkvm: fix kvm_getargv/kvm_getenvv
these functions always fail because of a regression in 2022.
("read the ps arguments from the correct place.")
this commit restores them by adding a missing p_psstrp initialization.
Pull up following revision(s) (requested by yamt in ticket #234):
sys/arch/x86/x86/tsc.c: revision 1.64
x86 tsc: decrease the timecounter quality for NVMM
NVMM vcpu loses its TSC "ticks" when switching to a different host cpu.
from the POV of the guest OS (ie. this code), it's observed as random
TSC drifts, which makes it unsuitable for a timecounter source.
Pull up following revision(s) (requested by yamt in ticket #233):
sys/kern/sched_4bsd.c: revision 1.48
sched_4bsd.c: honor the upper bound of l_estcpu
otherwise, certain threaded workloads can quickly
accumulate too large l_estcpu.
this change fixes mysterious long (eg 10 seconds) pauses
i've seen occasionally with git. git seems to spawn worker
threads internally these days and happens to hit the condition
of this bug. with very large l_estcpu, the lwp gets effective
priority 0 for a long time. on a busy system, such an lwp
basically will never get a chance to run until the estcpu decay
will eventually make it possible to run again.
it seems this bug has been there since 2007.
("Merge scheduler changes from the vmlocking branch")
[3 lines not shown]
Pull up following revision(s) (requested by yamt in ticket #232):
sys/dev/acpi/apei_hest.c: revision 1.8
apei_hest: fix a zero-sized kmem_zalloc issue
zero-sized kmem_zalloc is illigal.
this fixes a crash seen on HP Z4 G4.
when installing netbsd 10.1 on the machine, i had to
work this around by "userconf disable apei" and
```
userconf=disable apei*
```
in boot.cfg.
"acpidump -dt" on the machine said:
```
Error Source Count=0
```
[14 lines not shown]
