Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
XX_VirtToPhys(), by way of pmap_kextract(), is an expensive operation.
Profiling via dtrace during a series of iperf tests I found 16111 / 30432
stack frames were located in mmu_booke_kextract(), so eliminating this
expensive call should improve performance slightly. XX_PhysToVirt() is not
as expensive, but redundant calls in this context is wasteful.
We currently support the a83t's r_intc in a somewhat hack-ish way; our .dts
describes it as nmi_intc, and uses a subset of the actual register space to
make it line up with a20/a31 nmi offsets.
This breaks with the recent 4.14 update describing r_intc using the full
register space, so update aw_nmi to use the correct register offsets with
the right compat data in a way that doesn't break our current dts with
nmi_intc or upstream with r_intc described.
Reviewed by: manu
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D13122
Stale packets should not be transmitted when the interface comes up after being down.
Count the successfully transmitted ones for statistics and drop the rest.
Submitted by: Guy Yur <guyyur@gmail.com>
Differential Revision: https://reviews.freebsd.org/D12539
Use a spare dma map when attempting to map a new mbuf on the rx path.
If the mbuf allocation fails or the dma map loading for the new mbuf fails just reuse the old mbuf
and increase the drop counter.
Submitted by: Guy Yur <guyyur@gmail.com>
Differential Revision: https://reviews.freebsd.org/D12538
- use awg_encap and awg_txeof names to match iflib and other network drivers.
- handle m_collapse failure similarly by freeing the mbuf rather than reenqueuing it where it will continue to fail.
Submitted by: Guy Yur <guyyur@gmail.com>
Differential Revision: https://reviews.freebsd.org/D13035
TX_BUF_UA_INT is set when there are no buffers to transmit and can
happen before hw.awg.tx_interval segments have been transmitted.
To reduce load, tx cleanup should be done in hw.awg.tx_interval intervals.
Submitted by: Guy Yur <guyyur@gmail.com>
Differential Revision: https://reviews.freebsd.org/D13034
A packet may be built from multiple segments, don't increase the count for each segment
Submitted by: Guy Yur <guyyur@gmail.com>
Differential Revision: https://reviews.freebsd.org/D13032
According to the datasheet, TX_DESC_CTL is cleared when whole frame is transmitted or all
data in the current descriptor's buffer are transmitted.
When the mbuf and mapping are stored in the first segment and in a scenario where a tx
completion interrupt arrives for a frame and only the start of the next frame was transmitted,
at the time of interrupt processing the mbuf and mapping will be freed when processing the
first segment of the next frame but the other untrasmitted segments still need to use them.
Submitted by: Guy Yur <guyyur@gmail.com>
Differential Revision: https://reviews.freebsd.org/D13031
In a multi segment frame, if the first tx descriptor is marked with TX_DESC_CTL
but not all tx descriptors for the other segments in the frame are set up,
the TX DMA may transmit an incomplete frame.
To prevent this, set TX_DESC_CTL for the first tx descriptor only when done
with all the other segments.
Also, don't bother cleaning transmitted tx descriptors since TX_DESC_CTL
is cleared for them by the hardware and they will be reprogrammed before
TX_DESC_CTL is reenabled for them.
Submitted by: Guy Yur <guyyur@gmail.com>
Differential Revision: https://reviews.freebsd.org/D13030
The hardware will not issue a completion interrupt for a descriptor
with TX_INT_CTL set if it doesn't also have TX_LAST_DESC set.
Submitted by: Guy Yur <guyyur_gmail.com>
Differential Revision: https://reviews.freebsd.org/D13029
This also makes it so that top-level build targets do not immediately create
the OBJDIR. Only sub-make targets will do so. This avoids creating object
directories for targets like 'make check-old' or creating unneeded
MACHINE.MACHINE_ARCH directories during 'make tinderbox'.
Reported by: npn, lifanov
Tested by: npn, Mark Millard
Sponsored by: Dell
This will allow disabling some things like AUTO_OBJ early if not needed for the
directory/targets, without putting special logic into share/mk/*.sys.mk.
Sponsored by: Dell
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
Initially, only tag files that use BSD 4-Clause "Original" license.
RelNotes: yes
Differential Revision: https://reviews.freebsd.org/D13133
The old value was probably fine back in 1998, when that code was imported
(although the comments still mention VAX, which was quite obsolete by then);
now, however, it's too small to handle our libc, which results in some
additional calls to munmap/mmap later on. Asking for more virtual address
space is virtually free, and syscalls are not, thus the change.
It was suggested by kib@ that this might be a symptom of a deeper problem.
It doesn't only affect libc, though - the change also improves rtld memory
management for eg KDE libraries. I guess it's just a natural bloat.
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D12834
Do not invoke IPv4 NAT handler for non IPv4 packets. Libalias expects
a packet is IPv4. And in case when it is IPv6, it just translates them
as IPv4. This leads to corruption and in some cases to panics.
In particular a panic can happen when value of ip6_plen modified to
something that leads to IP fragmentation, but actual packet length does
not match the IP length.
Packets that are not IPv4 will be dropped by NAT rule.
Reported by: Viktor Dukhovni <freebsd at dukhovni dot org>
MFC after: 1 week
IPsec support can be loaded as kernel module, thus do not depend from
kernel option IPSEC and always build O_IPSEC opcode implementation as
enabled.
Obtained from: Yandex LLC
MFC after: 1 week
Sponsored by: Yandex LLC
