kernel - Performance tuning (4)

* Fix another bug in the new buf/bio code.  The flushing state can
  inadvertently become active and cause an endless loop due to a
  64-bit optimization (when BKVASIZE == MAXBSIZE) which is not properly
  conditionalized.

* Fix the endless loop.

* Add some debug variables and a sysctl to control it (temporary).
hammer2 - Stabilization

Yet more stabilization.  Generally speaking the code is starting to look
pretty good, but finding the corner cases for the in-memory chain state
has taken more time than I had hoped.  All of this complexity exists solely
in order to allow flushes to run concurrently with modifying operations by
the front-end (which is a pretty significant performance feature).

* Fix a bug in the hammer2_chain_get() race detection code.

* Refactor hammer2_freemap_alloc() a bit.

* Save debug info in dead block array fields (temporary), and add some
  debugging field to the chain structure.

* Refactor the flush code that checks whether a deleted chain should be
  ignored or not, fixing a bug at the same time.

* Refactor the transaction sequencing.  Flushes now allocate an extra
  transaction id so a distinction can be made between chains whos block
  arrays have not been updated and chains whos block arrays have been
  updated.

* Refactor the MOVED flag removal algorithm a little, fixing a bug or two.

* Adjust the freemap to detect forked chains and ensure that a different
  reserved block is calculated for the two possible forks.

* Fix a few mount fail cases that were panicing.

* Update bref.mirror_tid in scan1 skip cases.

* Do not update bref.mirror_tid in the skip case as this can confuse
  how a child's block array is interpreted in a future flush.

* Augment chain code with maxloops counters for debugging infinite
  loops.

* Remove the CHAIN_DUPLICATED tests in hammer2_chain_find() as this can
  catch a delete-duplicate in-progress and incorrectly cause the search
  to fail.

* Remove looping on CHAIN_DUPLICATED detection.  Instead what we do now
  is lock the chain before testing the CHAIN_DELETED bit.  Locking the
  chain will resolve delete-duplicate races and place the chain in a
  deterministic state.  The CHAIN_DELETED test is then sufficient.
Update the pciconf(8) database.

November 14, 2013 snapshot from http://pciids.sourceforge.net/