MFC r259079:
  Add WITH_DVD to RELEASE_RMAKEFLAGS, otherwise it is not actually
  passed to 'make release'.

Sponsored by:	The FreeBSD Foundation
MFC r259053:

Pull in r196590 from upstream clang trunk (by rdivacky):

  Move the body of GCCInstallationDetector ctor into an init() function
  and call it from its only user. The linux toolchain. This saves quite
  a lot of directory searching on other platforms.

See http://docs.freebsd.org/cgi/mid.cgi?51E6FAF5.3080802 for the
original discussion.  With this fix, the search for gcc installations is
completely eliminated on FreeBSD.

Reported by:	Kurt Lidl <lidl@pix.net>
MFC r259083:

For WARNS <= 3, change the clang warning flag -Wno-conversion to
-Wno-enum-conversion.  In earlier clang versions (before 3.2), the
latter did not exist, and suppressing enum conversion warnings was
really the goal of this warning suppression flag.

This should enable the same kind of warning again as was fixed by
r259072 ("incompatible integer to pointer conversion passing 'Elf_Addr'
(aka 'unsigned int') to parameter of type 'void *'"), and which was only
emitted by gcc.

Noticed by:	kib
Merge r257754 (by adrian) from head:

  Don't return ENOBUFS if the transmit path handles the frame but queues
  it (eg in power save.)

10.0 candidate.

PR:		kern/183727
Merge r258758 (by adrian) from head:

  Make sure any waiters on the scan results get notified if the scan task
  decides to do nothing.

  If this isn't done, then a scan request whilst a scan occurs in an
  active channel set or a completed channel set will hang.

Candidate for 10.0.
Merge r256294 (by adrian) from head:

  Fix the "am I a net80211 vap" check for bpf listeners.

  I changed it to use if_transmit a while ago but apparently with monitor
  mode the if_transmit method is overridden.

  This is (mostly) a workaround until a more permanent solution can be
  found.

Candidate for 10.0.

Submitted by:	Patrick Kelsey <kelsey@ieee.org>
Merge r257065 (by adrian) from head:

  Fix a use-after-free node reference issue when waiting for a return
  from a management frame transmission.

  This bug is a bit loopy, so here goes.

  The underlying cause is pretty easy to understand - the node isn't
  referenced before passing into the callout, so if the node is deleted
  before the callout fires, it'll dereference free'd memory.

  The code path however is slightly more convoluted.

  The functions _say_ mgt_tx - ie management transmit - which is partially
  true.  Yes, that callback is attached to the mbuf for some management
  frames.  However, it's only for frames relating to scanning and
  authentication attempts.  It helpfully drives the VAP state back to
  "SCAN" if the transmission fails _OR_ (as I subsequently found out!)
  if the transmission succeeds but the state machine doesn't make progress
  towards being authenticated and active.

  Now, the code itself isn't terribly clear about this.

  It _looks_ like it's just handling the transmit failure case.

  However, when you look at what goes on in the transmit success case, it's
  moving the VAP state back to SCAN if it hasn't changed state since
  the time the callback was scheduled.  Ie, if it's in ASSOC or AUTH still,
  it'll go back to SCAN.  But if it has transitioned to the RUN state,
  the comparison will fail and it'll not transition things back to the
  SCAN state.

  So, to fix this, I decided to leave everything the way it is and merely
  fix the locking and remove the node reference.

  The _better_ fix would be to turn this callout into a "assoc/auth request"
  timeout callback and make the callout locked, thus eliminating all races.
  However, until all the drivers have been fixed so that transmit completions
  occur outside of any locking that's going on, it's going to be impossible
  to do this without introducing LORs.  So, I leave some of the evilness
  in there.

Candidate for 10.0.
MFC r257345,257382,257388:

Implement extended LUN support. If PIM_EXTLUNS is set by a SIM, encode
the upper 32-bits of the LUN, if possible, into the target_lun field as
passed directly from the REPORT LUNs response. This allows extended LUN
support to work for all LUNs with zeros in the lower 32-bits, which covers
most addressing modes without breaking KBI. Behavior for drivers not
setting PIM_EXTLUNS is unchanged. No user-facing interfaces are modified.

Extended LUNs are stored with swizzled 16-bit word order so that, for
devices implementing LUN addressing (like SCSI-2), the numerical
representation of the LUN is identical with and without PIM_EXTLUNS. Thus
setting PIM_EXTLUNS keeps most behavior, and user-facing LUN IDs, unchanged.
This follows the strategy used in Solaris. A macro (CAM_EXTLUN_BYTE_SWIZZLE)
is provided to transform a lun_id_t into a uint64_t ordered for the wire.

This is the second part of work for full 64-bit extended LUN support and is
designed to a bridge for stable/10 to the final 64-bit LUN code. The
third and final part will involve widening lun_id_t to 64 bits and will
not be MFCed. This third part will break the KBI but will keep the KPI
unchanged so that all drivers that will care about this can be updated now
and not require code changes between HEAD and stable/10.

Reviewed by:	scottl
MFC r258692 (gnn).

Add constants for use in interrogating various fiber and copper connectors
most often used with network interfaces.

The SFF-8472 standard defines the information that can be retrieved
from an optic or a copper cable plugged into a NIC, most often
referred to as SFP+.  Examples of values that can be read
include the cable vendor's name, part number, date of manufacture
as well as running data such as temperature, voltage and tx
and rx power.

Copious comments on how to use these values with an I2C interface
are given in the header file itself.

Discussed with:	gnn
MFC: r257598
During code inspection, I spotted that there was a code path where
CLNT_CONTROL() would be called on "client" after it was
released via CLNT_RELEASE(). It was unlikely that this
code path gets executed and I have not heard of any problem
report caused by this bug. This patch fixes the code so that
this cannot happen.
MFC r259100:

Pull in r196658 from upstream clang trunk:

  CodeGen: Don't emit linkage on thunks that aren't emitted because they're
  vararg.

  This can happen when we're trying to emit a thunk with available_externally
  linkage with optimization enabled but bail because it doesn't make sense for
  vararg functions.

  [LLVM] PR18098.

This should fix clang "Broken module found, compilation aborted" errors when
building the qt4-based dvbcut port.

Reported by:	se
MFC r259111:

Use correct casts in gcc's emmintrin.h for the first arguments of the
following builtin functions:

* __builtin_ia32_pslldi128() takes __v4si instead of __v8hi
* __builtin_ia32_psllqi128() takes __v2di instead of __v8hi
* __builtin_ia32_psradi128() takes __v4si instead of __v8hi

This should fix the following errors when building the LINT kernel with
gcc:

sys/crypto/aesni/aesni_wrap.c:191: error: incompatible type for argument 1 of
'__builtin_ia32_psradi128'
sys/crypto/aesni/aesni_wrap.c:195: error: incompatible type for argument 1 of
'__builtin_ia32_pslldi128'
MFC	r256448, r257029;

Make di_blocks unsigned in UFS1 as is the case already for UFS2.
 Most of the code between UFS1 and UFS2 is shared so this change
 is pretty safe. Not only this makes UFS1 and 2 consistent but it
 also matches what NetBSD and MacOS X have for some years now.

UFS2: make di_extsize unsigned.
 di_extsize is the EA size and as such it should be unsigned.
 Adjust related types for consistency.

Reviewed by:	mckusick
MFC r257805, r257806, r257807, r257942:

r257805:
  Add a 'mini-memstick.img' release target, which will use the
  'bootonly.iso' components to create a smaller memory stick image.

  This is useful for system recovery, where a full memstick.img image
  is not necessarily needed (or wanted).  In addition, it is possible
  to do bootonly-style installation, where the base.txz, kernel.txz,
  etc. are fetched from a remote source.

  Provide backwards-compatible target (mini-memstick), to keep in sync
  with the targets documented in release/Makefile.

r257806:
  Remove extra target from 'memstick' that I forgot to remove before
  previous commit.

r257807:
  Update release(7) to include 'mini-memstick'.

r257942:
  Fix a few style nits.

Sponsored by:	The FreeBSD Foundation
MFC	r258503

Limit the large page size to 16MB for now.
MFC	r258615

Take care to handle the full 16 byte buffer in the get/put routines. Also,
skip the VTERM header once when receiving data from the hypervisor call when
we have a HVTERMPROT connection.
MFC	r258778

Add a printf to inform about the logical memory block size which is in use
by the system. This might give a hint why a pSeries system is not booting.
MFC	r259007

Increase PHYS_AVAIL_SZ because on pSeries machines we can have many logical
regions which represent the total amount of memory. The size of these regions
is not the physical size of the chip but it is a logical one and it is given
by the OpenFirmware, it is selectable at boot time and varies between 16MB and
256MB in my case. There is an 'automatic' option which would select the size as
64MB in case you have around 16GB of RAM.
To make sure we can allocate RAM with the automatic option bump this value
of PHYS_AVAIL_SZ to 256.
MFC r259101:

drm/radeon: agp_info->ai_aperture_size is in bytes, not Mbytes

This fixes radeon_agp_init() and gtt_size is now correct. However, this
is not enough to make Radeon AGP cards work: ttm_agp_backend.c isn't
implemented yet.

Submitted by:	tijl@
MFC     r257991, r257992, 257993, 258504

r257991:
  Consolidate Apple firmware hacks and improve them by switching on the
  presence of mac-io devices in the tree, which uniquely identifies Apple
  hardware.

r257992:
  Allow OF_decode_addr() to also be able to map resources on big-endian
  devices. To this end, make PCI device detection rely on the device_type
  field rather than name, as per the standard.

r257993:

  Make tsec work with the device tree present on the RB800. The previous code
  assumed that the MDIO bus was a direct child of the Ethernet interface. It
  may not be and indeed on many device trees is not. While here, add proper
  locking for MII transactions, which may be on a bus shared by several MACs.

r258504:

  Save and restore the trap vectors when doing OF calls on pSeries machines.

  It turned out that on pSeries machines the call into OF modified the trap
  vectors and this made further behaviour unpredictable.

  With this commit I'm now able to boot multi user on a network booted
  environment on my IntelliStation 285. This is a POWER5+ machine.