Stop installing psinfo.d dtrace script.
It uses `u_int` and `struct proc`, but no definitions are available.
This causes problems when dtrace is used for pkgsrc, see e.g.
wip/modular-xorg-server.
rump: Handle uvm_wait tickets like the real kernel does.
This should avoid trouble in any path that calls uvm_wait_prepare
with spin locks held even though it's not going to sleep in uvm_wait,
of which there are probably many more than just rump_hypermalloc --
uvm_wait_prepare is supposed to be cheap enough not to be worth
conditionalizing. (Perhaps we should measure that, though.)
PR kern/60636: rump on sparc64 totally broken still with vm.c rev 1.201
Followup for:
PR kern/58964: uvm: missing wakeup on uvmexp.free
PR kern/60029: panic: cpu0: softints stuck for 16 seconds
rump_hypermalloc: Don't get a uvm_wait ticket if we won't uvm_wait.
This path may be taken with a spin lock held, which means we can't
take pdaemonmtx (IPL_NONE).
PR kern/60636: rump on sparc64 totally broken still with vm.c rev 1.201
Followup for:
PR kern/58964: uvm: missing wakeup on uvmexp.free
PR kern/60029: panic: cpu0: softints stuck for 16 seconds
tests/dev/fss: New test of internal snapshots.
Verify that ls(1), find(1), and file(1) identify them as such too.
PR bin/60379: file(1) should recognize snapshot files
PR bin/60380: find(1) can't find snapshots
rump uvm: Allow uvm_wait_prepare before uvm_init.
Probably not worthwhile to figure out how to restructure rump
initialization.
Fixes total failure of rump after changes for:
PR kern/58964: uvm: missing wakeup on uvmexp.free
PR kern/60029: panic: cpu0: softints stuck for 16 seconds
string_to_flags(3): Put `snap' under #ifdef SF_SNAPSHOT.
Same as in flags_to_string(3). Not really sure why, but let's keep it
consistent so there's only one question to ponder and not two.
PR bin/60380: find(1) can't find snapshots
libc: Suggest another major bump task.
Prompted by noting that stdlib.h and libc are maybe not the right
place for this API in:
PR lib/60635: humanize_number(3): exa/exbi issues
uvm: Fix missed wakeups and reduce lock contention a little bit.
This addresses two problems under heavy load:
(a) uvm_wait would sometimes miss wakeups, causing various processes
system to hang but then recover from `call wakeup(uvmexp+0x10)'
in ddb:
PR kern/58964: uvm: missing wakeup on uvmexp.free
(b) Contention on uvmpd_lock would lead to so much time spent at
IPL_SOFTBIO softint context in uvm_pageout_done spinning for
uvmpd_lock that it would trip heartbeat panics:
PR kern/60029: panic: cpu0: softints stuck for 16 seconds
There are three intertwined parts to this, which I tried to split
into separate commits, but I eventually decided it wasn't worth the
trouble:
[87 lines not shown]
pool(9): Nix useless PR_GROWINGNOWAIT bit.
This was introduced back in 2017 as an attempt to avoid spurious
failure in concurrent PR_NOWAIT allocations, while still serializing
calls to the pool's back end allocator to avoid fragmentation:
https://mail-index.NetBSD.org/source-changes/2017/12/16/msg090490.html
However, this probably doesn't work very well when one pool_get call
in the middle of pool_grow is _interrupted by_ another one (in an
interrupt handler) -- the busy wait will turn into a deadlock:
https://mail-index.NetBSD.org/current-users/2017/12/29/msg033000.html
So the logic was changed to keep holding the lock across the backing
allocator in PR_NOWAIT allocations -- this way, calls to the pool's
back end allocator are still serialized, but we at least avoid
holding the lock _while sleeping_ in the back end allocator:
[9 lines not shown]
make: fix newline in word splitting
The newline character behaved differently depending on whether it
occurred at the beginning of a word or in the middle of it. In the
middle, it didn't act as a word separator but instead stopped splitting,
thereby ignoring any following words. This behavior was neither
documented nor to be expected. It probably came from a time before 1993
where the makefiles were read as a single block of text instead of
splitting them into lines first.
Pull up following revision(s) (requested by tsutsui in ticket #420):
sys/arch/sun68k/stand/libsa/sun3.c: revision 1.12
sys/arch/sun68k/stand/libsa/sun3.c: revision 1.13
sys/arch/sun68k/stand/libsa/version: revision 1.7
sun68k: fix typo in physical address calculation in dev3_mapin()
This typo was introduced in the sun3/sun3x merge 28 years ago,
so maybe harmless.
sun68k: avoid PROM DVMA map aliasing in sun3 bootloader
NetBSD/sun3 11.0 GENERIC fails to boot from a SCSI disk on
my Sun 3/60 with at least PROM revisions 2.8.3 and 3.0.1.
It looks sun3 PROM SCSI driver allocates internal resources
in DVMA space starting at 0xfff00000. The sun3 standalone
[26 lines not shown]
