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 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 r252857,255718:

Refresh vendor driver version which fixes command queue
full issue with ARC-1214 and ARC-1224.

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>