Deal with the absolutely pathological handling of the IDENTIFY command
on big-endian systems.
In wdc_datain_pio(), in the ATA_DRIVE_NOSTREAM case, if the bus.h
implementation does does not have __BUS_SPACE_HAS_STREAM_METHODS
and the system is _BIG_ENDIAN, individually swap each 16-bit value
rather than assuming the bus_space_read_*2() implementation will do
it.
This is necessary because IDENTIFY is treated differently than every
other command; all callers assume it will be returned in host-order,
when in reality it's an array of 256 16-bit little-endian integers (even
the string fields).
Ultimately, the correct fix is to stop special-casing IDENTIFY, but
that is a much larger change due to the confusing array of flags that
control I/O size and disposition, and requires much wider testing.
vflushbuf: Print `vflushbuf: dirty' warning only once per call.
And do it only under DEBUG, and rate-limit it globally.
This can happen when vflushbuf is competing with an onslaught of
concurrent I/O on a snapshot or block device (which is done without
holding the vnode lock, despite what the comment says). That
concurrent I/O might be happening indefinitely, so we are likely to
have to print a _lot_ of warnings, potentially overwhelming the
console, until the underlying problem is fixed by teaching vflushbuf
to wait only for the writes that began before have completed, not
also all writes that have begun since.
This stop-gap measure intended to be low-risk for pullup to release
branches.
PR kern/60531: looping "vflushbuf: dirty" message
gcc/arm: For -mtp=soft, ensure stack alignment in leaf functions using
thread local storage.
For each function compiled, record whether it accesses thread-local
storage. When laying out the stack frame for a leaf function, if the
function needs to use a C runtime subroutine to retrieve the thread
pointer, make sure that the stack pointer is aligned appropriately.
PR lib/57638: thread local storage broken on evbarm (armv5)
Upstream bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126394
ok skrll@ riastradh@
/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
