tests: fix test for NULL encription
After 04207850a9b9 it is required that key length is not zero.
Add some key to avoid error.
Reported by: markj
(cherry picked from commit b6708045590712930c533e916e3d6fdfe48ec5ba)
tests: fix test for NULL encription
After 04207850a9b9 it is required that key length is not zero.
Add some key to avoid error.
Reported by: markj
(cherry picked from commit b6708045590712930c533e916e3d6fdfe48ec5ba)
arm64: add a driver for the uart found on Apple Silicon machines
This is a revival of the old exynos4210 driver, with some additional
bits to configure the apple "s5l" uart (which is actually slightly
different to operate).
This hasn't been tested on anything that would hit the non-s5l path, so
banish it off to the apple/ domain until someone cares to confirm that
none of the other hardware is broken -- it may be that nobody does, but
the complexity isn't too bad: mostly the driver1 construct added to the
uart_bas that we use to avoid having a whole bunch of shims for uart
driver methods and hardcoded references to the cfg structs.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D48120
iommu_gas_map_region(): add comment explaining the ma array shift
and the difference between start and entry->start values at this point.
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
acpi_pci: Add quirk for PSTAT_PME-before-detach
In order to signal to Graviton [123] systems that a device is ready
to be "ejected" (after a detach request is made via the EC2 API) we
need to set PCIM_PSTAT_PME to 1 and PCIM_PSTAT_PMEENABLE to 0. We are
not aware of any rationale for this requirement beyond "another OS
kernel happens to do this", i.e. this is effectively bug-for-bug
compatibility.
Arguably this should be done by the ACPI _EJ0 method on these systems,
but it is not.
Create a new ACPI_Q_CLEAR_PME_ON_DETACH quirk and set it in EC2 AMIs,
and add the PCI register write to acpi_pci_device_notify_handler when
that quirk is set.
Reviewed by: jhb
MFC after: 1 month
Sponsored by: Amazon
[3 lines not shown]
pci: Only claim to support PCI ASPM on x86
We claim to support Active State Power Management, but don't appear to
do anything different in the kernel when it's enabled other than tell
the firmware we do.
This breaks VMware Fusion on Apple Silicon when it's enabled as it
expects the kernel to enable the ports. As it is reported to be needed
on some x86 servers keep it enabled there, but disable on non-x86
architectures.
Reported by: kp, tuexen
Reviewed by: tuexen, mav, imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48303
(cherry picked from commit 143dff0f9ce9a6f03ae5701368c7144b30e2dc39)
pci_host_generic: Support ACPI_IVAR_HANDLE
In the ACPI attachment support the ACPI_IVAR_HANDLE ivar. While here
use the common ivar function to support the common ivars.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48047
(cherry picked from commit deb36d0c65436d16b04f99cc2a27bd0f3980a6f0)
pci: Use a switch statement when reading ivars
In pci_host_generic.c use a switch statement rather than a series
of if statements.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48045
(cherry picked from commit fafb43abd0dcaf2d36ec7344f46e7e19c42be888)
acpica: Extract _OSC parsing to a common file
This will be used by pci_host_generic_acpi.c so needs to be in a
common location.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48044
(cherry picked from commit ba1904937d9ae0539e39001467a1519b17177118)
pci_host_generic:Add pcib_request_feature on ACPI
In the ACPI attachment add support for the pcib_request_feature method.
This uses the common _OSC handling.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48048
(cherry picked from commit 1f5c50a8617355758510675cb9412f56fed12efc)
LinuxKPi: lkpi___kmalloc change a < into <= for proper boundry check
lkpi___kmalloc() would use contigmalloc if the requested size is exactly
PAGE_SIZE. But we can still fullfill this request from malloc() without
losing the guarantee of physical contiguous memory.
Sponsored by: The FreeBSD Foundation
Reported by: emaste (in D46656)
Fixes: 19df0c5abcb9d
MFC after: 3 days
Reviewed by: dumbbell, emaste
Differential Revision: https://reviews.freebsd.org/D49570
LinuxKPI: be more verbose on _bus_dmamap_load_phys failures if debug is on
With the [k]malloc adjustments in switching skbuff from using a tunable
and conditional contigmalloc with boundries to using __kmalloc as allocator
should just work. The allocations are now physically contiguous and
nseg=1 should be fine even if we have to bounce.
The problem now coming back is that busdma bounce code cannot deal with
larger contiguous nseg=1 allocations. I originally found that on arm64
more than two years ago but I am also seeing it for amd64 now.
Improve the debugging beyond the dump_stack() call and print the busdma
error (so we know if it is EFBIG or else), print the physical address
so we can see better if we should bounce and print the length so we
have an idea on what lengths we are failing. D45813 has some
observations and rtw88 seems to be a good driver to test with.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
[2 lines not shown]
if_ovpn: fix use-after-free of mbuf
m_unshare() can return a new mbuf pointer. We update the 'm' pointer in
ovpn_udp_input(), but if we decide to pass on the packet (e.g. because it's for
an unknown peer) the caller (udp_append()) continues with the old 'm' pointer,
eventually resulting in a use-after-free.
Re-order operations in ovpn_udp_input() so that we don't modify the 'm' pointer
until we're committed to keeping the packet.
PR: 283426
Test case by: takahiro.kurosawa at gmail.com
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
pkg.7: Add example for fetching package for different FreeBSD versions
MFC after: 1 week
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D49580
usr.bin/Makefile: always build ELF Tool Chain strings(1)strings(1) is not conditional on WITH_/WITHOUT_TOOLCHAIN, as it is a
small utility that is also useful outside of the toolchain context.
As of commit 1cae7121c667 we switched to WITH_LLVM_BINUTILS by default.
After this change building world with default options but installing
WITHOUT_TOOLCHAIN failed, because we would build LLVM's strings but
attempt to install ELF Tool Chain's version, which did not exist.
Address this by always including ELF Tool Chain strings in non-install
make targets, so that it will be available if options are changed at
install time.
PR: 285556
Reported by: Michael Butler
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49425
(cherry picked from commit fdc4db57224ce19b867c60fce4c410068be40c27)
devd: raise the maximum allowed client to 50
since the creation of libudev-devd, but also with powerd, recent libusb
changes etc. 10 client is not enough anymore to cover the desktop needs
and end users often ends up with:
sonewconn: pcb 0xfffff8004dd43780 (local:/var/run/devd.seqpacket.pipe)...
raise the maximum allowed client to 50, which should be enough to cover
user requirements.
MFC After: 1 week
(cherry picked from commit 5682eee1efd35fb65751641181ae2a50d86efaab)
Add a kgdb python script to extract bbl from kernel dumps
A kgdb script allows us to be relatively resilient to kernel structure
changes, with a lower burden for updates when they happen than a C tool.
tuexen@ requested we ship this script in a source distribution. Making
it easier for users to extract useful debugging information from a core.
It requires kgdb and python3 and would ideally be a lldb lua script, but
there is more work needed on lldb lua before we can do that.
Add the script as is. A single script we could run against a core would
be nice, but I don't want to let that block making this tool more
available.
Reviewed by: teuxen, rrs
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48705
zoneinfo: also install tzdata.zi and version
Build and install the shrunk version of the time zone database required
by libc++ 19 std::chrono::current_zone (etc). While here, also install
the tzdata 'version' file to align more closely with other vendors.
PR: 282377
Reviewed by: dim, emaste, imp
Differential Revision: https://reviews.freebsd.org/D49577
