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]
Pull up following revision(s) (requested by tsutsui in ticket #1329):
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]
Pull up following revision(s) (requested by gutteridge in ticket #1328):
tests/usr.bin/grep/d_pr60552: revision 1.1
tests/usr.bin/grep/Makefile: revision 1.3
distrib/sets/lists/tests/mi: revision 1.1425
tests/usr.bin/grep/t_grep.sh: revision 1.10
tests/usr.bin/grep/t_grep.sh: revision 1.11
grep(1): Test screw case of case-insensitive match with colour.
PR bin/60552: /usr/bin/grep failure under AMD64
grep(1): Nix xfail on new test for PR 60552 screw case.
I was planning to do this in the same commit that fixes it, to keep
the history of bugs and fixes tidy, but gutteridge@ beat me to
committing the fix.
PR bin/60552: /usr/bin/grep failure under AMD64
Pull up following revision(s) (requested by gutteridge in ticket #419):
tests/usr.bin/grep/d_pr60552: revision 1.1
tests/usr.bin/grep/Makefile: revision 1.3
distrib/sets/lists/tests/mi: revision 1.1425
tests/usr.bin/grep/t_grep.sh: revision 1.10
tests/usr.bin/grep/t_grep.sh: revision 1.11
grep(1): Test screw case of case-insensitive match with colour.
PR bin/60552: /usr/bin/grep failure under AMD64
grep(1): Nix xfail on new test for PR 60552 screw case.
I was planning to do this in the same commit that fixes it, to keep
the history of bugs and fixes tidy, but gutteridge@ beat me to
committing the fix.
PR bin/60552: /usr/bin/grep failure under AMD64
libarchive: Avoid collision with LIBARCHIVE variable in makefile.
It was both the path to the .a file for DPADD, and the path to the
source directory. Can't be both, and the source directory is purely
local while the .a file is used in other makefiles, so let's call the
source directory LIBARCHIVEDIR instead.
Found while trying to diagnose:
PR lib/60560: libarchive tests are failing
