FreeBSD_HEAD_i386 - Build #2416 - Fixed

FreeBSD_HEAD_i386 - Build #2416 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2416/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2416/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2416/console

Change summaries:

295947 by erj:
ixl(4)/ixlv(4): Remove a couple unnecessary register writes/flushes.

The one in ixl_xmit() has brought up to us as being unnecessary at least a
couple times.

Differential Revision:	https://reviews.freebsd.org/D5208
Tested by:	jeffrey.e.pieper_at_intel.com
Sponsored by:	Intel Corporation

295946 by erj:
ixl(4): Fix potential driver interrupt setup issues and startup crash.

- Limit queue autoconfiguration to 8 queues to prevent the driver from
  requesting a large number of MSI-X vectors at boot.

- Fix potential kernel panic that occurs when the driver loads and cannot
  get all requested MSIX vectors. Instead, attach() will fail with an error.
  - Move taskqueue setup to later in attach() to prevent having to free
    taskqueues if some other error in attach() occurs.

Differential Revision:	 https://reviews.freebsd.org/D5205
MFC after:	1 month
Tested by:	jeffrey.e.pieper_at_intel.com
Sponsored by:	Intel Corporation

295945 by sobomax:
Obsolete mkulzma(8) and geom_uncompress(4), their functionality
is now provided by mkuzip(8) and geom_uzip(4) respectively.

MFC after:	1 month

295944 by jimharris:
nvme: fix intx handler to not dereference ioq during initialization

This was a regression from r293328, which deferred allocation
of the controller's ioq array until after interrupts are enabled
during boot.

PR:		207432
Reported and tested by: Andy Carrel <wac_at_google.com>
MFC after:	3 days
Sponsored by:	Intel

295943 by sobomax:
Improve mkuzip(8) and geom_uzip(4), merge in LZMA support from mkulzma(8)
and geom_uncompress(4):

1. mkuzip(8):

 - Proper support for eliminating all-zero blocks when compressing an
   image. This feature is already supported by the geom_uzip(4) module
   and CLOOP format in general, so it's just a matter of making mkuzip(8)
   match. It should be noted, however that this feature while it sounds
   great, results in very slight improvement in the overall compression
   ratio, since compressing default 16k all-zero block produces only 39
   bytes compressed output block, which is 99.8% compression ratio. With
   typical average compression ratio of amd64 binaries and data being
   around 60-70% the difference between 99.8% and 100.0% is not that
   great further diluted by the ratio of number of zero blocks in the
   uncompressed image to the overall number of blocks being less than
   0.5 (typically). However, this may be important from performance
   standpoint, so that kernel are not spinning its wheels decompressing
   those empty blocks every time this zero region is read. It could also
   be important when you create huge image mostly filled with zero
   blocks for testing purposes.

 - New feature allowing to de-duplicate output image. It turns out that
   if you twist CLOOP format a bit you can do that as well. And unlike
   zero-blocks elimination, this gives a noticeable improvement in the
   overall compression ratio, reducing output image by something like
   3-4% on my test UFS2 3GB image consisting of full FreeBSD base system
   plus some of the packages (openjdk, apache etc), about 2.3GB worth of
   file data (800+MB compressed). The only caveat is that images created
   with this feature "on" would not work on older versions of FeeBSDxi
   kernel, hence it's turned off by default.

 - provide options to control both features and document them in manual
   page.

 - merge in all relevant LZMA compression support from the mkulzma(8),
   add new option to select between both.

 - switch license from ad-hoc beerware into standard 2-clause BSD.

2. geom_uzip(4):

 - implement support for de-duplicated images;

 - optimize some code paths to handle "all-zero" blocks without reading
   any compressed data;

 - beef up manual page to explain that geom_uzip(4) is not limited only
   to md(4) images. The compressed data can be written to the block
   device and accessed directly via magic of GEOM(4) and devfs(4),
   including to mount root fs from a compressed drive.

 - convert debug log code from being compiled in conditionally into
   being present all the time and provide two sysctls to turn it on or
   off. Due to intended use of the module, it can be used in
   environments where there may not be a luxury to put new kernel with
   debug code enabled. Having those options handy allows debug issues
   without as much problem by just having access to serial console or
   network shell access to a box/appliance. The resulting additional
   CPU cycles are just few int comparisons and branches, and those are
   minuscule when compared to data decompression which is the main
   feature of the module.

 - hopefully improve robustness and resiliency of the geom_uzip(4) by
   performing some of the data validation / range checking on the TOC
   entries and rejecting to attach to an image if those checks fail.

 - merge in all relevant LZMA decompression support from the
   geom_uncompress(4), enable automatically when appropriate format is
   indicated in the header.

 - move compilation work into its own worker thread so that it does not
   clog g_up. This allows multiple instances work in parallel utilizing
   smp cores.

 - document new knobs in the manual page.

Reviewed by:		adrian
MFC after:		1 month
Differential Revision:	https://reviews.freebsd.org/D5333

295942 by jkim:
Silence PVS-Studio warning (V595).  It can never be NULL here.

295941 by bdrewery:
Fix build after r295934.