Use it wherever COMPAT_FREEBSD11 is currently specified, like r309749.
Reviewed by: imp, jhb, markj
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D20120
The DTS for this board is already present in sys/gnu/dts/arm64/rockchip/
and just needs to be enabled.
Submitted by: alex@wied.io
Differential Revision: https://reviews.freebsd.org/D19823
r345519 rewrote parts of how we build .dtb, but mistakenly dropped the
vendor dir for aarch64. Simply drop the :T for building ${DTB} in the
aarch64 case- it'll get applied at install-time as-needed, with :H:T for
determining the vendor dir.
Reported by: manu
Tested by: manu
Reviewed by: manu
MFC after: 3 days
That makes Linux lscpu(1) work.
Reviewed by: dchagin
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D20131
It's possible for a Hypervisor Maintenance Interrupt (HMI) to occur while in
the pmap code, holding locks. This can cause WITNESS to panic due to lock
errors in calling pmap_kextract(). Since we don't yet handle the flags
returned by OPAL_HANDLE_HMI2, just stop using it, so that we don't call into
pmap_kextract().
Reported by: pkubaj
Some UEFI implementations trash this register and, as we use it as a
platform register, the kernel doesn't save it before calling into the UEFI
runtime services. As we have a copy in tpidr_el1 restore from there when
exiting the EFI environment.
PR: 237234, 237055
Reviewed by: manu
Tested On: Ampere eMAG
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Sponsored by: Ampere Computing (hardware)
Differential Revision: https://reviews.freebsd.org/D20127
vm_map_wire() increments entry->wire_count, after that it drops the
map lock both for faulting in the entry' pages, and for marking next
entry in the requested region as IN_TRANSITION. Only after all entries
are faulted in, MAP_ENTRY_USER_WIRE flag is set.
This makes it possible for vm_map_protect() to run while other entry'
MAP_ENTRY_IN_TRANSITION flag is handled, and vm_map_busy() lock does
not prevent it. In particular, if the call to vm_map_protect() adds
VM_PROT_WRITE to CoW entry, it would fail to call
vm_fault_copy_entry(). There are at least two consequences of the
race: the top object in the shadow chain is not populated with
writeable pages, and second, the entry eventually get contradictory
flags MAP_ENTRY_NEEDS_COPY | MAP_ENTRY_USER_WIRED with VM_PROT_WRITE
set.
Handle it by waiting for all MAP_ENTRY_IN_TRANSITION flags to go away
in vm_map_protect(), which does not drop map lock afterwards. Note
that vm_map_busy_wait() is left as is.
Reported and tested by: pho (previous version)
Reviewed by: Doug Moore <dougm@rice.edu>, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D20091
Make function macro wrappers for locking and unlocking to ease readability.
No functional change.
Discussed with: kib@, tychon@ and zeising@
Sponsored by: Mellanox Technologies
Unconditional writing to MAS7, which doesn't exist on the e500v1 core, in a
TLB miss handler has been in the code for several years now. Since this has
gone unnoticed for so long, it's easily concluded that e500v1 is not in use
with FreeBSD. Simplify the code path a bit, by unconditionally zeroing MAS7
instead of calling a subroutine to do it.
r18 is used to hold the old PCB flags, but cpu_throw doesn't populate r18
with PCB flags, since the old thread is gone. This can lead to panics on
cores that don't have the registers guarded by these flags.
This version fixes the problems identified in r345244.
Reviewed by: kib
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19598
Turning on multicast debug made multicast failure worse
because the strings and #define values no longer matched
up. Fix them, and make sure they stay matched-up.
Submitted by: torek
MFC after: 1 week
Sponsored by: iXsystems, Inc.
This change makes it easier to enable/disable the inclusion of
OPAL flash in the kernel.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D20098
so it does not require a bounce buffer. The only need for this was
to align the buffer address. Implement unaligned access and we don't
need to copy data twice.
o Remove contigmalloc-based bounce buffer from xDMA code since it is
not suitable for arbitrary memory provided by platform, which is
sometimes a dedicated piece of memory that is not managed by OS at all.
Sponsored by: DARPA, AFRL
These predicates are vestigal and cannot be true today. For example,
idle threads are not allowed to acquire locks.
Also cache curthread in breada().
No functional change intended.
Reviewed by: kib, mckusick
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D20066
This way its children can attach earlier if needed, and some subsystems are
attached earlier, like the asynchronous token management.
MFC after: 2 weeks
It cannot load it automatically at boot, because the root filesystem
is not there yet. An alternative would be adding ispfw(4) to GENERIC,
but it's an additional 1MB.
Reviewed by: mav
MFC after: 2 weeks
Sponsored by: Klara Inc.
Differential Revision: https://reviews.freebsd.org/D19369
Add support to enable, save, and restore the following facilities:
* Target Address Register (bctar) -- seemingly just another register to
branch to.
* Event-based branching -- an interrupt-like userspace event handler
subsystem.
* Load-monitored facility -- A facility that allows monitoring a range of
physical memory, and triggering an event on access. Targeted to garbage
collection software features.
The Data Stream Control Register (DSCR) is privileged on POWER7, but
unprivileged (different register) on POWER8 and later. However, it's now
guarded by a new register, the Facility Status and Control Register, instead of
the MSR like other pre-existing facilities (FPU, Altivec). The FSCR must be
managed explicitly, since it's effectively an extension of the MSR.
Tested by: Brandon Bergren
We don't have the display engine driver commited in FreeBSD yet so it is
useless to expose the clocks yet (and also it have not been tested on H5).
Reported by: Manuel Stühn (freebsdnewbie@freenet.de)
PR: 237571
MFC after: 1 week
Allwinner H3 and H5 share many internal components, that's why they can
use the same drivers.
This patch adds the compatible strings to enable clock drivers
probing on Allwinner NanoPI NEO2 device.
Tested on: NanoPi NEO2 (by submitter), OrangePi PC2 (by manu)
Submitted by: Manuel Stühn (freebsdnewbie@freenet.de)
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D20069
The POWER8NVL (POWER8 NVLink) architecturally behaves identically to the
POWER8, with a different PVR identifier. Mark it as such, so it shows up
appropriately to the user.
Reported by: Alexey Kardashevskiy
MFC after: 2 weeks
Since the non-volatile registers are restored at the end of cpu_switchin (of
the new thread) they're free for us to use for our own purposes. Load the
PCB_FLAGS into a non-volatile register so it's preserved across the C
function calls that manage FPU and altivec state. This removes 4 loads from
each file. Might be a trivial performance improvement (~12 clock cycles per
context switch).
MFC after: 3 weeks
Some PPC systems (PowerNV) use msdosfs for /boot, which can't handle either
symlinks or hardlinks. So on PPC, copy the module instead. This change fixes
installkernel on such systems after r345350.
Reported by: Brandon Bergren <git_bdragon.rtk0.net>
Reviewed by: jhibbits, rgrimes
MFC after: 2 weeks
MFC-With: 345350, 346441
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19993
Replace most VM_MAXCPU constant useses with an accessor function to
vm->maxcpus which for now is initialized and kept at the value of
VM_MAXCPUS.
This is a rework of Fabian Freyer (fabian.freyer_physik.tu-berlin.de)
work from D10070 to adjust it for the cpu topology changes that
occured in r332298
Submitted by: Fabian Freyer (fabian.freyer_physik.tu-berlin.de)
Reviewed by: Patrick Mooney <patrick.mooney@joyent.com>
Approved by: bde (mentor), jhb (maintainer)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D18755
By default, cores are now assigned to queues in a sequential
manner rather than all NICs starting at the first core. On a four-core
system with two NICs each using two queue pairs, the nic:queue -> core
mapping has changed from this:
0:0 -> 0, 0:1 -> 1
1:0 -> 0, 1:1 -> 1
To this:
0:0 -> 0, 0:1 -> 1
1:0 -> 2, 1:1 -> 3
Additionally, a device can now be configured to use separate cores for TX
and RX queues.
Two new tunables have been added, dev.X.Y.iflib.separate_txrx and
dev.X.Y.iflib.core_offset. If core_offset is set, the NIC is not part
of the auto-assigned sequence.
Reviewed by: marius
MFC after: 2 weeks
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D20029
