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 9deb1e60eaaaf7a3687e48c58af5efd756f32ec6
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 0bf2176c23e7425bfa042c08a24f8a25fe6d8885
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 9f33fddac9215e32781a4f016ba17eab804fb6d4
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 73992ef7607738b2973736e409ccd644b30eadba
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.
