r315564 trasz March 19, 2017, 4:17 p.m.
MFC after:	2 weeks
ViewVC
r315561 trasz March 19, 2017, 3:53 p.m.
iscsi", along with all the other relevant components.

MFC after:	2 weeks
ViewVC
r315560 trasz March 19, 2017, 3:49 p.m.
MFC after:	2 weeks
Sponsored by:	DARPA, AFRL
ViewVC
r315552 kib March 19, 2017, 2:42 p.m.
When re-calculating the last inclusive page index after the pager
call, -1 was erronously ommitted.  If the pager extended the run
(unlikely), the result would be insertion of the valid page mapping
outside the current map entry range.

Found by:	alc
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
ViewVC
r315545 mav March 19, 2017, 1:46 p.m.
Since we support RQSTYPE_RPT_ID_ACQ, that functionality is only useful
in loop mode, which probably doesn't worth having this hack in 2017.

MFC after:	2 weeks
ViewVC
r315536 mav March 19, 2017, 10:28 a.m.
It is chip-specific and has nothing to do with platform.

MFC after:	2 weeks
ViewVC
r315534 mav March 19, 2017, 9:36 a.m.
MFC after:	2 weeks
ViewVC
r315533 mav March 19, 2017, 9:30 a.m.
This code has nothing to do with specific platform.

MFC after:	2 weeks
ViewVC
r315531 adrian March 19, 2017, 5 a.m.
When I initially did this 11n TX work in days of yonder, my 802.11 standards
clue was ... not as finely tuned.  One of the things in 802.11-2012 (which
I guess technically was after I did this work, but I'm sure it was like this
in the previous rev?) is that among other traffic classes, three things are
important:

* group addressed frames should be default non-QoS, even if they're QoS frames, and
* group addressed frames should have a seqno out of a different space than the
  per-TID QoS one; and because of this
* group addressed frames, being non-QoS, should never be in the Block-ACK window
  for TX.

Now, net80211 and now this code cheats by using the non-QOS TID, but ideally
we'd introduce a separate seqno space just for multicast/group traffic for
TX and RX comparison.

Later extensions (eg reliable multicast / multimedia) express what one should do
when doing multicast traffic in a TID.  Now, technically we /could/ do group traffic
as QoS traffic and throw it into a per-TID seqno space, but this definitely
introduces ordering issues when you take into account things like CABQ behaviour.
(Ie, if some traffic in the TID goes into the CABQ and some doesn't, because
it's doing a split of multicast and non-multicast traffic, then you have
seqno ordering issues.)

So, until someone implements 802.11vv reliable multicast / multimedia extensions,
group traffic is non-QoS.

Next, software/hardware queue TID mapping.  In the past I believed the WME tagging
of frames because well, net80211 had a habit of tagging things like management
traffic with it.  But, then we also map QoS traffic categories to TIDs as well.
So, we should obey the TID!  But! then it put some management traffic into higher
WME categories too, as those frames don't have QoS TIDs.  But! It'd do things like
put things like QoS action frames into higher WME categories, when they should
be kept in-order with the rest of the traffic for that TID.  So! Given all of this,
the ath(4) driver does overrides to not trust the WME category.

I .. am undoing some of this.  Now, the TID has a 1:1 mapping to the hardware
queue.  The TID is the primary source of truth now for all QoS traffic.
The WME is only used for non-QoS traffic.  This now means that any TID traffic
queued should be consistently queued regardless of WME, so things like the
"TX finished, do more TX" that is occuring right now for transmit handling
should be "better".

The consistent {TID, WME} -> hardware queue mapping is important for
transmit completion.  It's used to schedule more traffic for that
particular TID, because that {many TID}:{1 TXQ} mapping in ath_tx_tid_sched()
is used for driving completion.  Ie, when the hardware queue completes,
it'll walk that list of scheduled TIDs attached to that TXQ.

The eventual aim is to get ready for some other features around putting
some data into other hardware queues (eg for better PS-POLL support,
uAPSD, support, correct-er TDMA support, etc) which requires that
I tidy all of this up in preparation for then introducing further
TID scheduling that isn't linked to a hardware TXQ (likely a per-WME, per-TID
driver queue, and a per-node driver queue) to enable that.

Tested:

* AR9380, STA mode
* AR9380, AR9580, AP mode
ViewVC
r315530 ian March 19, 2017, 4:03 a.m.
cleanups enabled by that:

 - The only thing left in imx_gptvar.h was the softc, which IMO never
   should have been in there at all.  Move it into the driver, and
   delete the header file.

 - Remove several unneeded #includes from the driver.

 - Change imx_gpt_softc from global to static (it's used by DELAY()), and
   don't redundantly static-initialize it to NULL.
ViewVC
r315529 kp March 19, 2017, 3:06 a.m.
In pf_route6() we re-run the ruleset with PF_FWD if the packet goes out
of a different interface. pf_test6() needs to know that the packet was
forwarded (in case it needs to refragment so it knows whether to call
ip6_output() or ip6_forward()).

This lead pf_test6() to try to evaluate rules against the PF_FWD
direction, which isn't supported, so it needs to treat PF_FWD as PF_OUT.
Once fwdir is set correctly the correct output/forward function will be
called.

PR:		217883
Submitted by:	Kajetan Staszkiewicz
MFC after:	1 week
Sponsored by:	InnoGames GmbH
ViewVC
r315528 bjk March 19, 2017, 1:24 a.m.
man(1) has some logic to use two spaces after a full stop, which is
useful for spotting sentence breaks in monospace fonts.  However,
this logic is very simple, treating almost all '.' characters as
end-of-sentence markers, unless followed by certain other
characters.  For example, '.,' is not end-of-sentence, and neither
is ".) ", but ".)" at the end of a line triggers the sentence-end
detection.

Apply a zero-width space to a few instances of this in share/man,
and also supply a missing full stop for an instance that occurred at
the end of a sentence.

Leave untouched several instances that are at the end of a sentence
or list element.

Reported by:	0mp (ieee80211.9)
ViewVC
r315527 vangyzen March 19, 2017, 12:54 a.m.
Sponsored by:	Dell EMC
ViewVC
r315526 vangyzen March 19, 2017, 12:51 a.m.
Add a clock_nanosleep() syscall, as specified by POSIX.
Make nanosleep() a wrapper around it.

Attach the clock_nanosleep test from NetBSD. Adjust it for the
FreeBSD behavior of updating rmtp only when interrupted by a signal.
I believe this to be POSIX-compliant, since POSIX mentions the rmtp
parameter only in the paragraph about EINTR. This is also what
Linux does. (NetBSD updates rmtp unconditionally.)

Copy the whole nanosleep.2 man page from NetBSD because it is complete
and closely resembles the POSIX description. Edit, polish, and reword it
a bit, being sure to keep any relevant text from the FreeBSD page.

Reviewed by:	kib, ngie, jilles
MFC after:	3 weeks
Relnotes:	yes
Sponsored by:	Dell EMC
Differential Revision:	https://reviews.freebsd.org/D10020
ViewVC
r315525 jhb March 19, 2017, 12:36 a.m.
Decode the last argument to ioctl() as a pointer rather than an int.
Eventually this could use 'int' for the _IOWINT() case and pointers for
all others.

The last argument to sendto() is a socklen_t value, not a pointer.
ViewVC