Do not compare the existing mask of a cpuset with a new mask when changing
the mask of a cpuset.  Also, change the cpuset's mask before updating the
masks of all children.  Previously changing a cpuset's mask first required
setting the mask to a super-set of both the old and new masks and then
changing it a second time to the new mask.
Complete r251452:
Avoid to busy/unbusy a page in cases where there is no need to drop the
vm_obj lock, more nominally when the page is full valid after
vm_page_grab().

Sponsored by:	EMC / Isilon storage division
Reviewed by:	alc
Switch to 2-clause license and standard text

Approved by:	bms@
Fix r251444 so that gssd.c still builds for WITHOUT_KERBEROS.

Reported by:	bf1783@gmail.com
MFC after:	2 weeks
MFV r251474:

 * Illumos zfs issue #3137 L2ARC compression

Whether or not to compress buffers entering the L2ARC is
controlled by "compression" setting on the dataset, when
compression is not "off", L2ARC compression is enabled.

The compress method is always LZ4 for L2ARC when enabled
because it works best for the scenario.

MFC after:	2 weeks
Simplify the checking of flags for cam_periph_mapmem().  This gets rid of
a lot of code redundancy and grossness at very minor expense.

Reviewed by:	smh
Obtained from:	Netflix
MFC after:	3 days
gcc: install AMD intrinsics header ammintrin.h

This file was included in the changes from r251212 and originated
in the pre-GPLv3 gcc43 branch.

MFC after:	2 weeks
Do not report current link status if driver is not running.
Reporting link status in driver has a side-effect that makes mii(4)
check current link status.  mii(4) will call link status change
callback when it sees link state change.  Normally this wouldn't
have problems. However, ASF/IPMI firmware can actively access PHY
regardless of driver's running state such that reporting link
status for not-running interface can generate meaningless link
UP/DOWN messages.

This change also makes dhclient think driver got a valid link
regardless of link establishment so it will bypass dhclient's
initial link status check. I think that wouldn't be issue
though.

Tested by:	Daniel Braniss <danny@cs.huji.ac.il>
Correct setting TX random backoff register. This register is
implemented as a 10 bits linear feedback shift register so only
lower 10 bits are valid.
Because this register is used to initialize random backoff interval
register only when resolved duplex is half-duplex, it wouldn't have
caused issues in these days.

Submitted by:	Masanobu SAITOH <msaitoh@NetBSD.org>
Add bluetooth fixes to the AR5416/AR92xx HAL:

* Call the bluetooth setup function during the reset path, so the bluetooth
  settings are actually initialised.
* Call the AR9285 diversity functions during bluetooth setup; so the AR9285
  diversity and antenna configuration registers are correctly programmed
* Misc debugging info.

Tested:

* AR9285+AR3011 bluetooth combo; this code itself doesn't enable bluetooth
  coexistence but it's part of what I'm currently using.
Add accessor macros for the bluetooth coexistence routines.
Revert r238399.

The "failok" option doesn't have any effect at all unless specified in
fstab(5) and combined with the -a flag. The "failok" option is already
documented in fstab(5).

PR:		177630
No objection:	eadler
MFC after:	1 week
Use getnameinfo(3) instead of inet_ntop(3) to make printable versions of
sockaddr_in6 structures. getnameinfo(3) does the same thing, but it is
also able to represent a scope zone id as described in the RFC 4007.

MFC after:	2 weeks
Bring over the initial static bluetooth coexistence configuration
for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC.

The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285.

The code in if_ath_btcoex.c sets up the initial hardware mapping
and coexistence configuration.  There's nothing special about it -
it's static; it doesn't try to configure bluetooth / MAC traffic priorities
or try to figure out what's actually going on.  It's enough to stop basic
bluetooth traffic from causing traffic stalls and diassociation from
the wireless network.

To use this code, you must have the above NIC.  No, it won't work
for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards.

Then you set a kernel hint before boot or before kldload, where 'X'
is the unit number of your AR9285 NIC:

# kenv hint.ath.X.btcoex_profile=wb195

This will then appear in your boot messages:

[100482] athX: Enabling WB195 BTCOEX

This code is going to evolve pretty quickly (well, depending upon my
spare time) so don't assume the btcoex API is going to stay stable.

In order to use the bluetooth side, you must also load in firmware using
ath3kfw and the binary firmware file (ath3k-1.fw in my case.)

Tested:

* AR9280, no interference
* WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries
  were enough to cause traffic stalls and disassociations.  This has
  stopped with the btcoex profile code.

TODO:

* Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence
  is enabled.  No, I don't know why.  It's likely some kind of bug to do
  with the AR3011 sending bluetooth coexistence signals whilst the device
  is asleep.  Since we don't actually sleep the MAC just yet, it shouldn't
  be a problem.  That said, to be totally correct:

  + ASPM should be disabled - upon attach and wakeup
  + The PCIe powersave HAL code should never be called

  Look at what the ath9k driver does for inspiration.

* Add WB197 (AR9287+AR3012) support
* Add support for the AR9485, which is another combo like the AR9285
* The later NICs have a different signaling mechanism between the MAC
  and the bluetooth device; I haven't even begun to experiment with
  making that HAL code work.  But it should be a lot more automatic.

* The hardware can do much more interesting traffic weighting with
  bluetooth and wifi traffic.  None of this is currently used.
  Ideally someone would code up something to watch the bluetooth traffic
  GPIO (via an interrupt) and then watch it go high/low; then figure out
  what the bluetooth traffic is and adjust things appropriately.

* If I get the time I may add in some code to at least track this stuff
  and expose statistics.  But it's up to someone else to experiment with
  the bluetooth coexistence support and add the interesting stuff (like
  "real" detection of bulk, audio, etc bluetooth traffic patterns and
  change wifi parameters appropriately - eg, maximum aggregate length,
  transmit power, using quiet time to control TX duty cycle, etc.)
Don't hold the node lock over the iterator.

The "find node" function call will increase the node reference anyway;
so there's no reason to hold the node table lock during the MLME change.

The only reason I could think of is to stop overlapping mlme ioctls
from causing issues, but this should be fixed a different way.

This fixes a whole class of LORs that creep up when nodes are being
timed out or removed by hostapd.

Tested:

* AR5416, hostap, with nodes coming and going.  No LORs or stability
  issues were observed.
Properly set curvnet context in lagg_port_setlladdr() task handler.

Reported by:	Nikos Vassiliadis <nvass gmx.com>
Submitted by:	zec
Tested by:	Nikos Vassiliadis <nvass gmx.com>
MFC after:	1 week
Add libusb_get_port_numbers

libusbx deprecated libusb_get_port_path and replaced it with
libusb_get_port_numbers.  The latter omits an extra parameter which was
unused in the FreeBSD implementation anyway.
Add support for polling the XHCI interrupt handler when
the regular interrupt handler is not working properly or
in case of MSI interrupts which are not yet supported.
Remove interrupt setup code for FreeBSD versions older
than 700031.

MFC after:	1 week
PR:		usb/179342
FreeBSD 8.4 added.
Disable IGMPv3 link timers on a transition to IGMPv2.

Submitted by:	Alan Smithee