Merge commit bfb276e55c76 from upstream OpenZFS (by Jessica Clarke)
Once upon a time, 32-bit PowerPC did indeed have a 32-bit time_t, but
FreeBSD 12.0 switched to a 64-bit time_t for PowerPC as an ABI break,
which predates the addition of FreeBSD support to OpenZFS. Moreover,
64-bit PowerPC has existed since FreeBSD 9.0, where __powerpc__ is also
defined (alongside __powerpc64__ to disambiguate), which has always had
a 64-bit time_t. This code has therefore always been wrong for all
PowerPC variants. Fix this by limiting the 32-bit case to just i386,
which is the only architecture in FreeBSD to have a 32-bit time_t and
not have broken ABI, due to its special legacy compatibility status.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Jessica Clarke <jrtc27 at jrtc27.com>
Closes #18217
Closes #18218
Reported by: fuz
[3 lines not shown]
Merge commit bfb276e55c76 from upstream OpenZFS (by Jessica Clarke)
Once upon a time, 32-bit PowerPC did indeed have a 32-bit time_t, but
FreeBSD 12.0 switched to a 64-bit time_t for PowerPC as an ABI break,
which predates the addition of FreeBSD support to OpenZFS. Moreover,
64-bit PowerPC has existed since FreeBSD 9.0, where __powerpc__ is also
defined (alongside __powerpc64__ to disambiguate), which has always had
a 64-bit time_t. This code has therefore always been wrong for all
PowerPC variants. Fix this by limiting the 32-bit case to just i386,
which is the only architecture in FreeBSD to have a 32-bit time_t and
not have broken ABI, due to its special legacy compatibility status.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Jessica Clarke <jrtc27 at jrtc27.com>
Closes #18217
Closes #18218
Reported by: fuz
MFC after: 1 day
kqueue: Make kn_sfflags unsigned
This is used to hold a copy of the original fflags, which is unsigned.
MFC after: 3 days
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D55348
sh.1: Reference editline(7)
Key bindings for command line editing are documented in editline(7).
MFC after: 3 days
Reviewed by: jilles, ziaee
Differential Revision: https://reviews.freebsd.org/D54767
devmatch: Add SPDX-License-Identifier tag
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55271
nvme: Fix sim unit number to match nvme device
The CAM sim unit numbner should match the nvme device number. We need
this to match unit numbers in some wiring scenarios. For example:
hint.nvme.0.at="UEFI:PciRoot(0x3)/Pci(0x1,0x1)/Pci(0x0,0x0)"
hint.nvme.1.at="UEFI:PciRoot(0x3)/Pci(0x1,0x2)/Pci(0x0,0x0)"
hint.nvme.2.at="UEFI:PciRoot(0x3)/Pci(0x1,0x3)/Pci(0x0,0x0)"
hint.nvme.3.at="UEFI:PciRoot(0x3)/Pci(0x1,0x4)/Pci(0x0,0x0)"
hint.scbus.33.at="nvme0"
hint.nda.0.at="scbus33"
hint.scbus.34.at="nvme1"
hint.nda.1.at="scbus34"
hint.scbus.35.at="nvme2"
hint.nda.2.at="scbus35"
hint.scbus.36.at="nvme3"
hint.nda.3.at="scbus36"
If the devices that are nvme0 and nvme3 are the only ones populated, you
[6 lines not shown]
nvme: fix panic if we boot w/o a namespace
If we format a drive, and then crash, we'll come back up. nvme_sim_ns
device won't attach because we don't have a namespace. Some drives (all?
I couldn't find it in the standard) send an AER with a namespace change,
which causes a NULL dereference because s_sim wasn't initialized because
we didn't attach. So, if we get into the ns_changed routine, bail early
if we didn't attach. We'll attach later, and deal with the ns correctly
if it's really there, or not attach one if it's not.
Sponsored by: Netflix
fortune: fix netstat tip
netstati <mumble> 8 reports in bytes per second (averaged over 8
seconds) rather than bits per second because it reports the total
in bits over the 8 seconds...
Sponsored by: Netflix
git-arc: Tweak heuristic for email address
In the email address heuristic, assume guest-* are external
contributors. It's a new convention, apparently.
Sponsored by: Netflix
intrng: Shuffle unhandled interrupts too
When interrupt vectors are first allocated, they get assigned to
CPU #0; at SI_SUB_SMP / SI_ORDER_SECOND (aka once we have multiple
CPUs), the intr_irq_shuffle SYSINIT clears their CPU sets with the
effect of forcing them to be assigned to new CPUs later.
In case where interrupt vectors were allocated *but not yet bound*
this code did not run, with the effect that those interrupts would
remain pinned to CPU #0 forever. This affected the ena(4) driver,
which allocates interrupts for I/O when the device is attached but
doesn't set them up until the interface is brought up much later in
the boot process (and, crucially, long after intr_irq_shuffle runs).
Adjust intr_irq_shuffle to clear the CPU set for an interrupt source
even if it currently has no handlers, so that it will be properly
assigned to a CPU when it is used later.
Reviewed by: andrew, mhorne
[3 lines not shown]
pcib: Assume a window where both the base and limit are 0 is uninitialized
Since the low bits of a window's limit are hardwired to 1, this
configuration looks like a minimally sized window at address 0.
However, PCI resources are not generally at address 0 (see the
__PCI_BAR_ZERO_VALID macro that was only defined on sparc64), and some
PCI-PCI bridges report these register values after a reset. The
result today is a lot of spam in dmesg as the minimally-sized windows
fail to allocate. By ignoring these windows and treating them as
closed the end result is the same, but there is less spam during boot.
Reported by: jrtc27
Differential Revision: https://reviews.freebsd.org/D43922
