/bin/sh - trap.c - add missing line from previous
Somehow, some cretin forgot to add a required line to the
change to avoid lost memory.
Weirdly, it seems the only observed effect was a particularly odd
ATF test of use of the (no-one ever uses it like that) -n option.
It really could have been much worse than that. You don't want
to be missing this fix.
If OFW power-off returns without an error, wait 2 seconds before panicing.
This removes the confusing, and usually truncated, message on the console
just before the machine powers off:
"Skipping crash dump on recursive panic"
Message noticed on newer machines (SB2500S and U45) where there is a small
delay before they power off.
syslogd: Preserve full partial klog line when buffering
Buffer incomplete /dev/klog lines from the start of the original
line instead of the parse position. Otherwise, split messages
lose the BSD syslog priority prefix when reconstructed.
Fixed by Kenichi Suzuki at IIJ.
syslogd: Fix buffering of partial klog lines
When a /dev/klog read ends without a newline, the remaining data
is buffered for the next read. The code mistakenly copied the data
into linebuf instead of klog_linebuf, breaking reconstruction of
split log messages.
Found and fixed by nonaka@ and Kenichi Suzuki at IIJ.
cut.1 & paste.1: add HISTORY and AUTHORS
Sourced from OpenBSD and FreeBSD, which both reference the same post[1]
for part of it. They differ in certain details.
FreeBSD puts the additional credit to Marciano Pitargue in the wrong
utility, going by the source code credits (and what OpenBSD has). There
is discussion in the FreeBSD review[2] about which originating release
is relevant for cut(1) (32V vs. System III), as both BSDs referenced
32V for paste(1). This was perhaps confused in the FreeBSD review,
which talks directly about cut(1), but was applied also to paste(1). An
earlier FreeBSD commit specifically lists 32V for paste(1)[3]. (I don't
have 32V to examine.)
These histories could be subject to further cut and paste...
1. https://www.tuhs.org/pipermail/tuhs/2020-January/019955.html
2. https://reviews.freebsd.org/D36048
3. https://github.com/freebsd/freebsd-src/commit/30f8b6c18279162a2f4efdc9e85a49683a8aafbf
All M68040 configs require FPSP, and all M68060 configs require M060SP,
so just make M68040 and M68060 dependent on their respective software
packages rather than having to duplicate the options across every kernel
config.
Re-factor the MVME-1xx kernel configs to reduce duplication. Further
shrink the VME* configs to be much closer to "bare minimum for this
machine" to help out small memory config units (4MB base RAM on some).
/bin/sh - builtin read command fixes (miscbltin.c)
This corrects a change made in the previous version, where
in addition to the intended change, making a read error be
treated differently than EOF, a change with unplanned
consequences was also made, to treat the EINTR read error
as a "try again" signal, rather than as a read error.
That meant that caught traps no longer interrupted the read,
and while that is how (some) other shells do it (like bash)
it was a change to how our shell does things.
So, now there is (in normal shells) a new -c (continue) option
to cause this behaviour, when given, a trapped signal will be
processed during the wait for input by the read built-in utility,
but not end the read. When absent, the trap will still be processed
while the read is in progress, but will be treated as a read error
(and produce the special (>1) exit code 130.
While doing this, revert all these changes for SMALL shells, they
[4 lines not shown]
/bin/sh - trap.c - new func and avoid lost memory
Add run_traps() - which is just dotrap() except that it
preserves the state of the stack around the trap executions,
so is safe to call with the stack in any state. It will also
preserve the state of the growing string at the top of the
stack if informed (by giving a non-zero value as its arg)
that such a string currently exists. This new function does
not exist in SMALL shells.
While here, fix an unlikely memory leak - if a shell error
(not command error) occurs while processing a trap in dotrap()
the copy of the trap string being parsed can be lost. This is
irrelevant in non-interactive shells, as the errors which would
cause this loss, also cause a non-interactive shell to exit,
the lost memory is only lost for a very short time. Interactive
shells rarely set traps (except possibly an EXIT trap - for which
the memory loss is also immaterial for almost the same reason) at
all, and if one were set, and generated a shell error (typically
[3 lines not shown]
/bin/sh - memalloc.h - added STSTRLEN()
Add a new stack string macro STSTRLEN() which returns the
current length of the string being accumulated at the top
of the (shell) stack. As with all the other Stack String
macros, it may only be used between a STARTSTACKSTR() call
and the next call which allocates stack space (often
grabstackstr(), but stalloc() stunalloc() grabstackblock()
all count for this). Use at any other time will give
meaningless unspecified results.
* Avoid calling assume_default_colors because this in turn, calls
_change_pair which dirties lines resulting in a blank screen iff
stdsrc is not being used.
* Restore line dirtying code to __change_pair since makech() no longer
indirectly calls it.
PR/60522: evbppc/RB800 hits MI pmap KASSERT failure
Revert the pmap_protect part of
Fix two EXECness issues
- when creating a WX mapping via pmap_enter mark the page as EXEC
- when pmap_protect adds X then ensure that pmap_page_syncicache is called
for the page.
It seems that pmap_pte_protect is designed to remove a protection and not
add it.
For the module loading the text is indeed mapped eXecute initially, and
cache maintenance is currently handled by kobj_machdep and not the pmap.
sys/dev/pci/mpii.c: Reduce MPII_REQUEST_CREDIT to improve stability.
This should fix PR#58684, at least it does in my case on a
host with a "Symbios Logic SAS3008 (rev. 0x02)" controller.
Admittedly, this is a band-aid fix, but it's the best we could come
up with to solve the PR, and it does not appear to have significant
performance implications, at least not in a single-drive configuration.
So, better to be stable / functional than not.
