Back when Makefile.lib32 was turned into Makefile.libcompat, a typo was
introduced; it should have been LIBCOMPATDTRACE, but instead gained a
dollar sign in it as LIB$COMPATDTRACE (and with COMPATDTRACE not being
defined, was equivalent to ${LIB:U${DTRACE}}). This then meant it was
not converted to LIB${_LIBCOMPAT}DTRACE in 91d7edd549 ("Generalise
libcompat to be a list rather than a single option") and instead left
broken. Belatedly fix this long-standing seemingly-inconsequential bug.
Fixes: dba75e9fa5 ("Move Makefile.lib32 to Makefile.libcompat and generalize it.")
OpenSSL's BN_zero API has had a void return value since 1.1.x: chase the
change to unbreak the build on OpenSSL 3.x with MK_GH_BC == no.
MFC after: 2 weeks
Reviewed by: emaste, kevans
Differential Revision: https://reviews.freebsd.org/D41410
Without this patch got_sighup(), which is the SIGHUP handler,
would set a variable of type int.
This would appear to be incorrect, although it has worked reliably.
This patch changes the type to "_Atomic(int)", which appears
to be all that is needed to correct it.
Reported by: pen@lysator.lui.se
Reviewed by: theraven, karels (prev version), kevans (prev version)
Differential Revision: https://reviews.freebsd.org/D41265
uint64_t is not sufficient alignment for allocators on all platforms.
On a CHERI platform pointers require 16 byte alignment, but also if a
type contained a uint128_t or long double it would not be aligned
correctly either. C11 added max_align_t precisely to provide a
portable type for allocators to use.
Reviewed by: melifaro
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D41301
If a slot is freed that isn't the last one, we'll set its destructor to
NULL to indicate that it's been freed and leave a hole in the slot map.
Check osd_destructors in osd_call() to avoid dereferencing a method that
is potentially from a module that's been unloaded.
This scenario would most commonly surface when two modules are loaded
that osd_register(), then the earlier one deregisters and an osd_call()
is made after the fact. In the specific report that triggered the
investigation, kldload if_wg -> kldload linux* -> kldunload if_wg ->
destroy a jail -> panic.
Noted in the review, but left for follow-up work, is that the realloc
that may happen in osd_deregister() should likely go away and the
assumption that reallocating to a smaller size cannot fail is actually
not correct.
Reported by: dim
Reviewed by: markj, jamie
Differential Revision: https://reviews.freebsd.org/D41404
If the root fs is forcibly unmounted then basically every process
will die with a SEGV as soon as it tries to run again because libc.so
is gone, which leaves the system basically hung. It seems better
to just panic instead, so let's do that.
Requested-by: karels
Reviewed-by: imp, mckusick, karels
Sponsored-by: Netflix
Differential Revision: https://reviews.freebsd.org/D41387
Use IXGBE_GRC_BY_MAC(hw) macro instead of IXGBE_GRC as IXGBE_GRC's
address is different on Denverton platform.
This patch is part of change made in NetBSD kernel
by Masanobu Saitoh, NetBSD maintainer.
Differential Revision: https://reviews.freebsd.org/D19175
Approved by: erj
Vendor PR:
#15103 Remove zl_issuer_lock from zil_suspend()
Obtained from: OpenZFS
OpenZFS commit: 2848de11e516a2ef2e6baa574a60d77a6fb47023
Note: full vendor imports will continue when stable/14 has been branched
Vendor PR:
#15080 ZIL: Fix config lock deadlock
Obtained from: OpenZFS
OpenZFS commit: 2cb992a99ccadb78d97049b40bd442eb4fdc549d
Note: full vendor imports will continue when stable/14 has been branched
To send commands to the TPM device, bhyve can use the host TPM driver by
reading and writing from /dev/tpmX. Using this approach, only the host
TPM driver has to detect and interact with the physical TPM interface.
This simplifies bhyve's code much. As the host TPM driver has to
interact with the TPM regardless of bhyve making use of it or not, makes
it a good approach.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40460
Trap accesses to the CRB MMIO range and emulate them properly.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40459
Add support for the gpio controller found in the ZynqMP SoC.
The registers are the same as the Zynq 7000, just the number of
banks/pins per banks differs.
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 2 weeks
All other Zynq SoCs have the same GPIO controller, the only difference
is the number of banks/pins so make this driver more generic to add
other SoCs more easily.
No functional changes intended.
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 2 weeks
There is no list connecting all entries any more, and correspondingly no
order on the list entries.
Reviewed by: dougm
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential revision: https://reviews.freebsd.org/D41405
`INSTANTIATE_TEST_CASE_P` has been replaced with `INSTANTIATE_TEST_SUITE_P`.
Replace all uses of the former macro with the latter macro.
While here, address the fact that the latter macro doesn't permit some
of the constructions that the former macro did, e.g., empty parameters,
etc.
MFC after: 2 weeks
Reviewed by: asomers
Differential Revision: https://reviews.freebsd.org/D41398
GoogleTest 1.14.0 now requires C++14 to build. Change
`googletest.test.inc.mk` to reflect this requirement.
Adjust the build integration logic to handle the new version of
GoogleTest (add/remove headers/sources as needed).
Tighten down warnings via `CXXFLAGS.clang` instead of ignoring all
warnings. Some new warnings snuck in after I did my last round of fix
submissions upstream.
Also address some overlinking added in the previous version import by
removing superfluous libraries.
===============================
Expect WhenDynamicCastToTest.AmbiguousCast to fail
This change reapplies the expected failure from 1.10.0.
Ref: https://github.com/google/googletest/issues/2172
MFC after: 2 weeks
Reviewed by: asomers, emaste
Differential Revision: https://reviews.freebsd.org/D41399
Merge commit '8ef491440fcaec96f899d73e08873426c78583a4' into googletest-v1.14.0-import
The x550 uses an upgradable flash code. Check for recovery condition
like other flashable intel cards do in case of fw errors.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31869
Add the page pool skeleton based on a wireless driver. We have to
sort out some struct page problems first before we can start
implementing this but that should happen independent of all other
changes.
MFC after: 10 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D40250
When taking a UFS/FFS snapshot, it may not succeed for example if the
filesystem is too full to hold it. When a snapshot is unable to be
successfully taken, the partial snapshot should be removed.
Reported-by: Peter Holm
Tested-by: Peter Holm
MFC-after: 1 week
Sponsored-by: The FreeBSD Foundation
The pre-existing "ec2ami" target builds and uploads a single AMI
(with filesystem determined by ${VMFS}) as before; a new "ec2amis"
target does both UFS and ZFS.
Reviewed by: gjb
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41343
Prior to this commit, ${VMFS} controlled the filesystem used for
building EC2 images, but the AMIs were recorded with SSM Parameter
paths which indicated that they were UFS.
This commit (a) uses ${VMFS} in the SSM parameter path instead of
a hard-coded "ufs", and (b) adds the filesystem to the AMI name.
Reviewed by: gjb
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41342
New ${CW}_FSLIST settings control the list of filesystem types with which
each cloudware image will be built; currently these are all set to "ufs",
i.e. no change from previous.
The cloudware images have their filesystem type as part of their file
name; for backwards compatibilty the ${VMFS} image is linked to the
previously used file name. This compatibility can be removed once all
the cloudware uploading/publishing code has been updated to use the new
image names (possibly more than one of them).
Reviewed by: gjb
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41341
A new option 'VMFSLIST' controls the list of filesystems for which VM
images will be built; the default is to build both UFS and ZFS.
The vm-install target installs these as ${OSRELEASE}-${FS}.${FORMAT},
e.g. FreeBSD-14.0-CURRENT-amd64-zfs.vmdk. For backwards compatibility,
the ${VMFS} image is linked to the previously used ${OSRELEASE}.${FORMAT}
name.
Cloudware building will be updated in a later commit.
Reviewed by: gjb
Reviewed by: emaste, markj (previous version)
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41340
The MSI/MSI-X address includes 8 bits to encode the Destination ID.
Previously IDs over 255 overlapped with the fixed portion of the
address, resulting in an invalid value (and a nonfunctional interrupt).
Instead, print an error message and return EINVAL. The interrupt will
still not work, but the user will have a clue as to why.
PR: 273022
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41395
With the general removal of MIPS support there's no longer a need to
support these integrated switches.
Approved by: adrian
Differential Revision: https://reviews.freebsd.org/D41394
All of these are obsoleted by the general removal of MIPS support.
Actually, corresponding to the removed AH_SUPPORT_x, there is more
superfluous support sprinkled across the HAL source. However, that
code is left in place for now in order to ease a sync to NetBSD.
Reviewed by: emaste (w/ man page fix)
Approved by: adrian
Differential Revision: https://reviews.freebsd.org/D41355
The gic driver is also probed at this pass and depending on the order of
the nodes in the dts rk_i2c can be probed first and will fail, this is the
case for the rk3328 SoC.
The PMIC drivers are also probed at this pass but on the iicbus which is created
in rk_i2c so there is no order conflict here.
Fixes: ddefad7c4f ("arm64: rockchip: Tweak i2c, pmic and iodomain order")
Sponsored by: Beckhoff Automation GmbH & Co. KG