Some bnxt devices do not correctly send frames smaller than
52 bytes (without CRC), so add a quirk that will pad frames to an
arbitrary size before passing off to the encap routine.
Reported by: Bhargava Chenna Marreddy <bhargava.marreddy@broadcom.com>
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D13269
The LRO possible test was calling CURVNET_SET once for IPv4 or IPv6 for
each packet in a chain. Only call it once per chain instead.
Submitted by: Matthew Macy <mmacy@mattmacy.io>
Reviewed by: cem, ae
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D13368
Using
.symver foo,foo@@VER
causes foo and foo@@VER to be output to the .o file. This requires foo
to be weak since the linker handles foo@@VER as foo.
Using
.symver foo,foo@@@VER
causes just foo@@ver to be output and avoid the need for making foo
weak. It also reduces the constraint on how exactly a linker has to
handle foo and foo@@VER being present.
Submitted by: Rafael Espíndola
Reviewed by: dim, kib
Differential Revision: https://reviews.freebsd.org/D11653
- Updates tables in affected files with new entries from newer spec
revisions of SFF-8472, SFF-8024, and SFF-8636
- Change ifconfig to read and display the extended compliance code for
SFP media if the extended compliance code is not 0. This was being displayed
for QSFP transceivers only, but SFP28 media uses this to report 25G
capability.
Reviewed by: melifaro, sbruno
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D13286
The OBJS_DEPEND_GUESS mechanism was making vmx_genassym.o depend
on all headers along with vmx_assym.h, though vmx_assym.h depends
on having vmx_genassym.o present to generate. Moving the headers
to DPSRCS is enough to resolve the issue as they will no longer
be implicit dependencies for all objects. Because of this we
need explicit OBJS_DEPEND_GUESS entries to ensure the headers
are generated when needed for the *_support.o files that need
them.
X-MFC-With: r326552
MFC after: 2 weeks
Sponsored by: Dell EMC
there are no write delegations issued.
manu@ reported on the freebsd-current@ mailing list that there was
a significant performance hit in nfsrv_checkgetattr() caused by
the acquisition/release of a state lock, even when there were no
write delegations issued.
This patch add a count of outstanding issued write delegations to the
NFSv4 server. This count allows nfsrv_checkgetattr() to return without
acquiring any lock when the count is 0, avoiding the performance hit
for the case where no write delegations are issued.
Reported by: manu
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13327
Recent DTS (from Linux 4.14) specify a compatible "allwinner,sun50i-h5-ccu"
for H5 SoC. Since we get the DTB from u-boot this wasn't noticed.
Add the compatible so later version of u-boot will not fail for us.
This is better than directly changing PCI configuration space of the
device because it makes the PCI bus aware of the configuration.
Also, the change allows to drop a bunch of code that duplicated
pci_enable_msi() functionality.
I wonder if it's possible to further simplify the code by using
pci_alloc_msi().
ivhd should attach after the root PCI bus and, thus, after the ACPI
Host-PCI bridge off which the bus hangs. This is because ivhd changes
PCI configuration of a PCI IOMMU device that is located on the root bus.
If the bus attaches after ivhd it clears the MSI portion of the
configuration. As a result IOMMU event interrupts would never be
delivered.
For regular ACPI devices the order is calculated as
ACPI_DEV_BASE_ORDER + level * 10
where level is a depth of the device in the ACPI namespace.
I expect the depth of the Host-PCI bridge to be two or three,
so ACPI_DEV_BASE_ORDER + 10 * 10 should be a sufficiently safe order
for ivhd.
This should fix the setup of the AMD-Vi event interrupt when vmm is
preloaded (as opposed to kldload-ed).
This ensures that we can receive further event interrupts.
See the description of the bits in the specification for
MMIO Offset 2020h IOMMU Status Register.
The bits are defined as set-by-hardware write-1-to-clear, same as all
the bits in the status register.
Discussed with: anish
arm64 boot sequence. This will be a virtual address in the kernel space
after the kernel and any modules loaded by loader so we can use this to
find the size of the kernel + modules. We can then add on a level 2 page for
the module data and round up the size to be aligned to a level 2 page.
This allows more than 8 MiB of modules to be loaded by loader, e.g. zfs.ko
and opensolaris.ko.
Reported by: Shawn Webb
MFC after: 1 week
Sponsored by: DARPA, AFRL
Commit r326346 moved domain iterators from physical layer to vm_page one,
but it also removed translation of freelist to flind for
vm_page_alloc_freelist() call. Before it expects VM_FREELIST_ parameter,
but after it expect freelist index.
On small WiFi boxes with few megabytes of RAM, there is only one freelist
VM_FREELIST_LOWMEM (1) and there is no VM_FREELIST_DEFAULT(0) (see file
sys/mips/include/vmparam.h). It results in freelist 1 with flind 0.
At first, this commit renames flind to freelist in vm_page_alloc_freelist
to avoid misunderstanding about input parameters. Then on physical layer it
restores translation for correct handling of freelist parameter.
Reported by: landonf
Reviewed by: jeff
Differential Revision: https://reviews.freebsd.org/D13351
The existing check of the GCC version number is not sufficient
This fixes the build on sparc64 in preparation for integrating ZSTD into
the kernel for ZFS and Crash Dumps.
The cloudabi32.ko kernel modules can only be loaded on AMD64 and ARM64
by kernels built with COMPAT_FREEBSD32. Even though COMPAT_FREEBSD32
does not support the execution of native FreeBSD executables, do add it
to GENERIC, to make cloudabi32.ko usable.
According to size(1), this makes the kernel image approximately 0.7%
larger.
Reviewed by: andrew, imp, emaste
Differential Revision: https://reviews.freebsd.org/D13311
Currently, bwn(4) relies on the siba_bwn(4) bus driver to provide support
for the on-chip SSB interconnect found in Broadcom's older PCI(e) Wi-Fi
adapters. Non-PCI Wi-Fi adapters, as well as the newer BCMA interconnect
found in post-2009 Broadcom Wi-Fi hardware, are not supported by
siba_bwn(4).
The bhnd(4) bus driver (also used by the FreeBSD/MIPS Broadcom port)
provides a unified kernel interface to a superset of the hardware supported
by siba_bwn; by attaching bwn(4) via bhnd(4), we can support both modern
PCI(e) Wi-Fi devices based on the BCMA backplane interconnect, as well as
Broadcom MIPS WiSoCs that include a D11 MAC core directly attached to their
SSB or BCMA backplane.
This diff introduces opt-in bwn(4) support for bhnd(4) by providing:
- A small bwn(4) driver subclass, if_bwn_bhnd, that attaches via
bhnd(4) instead of siba_bwn(4).
- A bhndb(4)-based PCI host bridge driver, if_bwn_pci, that optionally
probes at a higher priority than the siba_bwn(4) PCI driver.
- A set of compatibility shims that perform translation of bwn(4)'s
siba_bwn function calls into their bhnd(9) API equivalents when bwn(4)
is attached via a bhnd(4) bus parent. When bwn(4) is attached via
siba_bwn(4), all siba_bwn function calls are simply passed through to
their original implementations.
To test bwn(4) with bhnd(4), place the following lines in loader.conf(5):
hw.bwn_pci.preferred="1"
if_bwn_pci_load="YES
bwn_v4_ucode_load="YES"
bwn_v4_lp_ucode_load="YES"
To verify that bwn(4) is using bhnd(4), you can check dmesg:
bwn0: <Broadcom 802.11 MAC/PHY/Radio, rev 15> ... on bhnd0
... or devinfo(8):
pcib2
pci2
bwn_pci0
bhndb0
bhnd0
bwn0
...
bwn(4)/bhnd(4) has been tested for regressions with most chipsets currently
supported by bwn(4), including:
- BCM4312
- BCM4318
- BCM4321
With minimal changes to the DMA code (not included in this commit), I was
also able to test support for newer BCMA devices by bringing up basic
working Wi-Fi on two previously unsupported, BCMA-based N-PHY chipsets:
- BCM43224
- BCM43225
Approved by: adrian (mentor, implicit)
Sponsored by: The FreeBSD Foundation & Plausible Labs
Differential Revision: https://reviews.freebsd.org/D13041
The Display Interface Unit (DIU) uses main memory for the framebuffer, which
is already mapped as cache coherent physical memory. Prevent mmap() from
using its own attributes which may otherwise conflict.
- Add missing call to device_delete_children() in bhndb_detach(), without
which we're left with stale child devices on module unload.
- Pass the parent PCI device to pci_release_msi(), not the bhndb_pci(4)
child.
Approved by: adrian (mentor, implicit)
Sponsored by: The FreeBSD Foundation
bhnd_chipc's children may hold strong provider references to their parent;
we must detach any children before attempting to deregister the bhnd_chipc
device as a bus service provider.
Approved by: adrian (mentor, implicit)
Sponsored by: The FreeBSD Foundation
Default WARNS to 0 still, since there's still some warnings on other
architectures.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D13301
a10_gpio previously accepted only {allwinner,}drive and {allwinner,}pull for
drive/bias setting, while newer DTS is using drive-strength and
bias-{disable,pull-up,pull-down} properties. Accept these properties as
well.
Additionally make bias and drive strength optional rather than required; not
setting them should just indicate that we do not need to configure these
properties.
Tested on: BananaPi-M3 (a83t)
Reviewed by: manu
Approved by: emaste (implicit)
Obtained from: NetBSD (partially)
Differential Revision: https://reviews.freebsd.org/D13284
SIOCGIFXMEDIA is required for extended ethernet media types,
but iflib did not support it.
Reported by: Bhargava Chenna Marreddy <bhargava.marreddy@broadcom.com>
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D13312
A correct destruction is important for WITNESS(4) and LOCK_PROFILING(9).
Submitted by: Sebastian Huber <sebastian.huber@embedded-brains.de>
MFC after: 1 week
SPDB was cleaned using TAILQ_CONCAT() instead of calling key_unlink()
for each SP, thus we need to properly clean lists in each bucket of
V_sphashtbl to avoid panic in hashdestroy() when INVARIANTS is enabled.
Do the same for V_acqaddrhashtbl and V_acqseqhashtbl.
When we are called in DEFAULT_VNET, destroy also all global locks and
drain key_timer callout.
Reported by: kp
Tested by: kp
MFC after: 1 week
We periodically record synchronization progress in the metadata
block of the disk being synchronized; this allows an interrupted
synchronization to be resumed. However, the frequency of these
updates heavily pessimized synchronization time on some media. This
change modifies gmirror to update metadata based on a time period,
and adds a sysctl to control that period. The default value results
in a much lower update frequency and increases the completion time
for an interrupted rebuild only marginally.
Reported by: Andre Albsmeier <andre@fbsd.e4m.org>
MFC after: 3 weeks
This change adds an implementation of a sysent for running CloudABI
armv6 and armv7 binaries on FreeBSD/arm64. It is a somewhat literal copy
of the armv6 version, except that it's been patched up to use the proper
registers.
Just like for cloudabi32.ko on FreeBSD/amd64, we make use of a vDSO that
automatically pads system call parameters to 64-bit value. These are
stored in a buffer on the stack, meaning we need to use copyin() and
copyout() unconditionally.
"panic: vdev_geom_close_locked: cp->private is NULL"
This panic will result if ZFS fails to open a device due to either of the
following reasons:
1) The device's sector size is greater than 8KB.
2) ZFS wants to open the device RW, but it can't be opened for writing.
The solution is to change the initialization order to ensure that the
assertion will be satisfied.
PR: 221066
Reported by: David NewHamlet <wheelcomplex@gmail.com>
Reviewed by: avg
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D13278
"panic: vdev_geom_close_locked: cp->private is NULL"
This panic will result if ZFS fails to open a device due to either of the
following reasons:
1) The device's sector size is greater than 8KB.
2) ZFS wants to open the device RW, but it can't be opened for writing.
The solution is to change the initialization order to ensure that the
assertion will be satisfied.
PR: 221066
Reported by: David NewHamlet <wheelcomplex@gmail.com>
Reviewed by: avg
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D13278
