MFC: r255866, r255867

  fix a bug where we access a bread buffer after we have brelse'd it...
  The kernel normally didn't unmap/context switch away before we accessed
  the buffer most of the time, but under heavy I/O pressure and lots of
  mount/unmounting this would cause a fault on nofault panic...

  NULL stale pointers (should be a no-op as they should no longer be
  used)...
MFC r255648:

Fix a typo when accounting for tx_broadcast statistics.

Submitted by:	Paul A. Patience <paul-a patience polymtl ca>
MFC r255768:
Stability fixes for Intel LynxPoint XHCI controllers. Disable XHCI port
routing if we get certain errors. Poll for command completion upon
command timeouts. The XHCI error events might not generate interrupts.

PR:		usb/181159
MFC r255712:
 Remove extra 'MAKE_FLAGS' line.
MFC r255928:
 Use the correct EtherType for logging IPv6 packets.
MFC r255614,255639:
Fix bug in busdma: if segs is a preexisting buffer, we memcpy it
into the DMA map. The length of the buffer had not yet been
initialized, however, so this would copy gibberish unless it
happened to be right by chance. This bug mostly only affected
systems with IOMMUs.
MFC revisions 255908, 255925, and 255925:

SVN r255908:
Fix a bug in HTTP checking/fetching. Add Main Site to HTTP menu. Add new
example script browse_packages_http.sh and move existing example script
browse_packages.sh -> browse_packages_ftp.sh

SVN r255925:
Remove the is (Iceland) mirror per mail from the admins.

SVN r255925:
Remove ftp5.se.f.o, as per request to -hubs@
MFC 236768,252209,253047:
Several improvements to rmlock(9).  Many of these are based on patches
provided by Isilon.
- Add an rm_assert() supporting various lock assertions similar to other
  locking primitives.  Because rmlocks track readers the assertions are
  always fully accurate unlike rw_assert() and sx_assert().
- Flesh out the lock class methods for rmlocks to support sleeping via
  condvars and rm_sleep() (but only while holding write locks), rmlock
  details in 'show lock' in DDB, and the lc_owner method used by
  dtrace.
- Add an internal destroyed cookie so that API functions can assert
  that an rmlock is not destroyed.
- Make use of rm_assert() to add various assertions to the API (e.g.
  to assert locks are held when an unlock routine is called).
- Give RM_SLEEPABLE locks their own lock class and always use the
  rmlock's own lock_object with WITNESS.
- Various updates to the manpage.
MFC	r250574, r250812, r253725;

DTrace: option for time-ordered output

Merge changes from illumos:

3021 option for time-ordered output from dtrace(1M)
3022 DTrace: keys should not affect the sort order when sorting by value
3023 it should be possible to dereference dynamic variables
3024 D integer narrowing needs some work
3025 register leak in D code generation

This brings yet another feature implemented in upstream DTrace.
A complete description is available here:
http://dtrace.org/blogs/ahl/2012/07/28/my-new-dtrace-favorite/

This change bumps the DT_VERS_* number to 1.9.1 in
accordance to what is done in illumos.

Special thanks to Mark Johnston for fixes and testing.

Illumos Revisions:	13758:23432da34147

Reference:
https://www.illumos.org/issues/3021
https://www.illumos.org/issues/3022
https://www.illumos.org/issues/3023
https://www.illumos.org/issues/3024
https://www.illumos.org/issues/3025
https://www.illumos.org/issues/1694

Obtained from:	Illumos
MFC r255878:
  Now that the portsnap buildbox is generating the raw bits for INDEX-10,
  add it to the set of INDEX files built by portsnap.
MFC	r249426;

Merge change from illumos:

3519 DTrace fails to resolve const types from fbt
3520 dtrace internal error -- token type 316 is not a valid D
     compilation token
3521 clean up dtrace unit tests

Illumos Revision:	e98f46c

Reference:
https://www.illumos.org/issues/3519
https://www.illumos.org/issues/3520
https://www.illumos.org/issues/3521

Tested by:	Fabian Keil
Obtained from:	Illumos
MFC 233422,233680,233681,237619,239904,249373,252346,252379,252423:
Sync locking(9) with HEAD.  The only change not merged is that 9 still
supports !MPSAFE filesystems.
MFC	r254941;

