Replace various void * / int argument combinations with common structures:
- ieee80211_ratectl_tx_status for *_tx_complete();
- ieee80211_ratectl_tx_stats for *_tx_update();
While here, improve amrr_tx_update() for a bit:
1. In case, if receiver is not known (typical for Ralink USB drivers),
refresh Tx rate for all nodes on the interface.
2. There was a misuse:
- otus(4) sends non-decreasing counters (as originally intended);
- but ural(4), rum(4) and run(4) are using 'read & clear' registers
to obtain statistics for some period of time (and those 'last period'
values are used as arguments for tx_update()). If arguments are not big
enough, they are just discarded after the next call.
Fix: move counting into *_tx_update()
(now otus(4) will zero out all node counters after every tx_update() call)
Tested with:
- Intel 3945BG (wpi(4)), STA mode.
- WUSB54GC (rum(4)), STA / HOSTAP mode.
- RTL8188EU (urtwn(4)), STA mode.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D8037
- Add a counter into 'struct ieee80211_node_table' to save current number
of allocated nodes.
(allows to remove array overflow checking in ieee80211_iterate_nodes()).
- Add ieee80211_iterate_nodes_vap() function; unlike non-vap version,
it iterates on nodes for specified vap only.
In addition to the above:
- Remove ieee80211_iterate_nt(); it is not used by drivers / net80211
outside ieee80211_iterate_nodes() function + cannot be separated due
to structural changes in code.
Since size of 'struct ieee80211_node_table' (part of ieee80211com,
which is a part of driver's softc) is changed all wireless drivers /
kernel need to be recompiled.
Tested with wpi(4), STA mode.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D7996
file descriptor for the given posix mqueue. Export the
timer_oshandle_np() symbol to get ktimer id for the given posix timer.
Requested by: Lewis Donzis <lew@perftech.com>
Reviewed by: jilles
Discussed with: kan
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
- Convert "options EVDEV" to "device evdev" and "device uinput", add
modules for both new devices. They are isolated subsystems and do not
require any compile-time changes to general kernel subsytems
- For hybrid drivers that have evdev as an optional way to deliver input
events add option EVDEV_SUPPORT. Update all existing hybrid drivers
to use it instead of EVDEV
- Remove no-op DECLARE_MODULE in evdev, it's not required, MODULE_VERSION
is enough
- Add evdev module dependency to uinput
Submitted by: Vladimir Kondratiev <wulf@cicgroup.ru>
A single gratuitous ARP (GARP) is always transmitted when an IPv4
address is added to an interface, and that is usually sufficient.
However, in some circumstances, such as when a shared address is
passed between cluster nodes, this single GARP may occasionally be
dropped or lost. This can lead to neighbors on the network link
working with a stale ARP cache and sending packets destined for
that address to the node that previously owned the address, which
may not respond.
To avoid this situation, GARP retransmissions can be enabled by setting
the net.link.ether.inet.garp_rexmit_count sysctl to a value greater
than zero. The setting represents the maximum number of retransmissions.
The interval between retransmissions is calculated using an exponential
backoff algorithm, doubling each time, so the retransmission intervals
are: {1, 2, 4, 8, 16, ...} (seconds).
Due to the exponential backoff algorithm used for the interval
between GARP retransmissions, the maximum number of retransmissions
is limited to 16 for sanity. This limit corresponds to a maximum
interval between retransmissions of 2^16 seconds ~= 18 hours.
Increasing this limit is possible, but sending out GARPs spaced
days apart would be of little use.
Submitted by: David A. Bright <david.a.bright@dell.com>
MFC after: 1 month
Relnotes: yes
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D7695
Because rtsold listens for RAs on a raw socket, it may receive RAs from
interfaces that it does not manage. Such events can result in excessive
logging.
Submitted by: Franco Fichtner <franco@opnsense.org>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D8108
This restriction was inherited from upstream but is not relevant on FreeBSD.
Furthermore, it hindered the tracing of locking primitive subroutines.
MFC after: 1 week
Previously, kdump used the kernel-only timervalsub() macro which required
defining _KERNEL when including <sys/time.h>. Now, kdump uses the existing
userland API. The timercmp() usage to check for a backwards timestamp is
also clearer and simpler than the previous code which checked the result of
the subtraction for a negative value.
While here, take advantage of the 3-arg timersub() to store the subtraction
results in a tempory timeval instead of overwriting the timestamp in the
ktrace record and then having to restore it.
The kernel uses a few negative errno values for internal conditions
such as requesting a system call restart. Normally these errno values
are not exposed to userland. However, kdump needs access to these
values as some of then can be present in a ktrace system call return
record. Previously kdump was defining _KERNEL to gain access to ehse
values, but was then having to manually declare 'errno' (and doing it
incorrectly). Now, kdump uses _WANT_KERNEL_ERRNO instead of _KERNEL
and uses the system-provided declaration of errno.
In particular, 64-bit system call arguments use up two register_t
arguments for 32-bit processes. They must also be aligned on a 64-bit
boundary on 32-bit powerpc processes. This fixes the decoding of
lseek(), procctl(), and wait6() arguments for 32-bit processes (both
native and via freebsd32).
Note that the ktrace system call return record only returns a single
register, so the return value of lseek is always truncated to the low
32-bits for 32-bit processes.
is NULL and the function jumps to the "release:" label.
For this case, the "inp" was write locked, but the code attempted to
read unlock it. This patch fixes the problem.
This case could occur for NFS over UDP mounts, where the server was
down for a few minutes under certain circumstances.
Reported by: bde
Tested by: bde
Reviewed by: gnn
MFC after: 2 weeks
VM_MEMATTR_WRITE_COMBINING sets write-through cache flag for framebuffer
memory that prevents pixel data from being stuck in cache until evicition
happens
On ARM if memattr is not overriden mmap(2) maps framebuffer
memory as WBWA which means part of changes to content in userland
end up in cache and appear on screen gradually as cache lines are
evicted. This change adds configurable memattr that hardware fb
implementation can set to get the memory mapping type it
requires:
- Add new flag FB_FLAG_MEMATTR that indicates that framebuffer
driver overrides default memattr
- Add new field fb_memattr to struct fb_info to specify requested
memattr
Reviewed by: ray
Differential Revision: https://reviews.freebsd.org/D8064
It appears that this assertion can be tripped in some cases when
multiple interfaces are on the same link. Until this is resolved, revert a
part of r306305 and simply log a message if the DAD timer fires on a
non-tentative address.
Reported by: jhb
X-MFC With: r306305
rS306534 did create bad cstyle by my mistake, correcting it.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D8103
Prepare for making evdev a module. "Pure" evdev device drivers (like
touchscreen) and evdev itself can be built as a modules regardless of
"options EVDEV" in kernel config. So if people does not require evdev
functionality in hybrid drivers like ums and ukbd they can, for instance,
kldload evdev and utouchscreen to run FreeBSD in kiosk mode.
In cam_periph_runccb, cam_periph_ccbwait was using the value of the ccb
pinfo.index and status fields to determine whether the ccb was done,
but these fields are updated without a contending lock and could glitch
into states that would be erroneously interpreted as done. Instead,
have cam_periph_ccbwait look for the explicit result of the function
cam_periph_done.
Submitted by: Ryan Libby <rlibby@gmail.com>
Reviewed by: mav
MFC after: 3 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D8020
