We can iterate over consecutive resident pages in the top-level object
using the object's page list rather than by performing lookups in the
object radix tree. This extends one of the optimizations in r312208 to the
case where a shadow chain is present.
Suggested by: alc
Reviewed by: alc, kib (previous version)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D9282
The checks have quadratic complexity over a number of advisory locks
active for a file and that could be a lot. What's the worse is that the
checks are done while holding ls_lock. That could lead to a long a very
long backlog and performance degradation even if all requested locks are
compatible (e.g. all shared locks).
The checks used to be under INVARIANTS.
Discussed with: kib
MFC after: 2 weeks
Sponsored by: Panzura
instead of their sys_*() counterparts in various compats. The svr4
is left untouched, because there's no point.
Reviewed by: ed@, kib@
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D9367
This would enqueue an event to send the gratuitous arp on a dying lagg
interface without any physical ports attached to it.
Apart from that, the taskqueue_drain() on lagg_clone_destroy() runs too
late, when the ifp data structure is already freed. Fix that too.
Obtained from: pfSense
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (Netgate)
There are no alternatives defined, so there's no point in keeping them. Also,
they weren't around every inline asm block anyway. Without __GNUCLIKE_ASM
defined, the guarded functions return garbage.
Reported by: Andrew Thompson
Clang complains about the shift of (1 << 7) into a int8_t changing the value:
warning: implicit conversion from 'int' to 'int8_t' (aka 'signed char') changes
value from 128 to -128 [-Wconstant-conversion]
Squash this warning by forcing clang to see it as an unsigned bit.
This seems odd, given that it's still a conversion of 128->-128, but I'm
guessing the explicit unsigned attribute notifies clang that sign really doesn't
matter in this case.
Reported by: Mark Millard <markmi AT dsl-only DOT net>
MFC after: 2 weeks
Summary:
Clang throws the following warning in powerpc intr_machdep:
/usr/src/sys/powerpc/powerpc/intr_machdep.c:454:15: warning: comparison of
constant -1 with expression of type 'enum intr_trigger' is always false
[-Wtautological-constant-out-of-range-compare]
if (i->trig == -1)
~~~~~~~ ^ ~~
This may lead to legitimate problems with aggressive optimizations, if not now
then in the future. To avoid this, add a new enum, INTR_TRIG_INVALID, set to
-1, and use this new enumeration in these checks.
Test Plan: Compile test.
Reviewed By: jhb, kib
Differential Revision: https://reviews.freebsd.org/D9300
Summary:
atomic_fcmpset_*() is analogous to atomic_cmpset(), but saves off the read value
from the target memory location into the 'old' pointer in the case of failure.
Requested by: mjg
Differential Revision: https://reviews.freebsd.org/D9325
After some digging and looking at packet traces, it looks like the
sequence number allocation being done by net80211 doesn't meet
802.11-2012.
Specifically, group addressed frames (broadcast, multicast) have
sequence numbers allocated from a separate pool, even if they're
QoS frames.
This patch starts to try and address this, both on transmit and
receive.
* When receiving, don't throw away multicast frames for now.
It's sub-optimal, but until we correctly track group addressed
frames via another TID counter, this is the best we can do.
* When doing A-MPDU checks, don't include group addressed frames
in the sequence number checks.
* When transmitting, don't allocate group frame sequence numbers
from the TID, instead use the NONQOS TID for allocation.
This may fix iwn(4) 11n because I /think/ this was one of the
handful of places where ni_txseqs[] was being assigned /outside/
of the driver itself.
This however doesn't completely fix things - notably the way that
TID assignment versus WME assignment for driver hardware queues
will mess up multicast ordering. For example, if all multicast
QoS frames come from one sequence number space but they're
expected to obey the QoS value assigned, they'll end up in
different queues in the hardware and go out in different
orders.
I can't fix that right now and indeed fixing it will require some
pretty heavy lifting of both the WME<->TID QoS assignment, as well
as figuring out what the correct way for drivers to behave.
For example, both iwn(4) and ath(4) shouldn't put QoS multicast
traffic into the same output queue as aggregate traffic, because
the sequence numbers are all wrong. So perhaps the correct thing
to do there is ignore the WME/TID for QoS traffic and map it all
to the best effort queue or something, and ensure it doesn't
muck up the TID/blockack window tracking. However, I'm /pretty/
sure that is still going to happen.
.. maybe I should disable multicast QoS frames in general as well,
but I don't know what that'll do for whatever the current state
of 802.11s mesh support is.
Tested:
* STA mode, ath10k NIC
* AP mode, AR9344/AR9580 AP
* iperf tcp/udp tests with concurrent multicast QoS traffic.
Before this, iperfs would fail pretty quickly because the sending
AP would start sending out QoS multicast frames that would be
out of order from the rest of the TID traffic, causing the blockack
window to get way, way out of sync.
This now doesn't occur.
TODO:
* verify which QoS frames SHOULD be tagged as M_AMPDU_MPDU.
For example, QoS NULL frames shouldn't be tagged!
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D9357
protection change.
On superpage promotion, x86 pmaps do not invalidate existing 4K
entries for the superpage range, because they are compatible with the
promoted 2/4M entry. But the invalidation on superpage removal or
protection change only did single INVLPG with the base address of the
superpage. This reliably flushed superpage TLB entry, and 4K entry
for the first page of the superpage, potentially leaving other 4K TLB
entries lingering. Do the invalidation of the whole superpage range
to correct the problem.
Note that the precise invalidation is done by x86 code for kernel_pmap
only, for user pmaps whole (per-AS) TLB is flushed. This made the bug
well hidden, because promotions of the kernel mappings require
specific load.
Reported and tested by: Jonathan Looney <jtl@netflix.com> (previous version)
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
convention for interfaces, because only one stf(4) interface can exist
in the system.
This disallow the use of unit numbers different than 0, however, it is
possible to create the clone without specify the unit number (wildcard).
In the wildcard case we must update the interface name before return.
This fix an infinite recursion in pf code that keeps track of network
interfaces and groups:
1 - a group for the cloned type of the interface is added (stf in this
case);
2 - the system will now try to add an interface named stf (instead of
stf0) to stf group;
3 - when pfi_kif_attach() tries to search for an already existing 'stf'
interface, the 'stf' group is returned and thus the group is added
as an interface of itself;
This will now cause a crash at the first attempt to traverse the groups
which the stf interface belongs (which loops over itself).
Obtained from: pfSense
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (Netgate)
in the i386 pmap.
The curcpu macro loads the per-cpu data pointer as its first step,
so the remaining steps of pcpu_find(curcpu) are circular.
get_pcpu() is already implemented for arm, arm64, and risc-v.
My plan is to implement it for the remaining architectures and use
it to replace several instances of pcpu_find(curcpu) in MI code.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D9370
-G0 is sufficent except on old version of clang (<3.8) and such versions
are unlikely to be generally useful on mips64.
Reported by: sbruno
Sponsored by: DARPA, AFRL
initialized, this can cause a divide by zero (if the VNET initialization
takes to long to complete).
Obtained from: pfSense
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (Netgate)
While GCC's __nonnull__ attribute is generally useful to prevent misuse of
some functions it also tends to do rather dangerous "optimizations". Now
that we have replaced (r312934) all such uses with the clang nullability
qualifiers, the GCC attribute is unnecessary.
Remove the definition completely to prevent its use in system's headers.
Replace uses of the GCC __nonnull__ attribute with the clang nullability
qualifiers. The replacement should be transparent for clang developers as
the new qualifiers will produce the same warnings and will be useful for
static checkers but will not cause aggressive optimizations.
GCC will not produce such warnings and developers will have to use
upgraded GCC ports built with the system headers from r312538.
Hinted by: Apple's Libc-1158.20.4, Bionic libc
MFC after: 11.1 Release
Differential Revision: https://reviews.freebsd.org/D9004
This interface type ("a parent interface of wlanX") is not used since
r287197
Reviewed by: adrian, glebius
Differential Revision: https://reviews.freebsd.org/D9308
driver to support exposing a GEOM device, which can be used to mount
Avalon-attached ROMs, reserved areas of DRAM, etc, as a filesystem:
commit 9deb1e60ea
Author: Robert N. M. Watson <robert.watson@cl.cam.ac.uk>
Date: Sat Mar 5 20:33:12 2016 +0000
Use format strings with make_dev(9) in avgen(4).
commit 0bf2176c23
Author: Robert N. M. Watson <robert.watson@cl.cam.ac.uk>
Date: Tue Mar 1 10:23:23 2016 +0000
Implement a new "geomio" configuration argument to altera_avgen(4),
the generic I/O device we attach to various BERI peripherals. The new
option requests that, instead of exposing the underlying device via a
special device node in /dev, it instead be exposed via geom(4),
allowing it to be used with filesystems. The current implementation
does not allow a device to be exposed both for file/mmap and geom, so
one of the two models must be selected when configuring it via FDT or
device.hints. A typical use of the new option will be:
sri-cambridge,geomio = "rw";
MFC after: 1 week
Sponsored by: DARPA, AFRL
CheriBSD, which attempt to work around an inherent race in the UART's
control-register design in detecting whether JTAG is currently,
present, which will otherwise lead to moderately frequent output
drops when running in polled rather than interrupt-driven operation.
Now, these drops are quite infrequent.
commit 9f33fddac9
Author: Robert N. M. Watson <robert.watson@cl.cam.ac.uk>
Date: Thu Jul 16 17:34:12 2015 +0000
Add a new sysctl, hw.altera_jtag_uart.ac_poll_delay, which allows the
(default 10ms) delay associated with a full JTAG UART buffer combined
with a lack of a JTAG-present flag to be tuned. Setting this higher
may cause some JTAG configurations to be more reliable when printing
out low-level console output at a speed greater than the JTAG UART is
willing to carry data. Or it may not.
commit 73992ef760
Author: Robert N. M. Watson <robert.watson@cl.cam.ac.uk>
Date: Sun Jan 1 15:13:07 2017 +0000
Minor improvements to the Altera JTAG UART device driver:
- Minor rework to the logic to detect JTAG presence in order to be a bit
more resilient to inevitable races: increase the retry period from two
seconds to four seconds for trying to find JTAG, and more agressively
clear the miss counter if JTAG has been reconnected. Once JTAG has
vanished, stop prodding the miss counter.
- Do a bit of reworking of the output code to frob the control register
less by checking whether write interrupts are enabled/disabled before
changing their state. This should reduce the opportunity for races
with JTAG discovery (which are inherent to the Altera
hardware-software interface, but can at least be minimised).
- Add statistics relating to interrupt enable/disable/JTAG
discovery/etc.
With these changes, polled-mode JTAG UART ttys appear substantially
more robust.
MFC after: 1 week
Sponsored by: DARPA, AFRL
Thank glebius for pointing this out:
"The network stuff shall not be added to sys/eventhandler.h"
Reviewed by: David_A_Bright_DELL.com, sephe, glebius
Approved by: sephe (mentor)
MFC after: 2 weeks
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9345
default, and the fewer changes relative to the upstream u-boot the
better.
Add compatibility links for the old names.
Add dts file for BeagleBone Green while we're here.
Upstream GCC and devel/mips64-gcc use "octeon+" as the CPU setting for
the Octeon processor in the EdgeRouter Lite. As of r312899 the base
system GCC 4.2.1 accepts octeon+ as an alias for the Octeon support
added in r208737 for the same CPU.
Sponsored by: The FreeBSD Foundation
regardless of what the default stack for the system is set to.
With current/default behavior, after changing the default tcp stack, the
application needs to be restarted to pick up that change. Setting this new knob
net.inet.tcp.functions_inherit_listen_socket_stack to '0' would change that
behavior and make any new connection use the newly selected default tcp stack.
Reviewed by: rrs
MFC after: 2 weeks
Sponsored by: Limelight Networks
We found routing performance dropped significantly when configuring
FreeBSD as a router, we are applying the following changes in order to
resolve those issues and hopefully perform better.
- don't prefetch the flags array, we usually don't need it
- prefetch the next cache line of each of the software descriptor arrays as
well as the first cache line of each of the next four packets' mbufs and
clusters
- reduce max copy size to 63 bytes
- convert rx soft descriptors from array of structures to a structure of arrays
- update copyrights
Submitted by: Matt Macy <mmacy@nextbsd.org>
undo_offload_socket() is only called by t4_connect() during a connection
setup failure, but t4_connect() still owns the TOE PCB and frees ita
after undo_offload_socket() returns. Release a reference in
undo_offload_socket() resulted in a double-free which panicked when
t4_connect() performed the second free. The reference release was
added to undo_offload_socket() incorrectly in r299210.
MFC after: 1 week
Sponsored by: Chelsio Communications
FASTTRAP_MAX_INSTR_SIZE is the largest valid value of a tracepoint, so
correct the assertion accordingly. This limit was hit with a 15-byte NOP.
Reported by: bdrewery
MFC after: 1 week
Sponsored by: Dell EMC Isilon
The intended use is to annotate frequently used globals which either rarely
change (and thus can be grouped in the same cacheline) or are an atomic counter
(which means it may benefit from being the only variable in the cacheline).
Linker script support is provided only for amd64. Architectures without it risk
having other variables put in, i.e. as if they were not annotated. This is
harmless from correctness point of view.
Reviewed by: bde (previous version)
MFC after: 1 month
Recent changes in the pseudo header accessor prototypes start to
use common code RxQ handle on datapath. The handle was located
at the end of the structure with members not used on datapath.
Reviewed by: philip
Sponsored by: Solarflare Communications, Inc.
MFC after: 2 days
Differential Revision: https://reviews.freebsd.org/D9359
TxQ is destroyed on stop and last used tag should be reset to default 0
on the next start.
Reviewed by: philip
Sponsored by: Solarflare Communications, Inc.
MFC after: 2 days
Differential Revision: https://reviews.freebsd.org/D9358
The MLX5 driver has four different types of DMA allocations which are
now allocated using busdma:
1) The 4K firmware DMA-able blocks. One busdma object per 4K allocation.
2) Data for firmware commands use the 4K firmware blocks split into four 1K blocks.
3) The 4K firmware blocks are also used for doorbell pages.
4) The RQ-, SQ- and CQ- DMA rings. One busdma object per allocation.
After this patch the mlx5en driver can be used with DMAR enabled in
the FreeBSD kernel.
MFC after: 1 week
Sponsored by: Mellanox Technologies
- When device disappears from PCI indicate error device state and:
1) Trigger command completion for all pending commands
2) Prevent new commands from executing and return:
- success for modify and remove/cleanup commands
- failure for create/query commands
3) When reclaiming pages for a device in error state don't ask FW to
return all given pages, just release the allocated memory
MFC after: 1 week
Sponsored by: Mellanox Technologies
PCI device(s), changes:
- alloc_entry() now clears bit for page slot entry aswell
- update of cmd->ent_arr[] is now under cmd->alloc_lock
- complete command if alloc_entry() fails
MFC after: 1 week
Sponsored by: Mellanox Technologies
By default reading the diagnostic counters is disabled. The firmware
decides which counters are supported and only those supported show up
in the dev.mce.X.diagnostics sysctl tree.
To enable reading of diagnostic counters set one or more of the
following sysctls to one:
dev.mce.X.conf.diag_general_enable=1
dev.mce.X.conf.diag_pci_enable=1
MFC after: 1 week
Sponsored by: Mellanox Technologies
consistent return values from the mlx5e_sq_has_room_for()
function. The two counters are incremented by different threads under
different locks.
MFC after: 1 week
Sponsored by: Mellanox Technologies
register, in addition to configuring it as input with the pinmux driver.
There was a control register bit commented as "no desc in datasheet". A
later revision of the manual reveals the bit to be an input/output control
for the timer pin. In addition to configuring capture or pulse mode, you
apparently have to separately configure the pin direction in the timer
control register.
Before this change, the timer block was apparently driving a signal onto a
pad configured by pinmux as input. Capture mode still accidentally worked
for me during testing because I was using a very strong signal source that
just out-muscled the weaker drive from the misconfigured pin.
* allocate an ext bit for fragment offload. Some NICs (like the ath10k
hardware in native wifi or 802.3 mode) support doing packet fragmentation
in firmware/hardware, so we don't have to do it here.
* allocate an ext bit for VHT and start using it.
* Although the hardware is awake, the power state handling doesn't think so.
So just explicitly wake it up early in setup so ath_hal calls don't complain.
* We shouldn't be transmitting or ACKing frames during DFS CAC or on passive
channels before we hear a beacon. So, start laying down comments in the
places where this work has to be done.
Note:
* The main bit missing from finishing this particular bit of work is a state
call to transition a VAP from passive to non-passive when a beacon is heard.
CAC is easy, it's an interface state. So, I'll go and add a method to control
that soon.
all of them in terms of an sbuf-based back-end, xpt_path_sbuf. This
unifies the implementation, but more importantly it stops the output
fropm being split between 4 or more invocations of printf. The
multiple invocations cause interleaving of the messages on the
console during boot, making the output of disk discovery often
unintelligible. This change helps a lot, but more work is needed.
Reviewed by: ken, mav
Sponsored by: Netflix
Commit r312747 ("Setup decoding windows for ARMADA38X") resulted
in build failing for Marvell platforms, which don't have AHCI controller.
This patch provides a fix by adding dummy functions for such cases.
On the occasion rename register dump routine to decode_win_ahci_dump,
in order to avoid confusion.
Submitted by: Marcin Wojtas <mw@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield
- Replace pcpu_find(curcpu) with get_pcpu(), which is much
more direct.
- Remove armv4 pcpu fields which I added in r286296 but never
needed to use.
- armv6 pc_qmap_addr was leftover from the old armv6 pmap
implementation. Rename it and put it to use in the new one.
Noted by: skra
Reviewed by: skra
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D9312
under a shared read lock. This patch attempts to upgrade the lock to
an exclusive write lock. If the exclusive write lock fails to be
obtained, the current fragment is not placed at the head of the list.
This portion of the patch was inspired by NetBSD ip_frag.c r1.4 (which
effectively removed the section of code that performed the reordering).
The patch to sys/contrib/ipfilter/netinet/ip_compat.h adds the
MUTEX_TRY_UPGRADE macro to support the patch to ip_frag.c.
The patch to contrib/ipfilter/lib/rwlock_emul.c supports this patch
by emulating the mutex in userspace when exercised by ipftest(1).
Inspired by: NetBSD ip_frag.c r1.4
MFC after: 1 month