Merge a couple of CTF fixes from illumos:

2942 CTF tools need to handle files which legitimately lack data
2978 ctfconvert still needs to ignore legitimately dataless files on SPARC

Illumos Revisions:	13745:6b3106b4250f
			13754:7231b684c18b

Reference:

https://www.illumos.org/issues/2942
https://www.illumos.org/issues/2978

Obtained from:	Illumos
MFC r255880:
Acquire a hold reference on the vnode when a knote is instantiated.
MFC r250198 (edwin, 2013-05-03):
On 30 April 2013 queen Beatrix resigned and crownprince Willem
Alexander became the new king. King's day is on 27 April.

MFC r255956 (rene, 2013-09-30):
Update the Dutch calendar entries:
- prince Johan Friso passed away in 2013
- correct status of queen Maxima and crown princess Catharina-Amalia
- language fixes

Approved by:	gjb (mentor)
MFC r255521, r255526, r255707:

r255521 (jmg):

add support for writing the pid of the daemon program to a pid file so
that daemon can be used w/ rc.subr and ports can use the additional
functionality, such as keeping the ldap daemon up and running, and have
the proper program to signal to exit..

PR:		bin/181341
Submitted by:	feld

r255526 (joel):

mdoc: remove EOL whitespace.

r255707:

1. Properly clean pid files in the case of the error.
2. Write the supervisor pid before the restart loop, so we don't
   uselessly rewrite it after every child restart.
3. Remove duplicate ppfh and pfh initialization.
MFC r255714, r255716, r255717:

r255714:

Use cv_broadcast() instead of cv_signal() when waking up threads
waiting on an empty queue as the queue may have several consumers.

Before the fix the following scenario was possible: 2 threads are
waiting on empty queue, 2 threads are inserting simultaneously. The
first inserting thread detects that the queue is empty and is going to
send the signal, but before it sends the second thread inserts
too. When the first sends the signal only one of the waiting threads
receive it while the other one may wait forever.

The scenario above is is believed to be the cause of the observed
cases, when ggate_recv_thread() was getting stuck on taking free
request, while the free queue was not empty.

Reviewed by:	pjd
Tested by:	Yamagi Burmeister yamagi.org

r255716:

When updating the map of dirty extents, most recently used extents are
kept dirty to reduce the number of on-disk metadata updates. The
sequence of operations is:

1) acquire the activemap lock;
2) update in-memory map;
3) if the list of keepdirty extents is changed, update on-disk metadata;
4) release the lock.

On-disk updates are not frequent in comparison with in-memory updates,
while require much more time. So situations are possible when one
thread is updating on-disk metadata and another one is waiting for the
activemap lock just to update the in-memory map.

Improve this by introducing additional, on-disk map lock: when
in-memory map is updated and it is detected that the on-disk map needs
update too, the on-disk map lock is acquired and the on-memory lock is
released before flushing the map.

Reported by:	Yamagi Burmeister yamagi.org
Tested by:	Yamagi Burmeister yamagi.org
Reviewed by:	pjd

r255717:

Fix comments.
MFC r255718:

Update arcmsr(4) driver to 1.20.00.28 which fixes mutex recursion in
CCB abort codepath.

Many thanks to Areca for continuing to support FreeBSD.

Submitted by:	黃清隆 <ching2048 areca com tw>
MFC r254134:

Add -c flag to pgrep(1) and pkill(1), to match login classes.
MFC r255978:

Pull in r191711 from upstream llvm trunk:

  The X86FixupLEAs pass for Intel Atom must not call
  convertToThreeAddress on ADD16rr opcodes, if src1 != src, since that
  would cause convertToThreeAddress to try to create a virtual register.
  This is not permitted after register allocation, which is when the
  X86FixupLEAs pass runs.

  This patch fixes PR16785.

Pull in r191715 from upstream llvm trunk:

  Forgot to add a break statement.

This should enable building the x11-toolskits/libXaw port with
CPUTYPE=atom.

Reported by:	Kenta Suzumoto <kentas@hush.com>