MFC	r265202:
Remove some unreachable breaks in regex.

This is based on a much bigger cleanup done in Illumos.

Reference:
https://www.illumos.org/issues/2077
MFC	r265231:

gcc: fix strict alignment.

From the OpenBSD log:

x86-64 ABI requires arrays greater than 16 bytes to be aligned to
16byte boundary.  However, GCC 16-byte aligns arrays of >=16 BITS,
not BYTES.

This diff improves bug detectability for code which has local arrays
of [16 .. 127] bits:  in those cases SSP will now detect even 1-byte
overflows.

Obtained from:	OpenBSD (CVS rev 1.4)
MFC mpr(4) driver changes.

This includes r265386, r265424, and r265473.

  ------------------------------------------------------------------------
  r265386 | ken | 2014-05-05 13:53:03 -0600 (Mon, 05 May 2014) | 15 lines

  Adjust #if statements inside mprsas_send_smpcmd() to more accurately
  reflect when unmapped I/O support was added.

  For FreeBSD 10, it arrived just prior to __FreeBSD_version 1000028.
  For FreeBSD 9, it arrived just prior to __FreeBSD_version 902001.

  Also, fix compiler warnings in mprsas_send_smpcmd() that happen in the
  i386 PAE build for non-unmapped I/O builds.  These were fixed in mps(4)
  in revision 241145, but didn't make it into the mpr(4) driver.  This
  change should only affect FreeBSD versions outside the above revisions,
  and thus doesn't affect head.

  Sponsored by:	Spectra Logic Corporation

  ------------------------------------------------------------------------
  ------------------------------------------------------------------------
  r265424 | ken | 2014-05-06 00:18:43 -0600 (Tue, 06 May 2014) | 33 lines

  Fix a problem with async notifications in the mpr(4) driver.

  This problem only occurs on versions of FreeBSD prior to the recent CAM
  locking changes.  (i.e. stable/9 and older versions of stable/10)  This
  change should be a no-op for head and stable/10.

  If a path isn't specified, xpt_register_async() will create a fully
  wildcarded path and acquire a lock (the XPT lock in older versions,
  and via xpt_path_lock() in newer versions) to call xpt_action() for the
  XPT_SASYNC_CB CCB.  It will then drop the lock and if the requested event
  includes AC_FOUND_DEVICE or AC_PATH_REGISTERED, it will get the caller up
  to date with any device arrivals or path registrations.

  The issue is that before the locking changes, each SIM lock would get
  acquired in turn during the EDT tree traversal process.  If a path is
  specified for xpt_register_async(), it won't acquire and drop its own lock,
  but instead expects the caller to hold its own SIM lock.  That works for
  the first part of xpt_register_async(), but causes a recursive lock
  acquisition once the EDT traversal happens and it comes to the SIM in
  question.  And it isn't possible to call xpt_action() without holding a SIM
  lock.

  The locking changes fix this by using the XPT topology lock for EDT
  traversal, so it is no longer an issue to hold the SIM lock while calling
  xpt_register_async().

  The solution for FreeBSD versions before the locking changes is to request
  notification of all device arrivals (so we pass a NULL path into
  xpt_register_async()) and then filter out the arrivals that are not ours.

  Sponsored by:	Spectra Logic Corporation

  ------------------------------------------------------------------------
  ------------------------------------------------------------------------
  r265473 | ken | 2014-05-06 16:13:38 -0600 (Tue, 06 May 2014) | 7 lines

  Change the device name for mpr(4) from /dev/mpr_N to /dev/mprN.

  This is more consistent with the existing mps(4) behavior.

  Reviewed by:	Steve McConnell <stephen.mcconnell@avagotech.com>

  ------------------------------------------------------------------------

Sponsored by:	LSI, Spectra Logic
MFC r265732:
  Add 9.3 to mdoc.local

Sponsored by:	The FreeBSD Foundation
MFC r264669: MFV r264666:

4374 dn_free_ranges should use range_tree_t

illumos/illumos-gate@bf16b11e8deb633dd6c4296d46e92399d1582df4
MFC r264671 (MFV r264668):

4754 io issued to near-full luns even after setting noalloc threshold
4755 mg_alloc_failures is no longer needed

illumos/illumos@b6240e830b871f59c22a3918aebb3b36c872edba
MFC r264740:

Use case insensitive match in portsnap.

PR:		bin/186510
Submitted by:	olli
MFC r264835 (MFV r264829):

3897 zfs filesystem and snapshot limits
MFC r264836 (MFV r264830):

4745 fix AVL code misspellings
MFC r265458:
Import George Wilson's change for Illumos #4730:

	4730 metaslab group taskq should be destroyed in metaslab_group_destroy()
	Reviewed by: Alex Reece <alex.reece@delphix.com>
	Reviewed by: Matthew Ahrens <mahrens@delphix.com>
	Reviewed by: Sebastien Roy <sebastien.roy@delphix.com>

	Original author: George Wilson
MFC r265464:

Sort .ALLSRC before concatenating files together.  This makes sure that the
file are always built the same.

(Note that Header and Localstuff must appear first and in that order, the
sorting does not affect as a coincident effect).

Submitted by:	sjg
MFC: r265244

Free resources in an error case.

CID:		1018947
Found with:	Coverity Prevent(tm)
MFC r264194:

Fork a child process and wait until the process terminates when the -P
option is specified. This behavior is documented on the manual page.

PR:		bin/187265
MFC r265411
Modify Copyright information to reflect Qlogic Corporation's purchase
of Broadcom's NetXtreme business

Submitted by:David C Somayajulu (davidcs@freebsd.org) QLogic Corporation
MFC r252440:

    Enable the second and the third I2C controllers on Beaglebone-black.
Revert bogus change in 265804 to configparser.c
MFC r265275:
Overwrite the de_Name for the directories on rename to correct the dot
name.
Manually MFC 262714:
  Add a missing semicolong, noticed by the gnu dt compiler.

In head, the directory layout changed and we can't svn merge correctly.
MFC r259126:

Activate the device before attempt to access any of its registers.  Without
this change we may end up with a panic (Fatal kernel mode data abort:
'External Non-Linefetch Abort (S)') as described in
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/276862.aspx.

It is now possible to bring up I2C1 and I2C2 on BBB.
MFC: r265263

Make this manpage ready for hardware notes generation, add more Xrefs and perform
general cleanup.

In particular, don't claim rsu(4) devices can be configured with hostname(1)...