PCP and CFI fields.
* Ethernet_type for VLAN encapsulation is tunable, default is 0x8100;
* PCP (Priority code point) and CFI (canonical format indicator) is
tunable per VID;
* Tunable encapsulation to support 802.1q
* Encapsulation/Decapsulation code improvements
New messages have been added for this netgraph node to support the
new features.
However, the legacy "vlan" id is still supported and compiled in by
default. It can be disabled in a future release.
TODO:
* Documentation
* Examples
PR: kern/161908
Submitted by: Ivan <rozhuk.im@gmail.com>
- add the macro NETMAP_RING_FIRST_RESERVED() which returns
the index of the first non-released buffer in the ring
(this is useful for code that retains buffers for some time
instead of processing them immediately)
quantum bytewise to the address of a 64-bit variable results in writing
to the "wrong" 32-bit half so adjust the address accordingly. This fix
is implemented in a hackish way for two reasons:
o in order to be able to get it into 8.3 with zero impact on the little-
endian architectures where this bug has no effect and
o to avoid blowing the x86 boot2 out of the water again when compiling
it with clang, which all sane versions of this fix tested do.
This change fixes booting from UFS1 file systems on big-endian machines.
MFC after: 3 days
make use of it where possible.
This primarily brings in support for newer hardware, and FreeBSD is not yet
able to support the abundance of IRQs on new hardware and many features in the
Ethernet driver.
Because of the changes to IRQs in the Simple Executive, we have to maintain our
own list of Octeon IRQs now, which probably can be pared-down and be specific
to the CIU interrupt unit soon, and when other interrupt mechanisms are added
they can maintain their own definitions.
Remove unmasking of interrupts from within the UART device now that the
function used is no longer present in the Simple Executive. The unmasking
seems to have been gratuitous as this is more properly handled by the buses
above the UART device, and seems to work on that basis.
of the Cavium Simple Executive, which violates large function growth rules
in such a way that simply increasing the large function growth parameter is
insufficient.
o) The MAC set must occur before the multicast list is set up as the former
will enable the CAM unconditionally, while promiscuous mode disables it,
so if promiscuous mode is to be set this must occur after the MAC is
programmed.
o) The multicast list must be set up unconditionally as even if flags have
not changed, if the interface has gone through a reinitialization, the
state of the CAM as changed by the MAC initialization could be incorrect.
o) Call octm_init when flags change, even if the interface is already running.
kernel version introduced the sysctl (based upon a linux man-page)
- add comments to sscalls.master regarding some names of sysctls which are
different than the linux-names (based upon the linux unistd.h)
- add some dummy sysctls
- name an unimplemented sysctl
MFC after: 1 month
Lower (ISA) IRQs are working, but allowed mask is not set correctly.
Block both by default to allow HP BL465c G6 blade system to boot.
Reported by: Attila Nagy <bra@fsn.hu>
MFC after: 1 week
Although access to the flags to check/set OACTIVE is racy due to how
the default if_start() function works, this should remove any races
with read/modify/write between threads.
don't setup the avp mcast queue.
This is a bit annoying though - it turns out the mcast queue isn't
initialised for STA mode but it's then touched to see whether anything
is in it. That should be fixed in a subsequent commit.
Noticed by: gperez@entel.upc.edu
PR: kern/165895
Instead of using 25MHz equality threshold, look for the nearest value when
handling dev.cpu.0.freq sysctl and for exact match when it is expected.
ACPI may report extra level with frequency 1MHz above the nominal to
control Intel Turbo Boost operation. It is not a bug, but feature:
dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ...
In this case value 2933 means 2.93GHz, but 2934 means 3.2-3.6GHz.
I've found that my Core i7-870 based system has Intel Turbo Boost disabled
by default and without this change it was absolutely invisible and hard
to control.
MFC after: 2 weeks
After 8.0-RELEASE, iwi(4) doesn't send any data frames in infrastructure
mode.
Bacause of the condition `while (frm < efrm)', IEEE80211_VERIFY_LENGTH()
was checking item length beyond the ieee80211_frame region, and returned
from iwi_checkforqos() without setting flags, capinfo and associd.
In infrastructure mode associd is required, so this problem causes
discarding mbuf in ieee80211_start().
PR: kern/165819
Tested/Reviewed/Supported by: bschmidt and adrian
MFC after: 1 week
- Pass number of events to the statclock() and profclock() functions
same as to hardclock() before to not call them many times in a loop.
- Rename them into statclock_cnt() and profclock_cnt().
- Turn statclock() and profclock() into compatibility wrappers,
still needed for arm.
- Rename hardclock_anycpu() into hardclock_cnt() for unification.
MFC after: 1 week
- Remove unneeded whitespace for function calls.
- Add empty line at the top of functions without local variables.
- Change while (1) to for (;;).
MFC after: 1 week
socket is used. The previous code structure assumed that AF_INET sockets
were always available, which is an invalid assumption on IPv6-only systems.
This merges the fololowing revisions from NetBSD:
src/usr.bin/ftp/main.c 1.120
src/usr.bin/ftp/util.c 1.156
PR: bin/162661
Tested by: bz
Obtained from: NetBSD
MFC after: 1 week
for TLS microbenchmark using global-dynamic TLS model on amd64 (which is
default for PIC dso objects).
Split the slow path into tls_get_addr_slow(), for which inlining is
disabled. This prevents the registers spill on tls_get_addr_common()
entry.
Provide static branch hint to the compiler, indicating that slow path
is not likely to be taken.
While there, do some minimal style adjustments.
Reported and tested by: davidxu
MFC after: 1 week
XXX It would be good to use a better way to size intrcnt.
o) Fix literal 4s that are supposed to be sizeof (u_long).
XXX Why the * 2 here? Is this an artifact of a different system that this
code came from? We seem to allocate twice as much space for intrcnt
as we admit to in sintrcnt.
In a very noisy 2.4GHz environment (with HT/40 enabled, making it worse)
I saw the following occur:
* the air was considered "busy" a lot of the time;
* the cabq time is quite short due to staggered beacons being enabled;
* it just wasn't able to keep up TX'ing CABQ frames;
* .. and the cabq would swallow up all the TX ath_buf's.
This patch introduces a twiddle which allows the maximum cabq depth to be
set, forcing further frames to be dropped.
It defaults to the TX buffer count at the moment, so the default behaviour
isn't changed.
I've also started fleshing out a similar setup for the data path, so
it doesn't swallow up all the available TX buffers and preventing management
frames (such as ADDBA) out.
PR: kern/165895
frames with stations in power saving mode.
I'm not (yet) sure how to handle TX'ing aggregates frames to stations
that are in power saving mode, or whether that's even a feasible thing
to do. So in order to (mostly) not forget, leave a couple of comments
in the code.
The code presently assumes that the aggregation TID state for an ath_node
is locked not by the ath_node lock or a node+TID lock, but behind the
hardware queue said TID maps to. This assumption is going to be
incorrect for stations in power saving mode as we'll be TX'ing frames
on the multicast queue.
In any case, I'm afraid its a "later problem". :/
and fixing the format string in sbin/fsdb/fsdbutil.c instead.
Note the remark "Work around a problem with format string warnings and
ntohs macros" was actually incorrect. The DIP(dp, di_nlink) macro
invocation actually returned an int, due to its ternary expression, even
though the di_nlink members of struct ufs1_dinode and struct ufs2_dinode
are both defined as int16_t.
MFC after: 2 weeks
__uint16_t, we can partially undo r228668.
Note the remark "Work around a clang false positive with format string
warnings and ntohs macros (see LLVM PR 11313)" was actually incorrect.
Before r232745, on some arches, the ntohs() macros did in fact return
int, not uint16_t, so clang was right in warning about the %hu format
string.
MFC after: 2 weeks
