f808c43ad9 introduced a FreeBSD specific
behaviour to wait for firmware load completion before returning from
loading the driver. This does no longer allow iwl_drv_stop to detect
that startup has completed and it will wait indefinitely for a
completion event that will not happen.
We could change the complete() call to a complete_all() but to avoid
confusion, future side effects, and for simplicity daisy-chain two
complete events in FreeBSD.
PR: 267869
Reported by: Peter Much (pmc citylink.dinoex.sub.org)
Tested by: Peter Much (pmc citylink.dinoex.sub.org)
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Saves on work in a common case of checking both directions.
Note further work in the area is impending to elide these in the common
case to begin with.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D36485
As PF now also supports dummynet but can not configure it on its own,
the service which configures pipes, queues and schedulers is needed.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D37451
Running "dnctl" vs "/sbin/dnctl" gave different results, because we
looked at the entire argv[0] string, rather than the basename.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D37431
Along with _PSV, _HOT, and _CRT, ACPI supports the _CR3 threshold
which specifies a temperature above which a system should transition
to the S3 standby state.
On FreeBSD, this is more useful than _HOT, which specifies the S4
transition threshold temperature (since FreeBSD does not generally
support the S4 state), or, in many cases, _CRT, since after
transitioning to S3 the system can cool and then be resumed.
Reviewed by: jhb, bcr (manpages)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D35980
A small reduction in build infrastructure complexity; when we had both
Clang and GCC in the tree it was useful to have both built, and choose
one or the other to install as /usr/bin/cc. Now only Clang is in the
tree, and there is no point in building and installing base Clang but
not providing it as cc (and c++, cpp).
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37075
Now that all ACPI tables are build by basl, basl can dynamically
calculate the offset for each table.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37002
Building the RSDP table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37001
Building the RSDT table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37000
Building the XSDT table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36999
Building the FADT table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36998
Building the MADT table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36997
Building the HPET table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36996
Building the MCFG table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36995
The common style for build an ACPI table will be:
1. basl_table_create
2. basl_table_append_header
3. setup an ACPI_TABLE_* struct
4. basl_table_append_bytes (without header)
Add a helper for the last step.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37406
The code will be more readable if we use struct definitions from ACPI-CA
to build ACPI tables. We can fill out the struct and append it to the
basl_table by using basl_table_append_bytes. After that, we have to
declare which checksums, length and pointers should be patched by basl.
That's done by the add_* functions.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37405
Building the FACS table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36994
When a vcpu sees that a rendezvous is in progress, it exits and tries to
handle the rendezvous. The vcpu doesn't check if it's part of the
rendezvous or not. If the vcpu isn't part of the rendezvous, the
rendezvous could be done before it reaches the assertion. This will
cause a panic.
The assertion isn't needed at all because vm_handle_rendezvous properly
handles a spurious rendezvous. So, we can just remove it.
PR: 267779
Reviewed by: jhb, markj
Tested by: bz
Approved by: manu (mentor)
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37417
32-bit powerpc doesn't have a fuword64, so only use it on powerpc64.
This could also be done elsewhere that splits 32-bit and 64-bit
accesses, but adding ifdefs everywhere would just clutter up the source
for little benefit. This is the only usage of fuword64 directly; other
archs have a dtrace_fuword64_nocheck(), but powerpc does not, and I
don't see a need to add it currently.
MFC after: 1 week
Commit 5e6a2d6eb2 moved libc++ from /usr/lib to /lib, so we no longer
have an interval during boot when it is not available (before /usr is
mounted). We no longer need to force devd to be statically linked.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37409
Current sequence of IEEE OUI Identifier output is wrong.
For Intel, current output is e4 d2 5c, specification is 5CD2E4h
For Samsung, current output is 38 25 00, specification is 002538h
also check with Linux nvme-cli.
Reviewed by: imp, chuck
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D33856
libc++ requires C++20, so mark C++ (MK_CXX) as broken if the compiler
does not support C++20.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D36893
src.opts.mk will need bsd.compiler.mk to determine if CXX is
supported. Without this, src.opts.mk always marks CXX as broken and
attempts to delete all dependencies of MK_CXX from WORLDTMP.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36890
of various keyboard drivers.
EVIOCGRAB ioctl execution on /dev/input/event# device node gains
exclusive access to this device to caller. It is used mostly for
development purposes and remote control software. See e.g.
https://reviews.freebsd.org/D30020 which is the reason of creation
of this change.
Keyboard grabbing is disabled in KDB and during panics.
MFC with: 4a0db5e292
Tested by: corvink
Differential revision: https://reviews.freebsd.org/D30542
The pkgbase metalog tool is named metalog_reader.lua. (One may argue
that a better name could be chosen, but the README should match in any
case.)
Sponsored by: The FreeBSD Foundation
Disable -Wcast-align for now since we have many instances of that
warning (I fixed some but not most of them) and platforms on which bhyve
runs don't particularly care about unaligned accesses.
Reviewed by: corvink
Differential Revision: https://reviews.freebsd.org/D37296
I believe the __packed annotation is there only because
pci_xhci_portregs_read() is treating the register set as an array of
uint32_t. clang warns about taking the address of portregs->portsc
because it is a packed member and thus might not have expected
alignment.
Fix the problem by simply selecting the field to read with a switch
statement. This mimics pci_xhci_portregs_write(). While here, switch
to using some symbolic constants.
There is a small semantic change here in that pci_xhci_portregs_read()
would silently truncate unaligned offsets. For consistency with
pci_xhci_portregs_write(), which does not do that, return all ones for
unaligned reads instead.
MFC after: 2 weeks
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37408
- Make basl_dump() as unused.
- Avoid arithmetic on a void pointer.
- Avoid a signed/unsigned comparison with
BASL_TABLE_CHECKSUM_LEN_FULL_TABLE.
- Ignore warnings about unused parameters from stuff pulled in by
acpi.h. In particular, any prototype wrapped by
ACPI_DBG_DEPENDENT_RETURN_VOID() will raise such parameters unless
ACPI_DEBUG_OUTPUT is defined.
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37397
The compiler was warning that the "size" parameter to
smbios_generic_initializer() was unused. This parameter is apparently
used to populate the "maximum structure size" field in the SMBIOS entry
point, but we were always setting it to zero.
Implement it instead in the main loop of the smbios table builder.
MFC after: 2 weeks
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37294
The warnings that arise are bogus and have to be muted with
__no_lock_analysis in most cases. As a step towards enabling the
default warning level for bhyve, just disable them.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D37295
The default is now the number of physical CPUs in the system rather
than 16.
Reviewed by: corvink, markj
Differential Revision: https://reviews.freebsd.org/D37175
Bjoern A. Zeeb