In particular, print them before we release APs. Otherwise they tend to
get mixed with other kernel messages.
Reviewed by: andrew, manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31242
On Linux, this syscall doesn't take any arguments; instead
it assumes the context was put on the stack.
Reviewed By: dchagin
Sponsored By: EPSRC
Differential Revision: https://reviews.freebsd.org/D31251
Note that, as pointed out by scottl@, this code should really look
a bit different, in that the stack allocations should be replaced
with dynamic allocation, and the periph creation should be moved
to a context where one can use M_WAITOK. See the review for more
details. For now let's go with a minimal fix until we're done with
UMA CCBs.
Reviewed By: mav, imp
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D30298
Previously we would display "OK, Swapped" for swapped disks,
instead of the usual disk size.
Reviewed By: allanjude
Differential Revision: https://reviews.freebsd.org/D31219
These two ioctls are not part of the current version of OSS and were
considered obsolete. However, their behaviour is not the same as their
old one, so this implementation is specific to FreeBSD.
Older OSS versions had the MUTE ioctls take and return an integer with
a value of 0 or 1, which meant that the _whole_ mixer is unmuted or
muted respectively. In my implementation, the ioctl takes and returns
a bitmask that tells us which devices are muted.
This allows us to mute and unmute only the devices we want, instead of the
whole mixer. The bitmask works the same way as in DEVMASK, RECMASK and
RECSRC.
Integrated the hardware volume feature with the new mute system.
Submitted by: Christos Margiolis <christos@freebsd.org>
Differential Revision: https://reviews.freebsd.org/D31130
MFC after: 1 week
Sponsored by: NVIDIA Networking
We already attempt to enable the SiFive SPI controller, but since spibus
isn't enabled it isn't actually built.
Reviewed by: kp, philip
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31027
Currently we use the num-viewports property to decide how many outbound
regions there are we can use, defaulting to 2. However, Linux has
stopped using that and so it no longer appears in new device trees, such
as for the SiFive FU740. Instead, it's possible to just probe the
hardware directly.
Reviewed by: mmel
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31030
This supersedes the old legacy mode where a viewport register was used
to mux multiple regions behind a single set of registers, and is used on
the SiFive FU740.
Reviewed by: mmel
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31029
Currently we assume there is only one memory and one prefetch memory
window, and ignore the latter. However, the SiFive FU740 has two normal
memory windows.
As part of this, the viewports are rearranged. Previously the viewports
were memory, config then optionally I/O. Both to simplify the config
index calculation and to ensure it can always be mapped even if we have
too many memory windows for the number of viewports, config is moved to
being the first viewport.
This generalisation now also naturally supports mapping prefetch memory
windows.
Reviewed by: mmel
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31028
Unlike the old fmake, running make FOO=bar when using bmake doesn't put
FOO=bar in .MAKEFLAGS at the top level, it instead just puts FOO in
.MAKEOVERRIDES and the full MAKEFLAGS will be formed for sub-makes.
Moreover, this only applies for sub-makes in rules, so this doesn't
apply to those in shell assignments. This means that the current check
does not catch make MAKEOBJDIRPREFIX=..., only those defined in config
files. Thus we must also check .MAKEOVERRIDES explicitly.
Reviewed by: sjg
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31015
The pindex values are assigned from the L3 leaves upwards, meaning there
are NUL2E L3 tables and then NUL1E L2 tables (with a futher NUL0E L1
tables in future when we implement Sv48 support). Therefore anything
below NUL2E is an L3 table's page and anything above or equal to NUL2E
is an L2 table's page (with the threshold of NUL2E + NUL1E marking the
start of the L1 tables' pages in Sv48). Thus all the comparisons and
arithmetic operations must use NUL2E to handle the L3/L2 allocation (and
thus L2/L1 entry) transition point, not NUL1E as all but pmap_alloc_l2
were doing.
To make matters confusing, the NUL1E and NUL2E definitions in the RISC-V
pmap are based on a 4-level page hierarchy but we currently use the
3-level Sv39 format (as that's the only required one, and hardware
support for the 4-level Sv48 is not widespread). This means that, in
effect, the above bug cancels out with the bloated NULxE definitions
such that things "work" (but are still technically wrong, and thus would
break when adding Sv48 support), with one exception. pmap_enter_l2 is
currently the only function to use the correct constant, but since
_pmap_alloc_l3 uses the incorrect constant, it will do complete nonsense
when it needs to allocate a new L2 table (which is rather rare). In this
instance, _pmap_alloc_l3, whilst it would correctly determine the pindex
was for an L2 table, would only subtract NUL1E when computing l1index
and thus go way out of bounds (by 511*512*512 bytes, or 127.75 GiB) of
its own L1 table and, thanks to pmap_distribute_l1, of every other
pmap's L1 table in the whole system. This has likely never been hit as
it would presumably instantly fault and panic.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31087
These use the raw console interface and poll. Unfortunately, the SiFive
UART puts the FIFO empty bit inside the FIFO data register, which means
that the act of checking whether a character is available also dequeues
any character from the FIFO, requiring the user to press each key twice.
However, since we configure the watermark to be 0 and, when the UART has
been grabbed for the console, we have interrupts off, we can abuse the
interrupt pending register to act as a substitute for the FIFO empty
bit.
This perhaps suggests that the console interface should move from having
rxready and getc to having getc_nonblock and getc (or make getc take a
bool), as all the places that call rxready do so to avoid blocking on
getc when there is no character available.
Reviewed by: kp, philip
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31025
Note that currently Linux's device tree uses the FU540's compatible
string, as does upstream U-Boot, but the U-Boot shipped with the board
based on an older patch series has the correct FU740 name. Thankfully
they are the same, at least as far as software is concerned.
Whilst here, fix a style(9) nit.
Reviewed by: philip, kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31034
This is required for the SiFive FU740's PCIe controller. Copied from
arm64 with the only difference being changing pmap_mapdev_attr to
pmap_mapdev as riscv only has the latter.
Reviewed by: mhorne
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31032
This partially reverts commit af433832f7.
Since such bogus disklabels still exist in the wild, we now probe for a
disklabel to decide whether to ignore the UFS partition or not; if there
is a label then we use the old behaviour, and if there isn't one then we
use the new behaviour.
Reviewed by: cy, mckusick
Differential Revision: https://reviews.freebsd.org/D31068
See 3f6867ef63 for additional context.
It is also needed for OpenZFS performance and stability.
Reviewed by: ian (arm), imp
Differential Revision: https://reviews.freebsd.org/D31244
On Armada8k boards various peripherals (e.g. USB) have interrupt lines
connected to on of the ICU interrupt controllers.
After an interrupt is detected it triggers MSI to a given address,
with a programmed value. This in turn triggers an SPI interrupt.
Normally MSI vector should be allocated by ICUs parent and set
during interrupt allocation.
Instead of doing that we relied on the ICU being pre-configured in firmware.
This worked with EDK2 and older versions of U-Boot, but in the newer
ones that is no longer the case.
Extend ICU msi-parents - GICP and SEI to support MSI interface
and use it during interrupt allocation.
This allows us to boot on Armada 7k/8k SoCs independent from the
firmware configuration and successfully use modern U-Boot + device tree.
For SATA interrupts we need to apply a WA previously done in firmware.
We have two SATA ports connected to one controller.
Each ports gets its own interrupt, but only one of them is
described in dts, also ahci_generic driver expects only one irq too.
Fix it by mapping both interrupts to the same MSI when one of them
is allocated, which allows us to use both SATA ports.
Reviewed by: mmel, mw
Obtained from: Semihalf
Sponsored by: Marvell
Differential Revision: https://reviews.freebsd.org/D28803
Before this patch there was a chance for thread that called rand(3)
slightly later to see rand3_state already allocated, but not yet
initialized. While this API is not expected to be thread-safe, it
is not expected to crash. ztest on 64-thread system reproduced it
reliably for me.
MFC after: 1 month
This shaves calculation which in particular helps on arm.
Note using the & hack instead would still be more work.
Reviewed by: kp
Sponsored by: Rubicon Communications, LLC ("Netgate")
We failed to list the new pf_syncookies.c file in sys/conf/files. This
worked for the usual configurations, where pf is a module, but not for
LINT builds.
Reported by: lwhsu
MFC after: 1 week
Sponsored by: Modirum MDPay
Recent versions of homebrew's LLD are built with PACKAGE_VENDOR (since
e7c972b606).
This means that the -v output is now
`Homebrew LLD 12.0.1 (compatible with GNU linkers)` and bsd.linker.mk no
longer detects it as LLD since it only checks whether the first word is
LLD. This change allow me to build on macOS again and should unbreak the
GitHub actions CI.
Reviewed By: imp, uqs
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D31224
In the futex_atomic_op() the encoded_op is a user-supplied parameter.
If the user specifies an incorrect value for this parameter paired with a valid
*uaddr parameter the caller will go into the endless loop. To prevent this check
futex_atomic_op() result and break the loop in case of ENOSYS.
MFC after: 2 weeks
For the caller is no need for access checking here, as the caller must take care
of EFAULT handling. Moreover, this check would be superfluous, since EFAULT is
extremily rare, and we prefer the fast path.
MFC after: 2 weeks
Initial patch from submitter was adapted by me to prevent unconditional
FUTEX_REQUEUE use.
PR: 255947
Submitted by: Philippe Michaud-Boudreault
Differential Revision: https://reviews.freebsd.org/D30332
Move flags and rtclock to the struct linux_futex_args. This will be used when
I split linux_futex() into separate futex op functions.
MFC after: 2 weeks
This will be useful in an update for finding which HWCAPS to set.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31200
On arm64 we should use bit 55 of the address to decide if aan address
is a user or kernel address. Add a new macro with this check and a
second to ensure the address is in teh canonical form, i.e.
the top bits are all zero or all one.
This will help with supporting future cpu features, including Top
Byte Ignore, Pointer Authentication, and Memory Tagging.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31179
This builds on recently introduced NO_NEW_PRIVS flag to implement
unprivileged chroot, enabled by `security.bsd.unprivileged_chroot`.
It allows non-root processes to chroot(2), provided they have the
NO_NEW_PRIVS flag set.
The chroot(8) utility gets a new flag, -n, which sets NO_NEW_PRIVS
before chrooting.
Reviewed By: kib
Sponsored By: EPSRC
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D30130
Test that with syncookies enabled pf does not create state for
connections before the remote peer has replied to the SYN|ACK message.
MFC after: 1 week
Sponsored by: Modirum MDPay
Differential Revision: https://reviews.freebsd.org/D31142
Test syncookies on a forwarding host. That is, in a setup where the
machine (or vnet) running pf is not the same as the machine (or vnet)
running the server it's protecting.
MFC after: 1 week
Sponsored by: Modirum MDPay
Differential Revision: https://reviews.freebsd.org/D31141
Kernel side implementation to allow switching between on and off modes,
and allow this configuration to be retrieved.
MFC after: 1 week
Sponsored by: Modirum MDPay
Differential Revision: https://reviews.freebsd.org/D31139
Import OpenBSD's syncookie support for pf. This feature help pf resist
TCP SYN floods by only creating states once the remote host completes
the TCP handshake rather than when the initial SYN packet is received.
This is accomplished by using the initial sequence numbers to encode a
cookie (hence the name) in the SYN+ACK response and verifying this on
receipt of the client ACK.
Reviewed by: kbowling
Obtained from: OpenBSD
MFC after: 1 week
Sponsored by: Modirum MDPay
Differential Revision: https://reviews.freebsd.org/D31138
The intention here is to reduce differences between em, igb, igc, ixgbe.
The main functional change is logical simplification in igb_rx_checksum
and getting interface caps from scctx instead of the ifp.
Reviewed by: gallatin, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D30073
