r318575 dim May 20, 2017, 11:40 a.m.
r318574 emaste May 20, 2017, 11:20 a.m.
Metadata printing with -b, -H, or -n flags suffered from a few flaws:

1) -b/offset printing was broken when used in conjunction with -o

2) With -o, bsdgrep did not print metadata for every match/line, just
   the first match of a line

3) There were no tests for this

Address these issues by outputting this data per-match if the -o flag is
specified, and prior to outputting any matches if -o but not --color,
since --color alone will not generate a new line of output for every
iteration over the matches.

To correct -b output, fudge the line offset as we're printing matches.

While here, make sure we're using grep_printline in -A context.  Context
printing should *never* look at the parsing context, just the line.

The tests included do not pass with gnugrep in base due to it exhibiting
similar quirky behavior that bsdgrep previously exhibited.

Submitted by:	Kyle Evans <kevans91@ksu.edu>
Reviewed by:	cem
Differential Revision:	https://reviews.freebsd.org/D10580
r318571 emaste May 20, 2017, 3:51 a.m.
We should not set an arbitrary cap on the number of matches on a line,
and in any case MAX_LINE_MATCHES of 32 is much too low.  Instead, if we
match more than MAX_LINE_MATCHES, keep processing and matching from the
last match until all are found.

For the regression test, we produce 4096 matches (larger than we expect
we'll ever set MAX_LINE_MATCHES) and make sure we actually get 4096
lines of output with the -o flag.

We'll also make sure that every distinct line is getting its own line
number to detect line metadata not being printed as appropriate along
the way.

PR:		218811
Submitted by:	Kyle Evans <kevans91@ksu.edu>
Reported by:	jbeich
Reviewed by:	cem
Differential Revision:	https://reviews.freebsd.org/D10577
r318566 adrian May 20, 2017, 12:43 a.m.
When doing AMSDU offload, the driver (for now!) presents 802.11 frames with
the same sequence number and crypto sequence number / IV values up to the stack.
But, this will trip afoul over the sequence number detection.

So drivers now have a way to signify that a frame is part of an offloaded
AMSDU group, so we can just ensure that we pass those frames up to the

The logic will be a bit messy - the TL;DR will be that if it's part of
the previously seen sequence number then it belongs in the same burst.
But if we get a repeat of the same sequence number (eg we sent an ACK
but the receiver didn't hear it) then we shouldn't be passing those frames
up.  So, we can't just say "all subframes go up", we need to track
whether we've seen the end of a burst of frames for the given sequence
number or not, so we know whether to actually pass them up or not.

The first part of doing all of this is to ensure the ieee80211_rx_stats
struct is available in the RX sequence number check path and the
RX ampdu reorder path.  So, start by passing the pointer into these
functions to avoid doing another lookup.

The actual support will come in a subsequent commit once I know the
functionality actually works!
r318565 emaste May 20, 2017, 12:42 a.m.
r313948 partially fixed --mmap behavior but was incomplete.  This commit
generally reverts it and does it the more correct way- by just consuming
the rest of the buffer and moving on.

PR:		219402
Submitted by:	Kyle Evans <kevans91@ksu.edu>
Reviewed by:	cem
Differential Revision:	https://reviews.freebsd.org/D10820
r318562 jhb May 19, 2017, 10:54 p.m.
r318550 maxim May 19, 2017, 8:02 p.m.
PR:		219395
Submitted by:	Tiwei Bie
r318548 emaste May 19, 2017, 6:13 p.m.
General cleanup, for diff reduction with NetBSD and future use by FAT
support in makefs.

Submitted by:	Siva Mahadevan <smahadevan@freebsdfoundation.org>
Obtained from:	NetBSD
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D10821
r318546 ngie May 19, 2017, 5:14 p.m.
The previous logic was flawed in the sense that it assumed that /dev/md3
was always available. This was a caveat I noted in r306038, that I hadn't
gotten around to solving before now.

Cache the device for the mountpoint after executing mdmfs, then use the
cached value in basic_cleanup(..) when unmounting/disconnecting the md(4)

Apply sed expressions to use reuse logic in the NetBSD code that could
also be applied to FreeBSD, just with different tools.

Differential Revision:	D10766
MFC after:	1 week
Reviewed by:	bdrewery
Sponsored by:	Dell EMC Isilon
r318545 ngie May 19, 2017, 5:04 p.m.
I incorrectly started this pattern in r277541 with the opensm newsyslog.conf.d file,
and continued using it in r318441 and r318443.

This will fix the files being handled improperly via installworld, preventing tools like
etcupdate, mergemaster, etc from functioning properly when comparing the installed
contents on a system vs the contents in a source tree when doing merges.

PR:		219404
Submitted by:	Dan McGregor <dan.mcgregor@usask.ca>
MFC after:	2 weeks
MFC with:	r277541, r318441, r318443
Sponsored by:	Dell EMC Isilon
r318539 vangyzen May 19, 2017, 1:04 p.m.
Fix warnings about the following when WARNS=6 (which I will commit soon):

- casting away const
- no previous 'extern' declaration for non-static variable
- others as explained by #pragmas and comments
- unused parameters

The last is the only functional change.

Reviewed by:	kib
MFC after:	3 days
Sponsored by:	Dell EMC
Differential Revision:	https://reviews.freebsd.org/D10808
r318531 hselasky May 19, 2017, 12:22 p.m.
When creating EQs to handle CQ completion events for the PF or for
VFs, we create enough EQE entries to handle completions for the max
number of CQs that can use that EQ.

When SRIOV is activated, the max number of CQs a VF (or the PF) can
obtain is its CQ quota (determined by the Hypervisor resource
tracker).  Therefore, when creating an EQ, the number of EQE entries
that the VF should request for that EQ is the CQ quota value (and not
the total number of CQs available in the firmware).

Under SRIOV, the PF, also must use its CQ quota, because the resource
tracker also controls how many CQs the PF can obtain.

Using the firmware total CQs instead of the CQ quota when creating EQs
resulted wasting MTT entries, due to allocating more EQEs than were

MFC after:		3 days
Sponsored by:		Mellanox Technologies
r318530 mmel May 19, 2017, 11:45 a.m.
LLVM binaries are huge...

MFC after:	3 days
r318527 truckman May 19, 2017, 8:38 a.m.
(TS) method is used.  When packet timestamp is used, the "current_qdelay"
keeps storing the last queue delay value calculated in the dequeue
function.  Therefore, when a burst of packets arrives followed by
a pause, the "current_qdelay" will store a high value caused by the
burst and stick to that value during the pause because the queue
delay measurement is done inside the dequeue function.  This causes
the drop probability calculation function to calculate high drop
probability value instead of zero and prevents the burst allowance
mechanism from working properly.  Fix this problem by resetting
"current_qdelay" inside the drop probability calculation function
when the queue length is zero and TS option is used.

Submitted by:	Rasool Al-Saadi <ralsaadi@swin.edu.au>
MFC after:	1 week
r318526 wma May 19, 2017, 8:26 a.m.
Marvell Armada 380 is a uni-processor variant of the 38x SoC
family. A function platform_mp_setmaxid() was setting a hardcoded
value, which caused boot fail on A380. Fix this by relying on
the CPU count obtained from device tree nodes.

Submitted by:  Marcin Wojtas <mw@semihalf.com
Obtained from: Semihalf
Sponsored by:  Netgate
Reviewed by:   loos
Differential revision: https://reviews.freebsd.org/D10783