It indicates to a debugger that the thread is stopped at the
kernel->user exit path.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D37590
and TDB_COREDUMPRQ to TDB_COREDUMPREQ
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D37590
Change the range test in iommu_gas_match_one from '< ubound' to '<=
ubound', and pass a smaller-by-one ubound parameter to it, to avoid
overflow in ubound calculation.
Reported by: andrew
Reviewed by: andrew (previous version)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D37764
Introduce new prompt format characters:
- '\[' starts the sequence of non-printing chatacters
- '\]' ends the sequence of non-printing characters
Within these sequences, the following characters are now supported:
- '\a' emits ASCII BEL (0x07, 007) character
- '\e' emits ASCII ESC (0x1b, 033) character
- '\r' emits ASCII CR (0x0d, 015) character
- '\n' emits ASCII CRLF sequence
These can be used to embed ANSI sequences into prompt strings.
Example in .shrc:
PS1="\[\e[7m\]\u@\h\[\e[0m\]:\w \\$ "
This tries to maintain some degree of compatibility with GNU bash,
that uses GNU readline library (which behaves slightly different from
BSD editline): It has two "non-printing boundary" characters:
- RL_PROMPT_START_IGNORE (\001)
- RL_PROMPT_END_IGNORE (\002)
while BSD editline only has one (when using EL_PROMPT_ESC setting), so
for this purpose, ASCII \001 was chosen and both \[ and \] emits
this character.
And while here, enlarge PROMPTLEN from 128 to 192 characters.
Reviewed by: jilles
Approved by: jilles
Differential Revision: https://reviews.freebsd.org/D37701
Since a NFSERR_NOFILEHANDLE reply from an NFSv4 server
usually means that the file system is not exported on
the server, change the console log message to indicate
that.
MFC after: 1 week
Although the tls syscall to set up the upcall should
not normally fail, the daemon should check for such
a failure. This patch adds a check for that failure.
MFC after: 1 week
To support running on some emulators we allow CPU start to fail if the
CPU we are starting is not present. The PMU driver will then check if
the CPU is present and fail to attach if any are missing.
To allow the PMU to be used in such an environment don't fail to attach
when a CPU is missing.
Sponsored by: Arm Ltd
Historically the ACPI _HID for both the Arm PL011 and Generic UARTs
was ARMH0011. In the Arm Base Boot Requirements 2.0 the Generic UART
_HID is changed to ARMHB000. Use this new value in the PL011 driver
where we support both UART types.
This has been observed in some recent EDK2 builds.
Sponsored by: Arm Ltd
The SPDX-License-Identifier was wrong in the Arm CoreLink DMC-620
driver files. It used the incorrect FreeBSD variant of the BSD-2-Clause
identifier. According to [1] all files should use BSD-2-Clause.
[1] https://tools.spdx.org/app/check_license/
Reported by: emaste
Sponsored by: Arm Ltd
The SPDX-License-Identifier was wrong in the Arm CoreLink CMN-600
driver files. It used the incorrect FreeBSD variant of the BSD-2-Clause
identifier. According to [1] all files should use BSD-2-Clause.
[1] https://tools.spdx.org/app/check_license/
Reported by: emaste
Sponsored by: Arm Ltd
In 0a9a4d2cd6 a check for OPT_ACPI was added to the hwpmc Makefile
to fix loading the module in a kernel where ACPI has been disabled.
This broke loading the module when ACPI was enabled in the build as
OPT_ACPI isn't a Makefile macro so was always disabled.
Move this check to the C files where the DEV_ACPI macro does exist.
Reviewed by: gnn
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D37773
The td_ast member is an int so only 4 bytes, yet we were using an 8 byte
load and thus also got td_inhibitors in the upper bits. The code prior
to the commit that introduced td_ast did also do a bogus 8 byte load of
td_flags but masked the flags so arguably was correct, if dodgy. Now
that we're using the right width for the load we can also fold the
immediate offset back into the load; because td_ast is at an odd
multiple of 4 bytes from the start of struct thread the normal scaled
load couldn't be used with such an immediate offset when doing an 8 byte
load due to its limited immediate range, but we can use a scaled load
once more now that the offset is a multiple of the load width.
Reviewed by: andrew, kib
Fixes: c6d31b8306 ("AST: rework")
Differential Revision: https://reviews.freebsd.org/D37751
The pin-mode (ft, pd, pu for floating, pull-down, pull-up) is
specified after the intr-config (no, eb, ef, er) for each pin.
Tested on my Raspberry Pi 1B.
PR: 268504
Approved by: manu
MFC after: 1 week
This is to upgrade current irdma driver version (in support of RDMA on
Intel(R) Ethernet Controller E810) to 1.1.5-k
change summary:
- refactor defines for hardware registers
- rereg_mr verb added in libirdma
- fix print warning during compilation
- rt_ros2priority macro fix
- irdma.4 validated with mandoc
- fixing nd6_resolve usage
- added libirdma_query_device
- sysctl for irdma version
- aeq_alloc_db fix
- dwork_flush protected with qp refcount
- PFC fixes
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: erj@
Sponsored by: Intel Corporation
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36944
Although the tls syscall to set up the upcall should
not normally fail, the daemon should check for such
a failure. This patch adds a check for that failure.
MFC after: 1 week
Silence -Winfinite-recursion for ldo.c in lua and -Wstringop-overread
for nvpair.c.
Reviewed by: mm
Differential Revision: https://reviews.freebsd.org/D37631
The mlx5 driver and some other OFED bits use a somewhat dubious
pattern of:
struct foo {
uint64_t arg[0];
/* Real members of a struct */
};
The code then treats 'arg' as if it were really a kind of union
such that foo.arg[N] functions similarly to (uint64_t *)foo[N].
This uses of foo.arg[N] then trigger this warning.
No real bugs were found by this warning though, so just turn it off
globally.
Reviewed by: hselasky, kib
Differential Revision: https://reviews.freebsd.org/D37630
Some of the warnings raised in the kernel seem to be outright bugs in
the compiler (e.g. the cases in ata_xpt.c and scsi_xpt.c). Other
cases are not fatal and it didn't seem to find any legitimate bugs in
the kernel.
Differential Revision: https://reviews.freebsd.org/D37629
The USB code and some other places raise false positives when a NULL
pointer is passed to an inlined function along with a separate length
and the compiler can't determine that the separate length of 0
prevents the use of the NULL pointer.
Differential Revision: https://reviews.freebsd.org/D37627
In this call to IEEE80211_NOTE, ni is always NULL due to the assignment
a few lines earlier at the start of the function. If debug traces are
enabled, then this will pass an invalid pointer as the 'mac' pointer to
ieee80211_note_mac. Use IEEE80211_DPRINTF which doesn't take a 'ni'
argument instead.
Reported by: GCC -Wstringop-overread
Reviewed by: bz, emaste
Differential Revision: https://reviews.freebsd.org/D37626
mrsas_issue_blocked_cmd stores a pointer to an on-stack variable
in its softc so that the driver can call wakeup() on the correct
pointer. Once the loop around tsleep() has finished however, the
pointer is no longer needed and any further use would be invalid.
Clear sc->chan to NULL after the loop.
Reported by: GCC -Wdangling-pointer
Differential Revision: https://reviews.freebsd.org/D37628
Set the thread affinity in fbsdrun_start_thread next to where the
thread name is set. This keeps all the pthread initialization
operations at the start of a thread in one place.
Reviewed by: corvink, markj
Differential Revision: https://reviews.freebsd.org/D37646
The global vmexit[] array is no longer needed to smuggle the rip
value from fbsdrun_addcpu() to vm_loop().
Reviewed by: corvink, markj
Differential Revision: https://reviews.freebsd.org/D37644
fbsdrun_addcpu() read the current vCPU's RIP register from the kernel
via vm_get_register() to pass along through some layers to vm_loop()
which then set the register via vm_set_register(). However, this is
just always setting the value back to itself.
Reviewed by: corvink
Differential Revision: https://reviews.freebsd.org/D37643
- Enable VM_CAP_IPI_EXIT in fbsdrun_set_capabilities along with other
capabilities enabled on all vCPUs.
- Don't call fbsdrun_set_capabilities a second time on the BSP in
spinup_vcpu.
- To preserve previous behavior, don't unconditionally enable
unrestricted guest mode on the BSP (this unbreaks single-vCPU guests
on Nehalem systems, though supporting such setups is of dubious
value). Other places that enbale UG on the BSP are careful to check
the result of the operation and fail if it is not available.
- Don't set any capabilities in spinup_ap(). These are now all
redundant with earlier settings from spinup_vcpu().
- While here, axe a stale comment from fbsdrun_addcpu(). This
function is now always called from the main thread for all vCPUs.
Reviewed by: corvink, markj
Differential Revision: https://reviews.freebsd.org/D37642
Since commit 0bda8d3e9f, bhyve always enables VM_EXITCODE_IPI exits
instead, so this handler is no longer used.
Reviewed by: corvink, markj
Differential Revision: https://reviews.freebsd.org/D37640
The order of asserting/deasserting the resets doesn't matter so use
the new hwreset_array to manage them all.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37358
In some drivers we need to assert and deassert a group of hardware
resets in any order. To support this add a new hwreset_array that
manages all hwresets defined for a device.
Reviewed by: bz, manu, mmel
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37357
