Allow a native i386 kernel to be built with 'nodevice atpic'.  Just as on
amd64, if 'device isa' is present quiesce the 8259A's during boot and
resume from suspend.

While here, be more selective on amd64 about which kernel configurations
need elcr.c.

MFC after:	2 weeks
Add casts to __uint16_t to the __bswap16() macros on all arches which
didn't already have them.  This is because the ternary expression will
return int, due to the Usual Arithmetic Conversions.  Such casts are not
needed for the 32 and 64 bit variants.

While here, add additional parentheses around the x86 variant, to
protect against unintended consequences.

MFC after:	2 weeks
Move i386's intr_machdep.c to the x86 tree and share it with amd64.
After r232745, which makes sure __bswap16(), ntohs() and htons() return
__uint16_t, we can partially undo r228668.

Note the remark "Work around a clang false positive with format string
warnings and ntohs macros (see LLVM PR 11313)" was actually incorrect.

Before r232745, on some arches, the ntohs() macros did in fact return
int, not uint16_t, so clang was right in warning about the %hu format
string.

MFC after:	2 weeks
Partially undo r228693, by removing NO_WFORMAT.clang in fsdb's Makefile,
and fixing the format string in sbin/fsdb/fsdbutil.c instead.

Note the remark "Work around a problem with format string warnings and
ntohs macros" was actually incorrect.  The DIP(dp, di_nlink) macro
invocation actually returned an int, due to its ternary expression, even
though the di_nlink members of struct ufs1_dinode and struct ufs2_dinode
are both defined as int16_t.

MFC after:	2 weeks
Perform the parameter validation before assigning it to a signed int
variable. This fixes the problem seen with readdir(3) fuzzing.

Submitted by:	bde
MFC after:	1 week
Export intrcnt correctly when running under 32-bit compatibility.

Reviewed by:	gonzo, nwhitehorn
Should the mcast queue be locked here? In case more multicast traffic
comes along?

This commit was brought to you via an Atheros AR5210, associated to an 3x3
HT40 11na access point.  Yes, this driver still works with it.
Document that we may end up with some suboptimal handling of data
frames with stations in power saving mode.

I'm not (yet) sure how to handle TX'ing aggregates frames to stations
that are in power saving mode, or whether that's even a feasible thing
to do. So in order to (mostly) not forget, leave a couple of comments
in the code.

The code presently assumes that the aggregation TID state for an ath_node
is locked not by the ath_node lock or a node+TID lock, but behind the
hardware queue said TID maps to.  This assumption is going to be
incorrect for stations in power saving mode as we'll be TX'ing frames
on the multicast queue.

In any case, I'm afraid its a "later problem". :/
Make boot2 build with Clang again.

Submitted by:	dim (bsd.sys.mk)
Reviewed by:	dim, jhb
Enforce that wtap requires VIMAGE to be useful.
Don't flood the cabq/mcastq with frames.

In a very noisy 2.4GHz environment (with HT/40 enabled, making it worse)
I saw the following occur:

* the air was considered "busy" a lot of the time;
* the cabq time is quite short due to staggered beacons being enabled;
* it just wasn't able to keep up TX'ing CABQ frames;
* .. and the cabq would swallow up all the TX ath_buf's.

This patch introduces a twiddle which allows the maximum cabq depth to be
set, forcing further frames to be dropped.

It defaults to the TX buffer count at the moment, so the default behaviour
isn't changed.

I've also started fleshing out a similar setup for the data path, so
it doesn't swallow up all the available TX buffers and preventing management
frames (such as ADDBA) out.

PR:		kern/165895
o) Bump INTRCOUNT_COUNT to 256, since Octeon already has >128.
   XXX It would be good to use a better way to size intrcnt.
o) Fix literal 4s that are supposed to be sizeof (u_long).
   XXX Why the * 2 here?  Is this an artifact of a different system that this
       code came from?  We seem to allocate twice as much space for intrcnt
       as we admit to in sintrcnt.
After r232403, DMA transactions does not cross 4GB boundary for
all PCI devices.  Remove driver workaround for 4GB boundary issue.
Reduce diffs with freebsd32_sysarch.
Don't truncate physical addresses to 32-bits.
Get rid of mainbus.c.  The version in nexus.c is being used and is
perfectly-sufficient and equally-crufty.
o) Remove some CPU_CNMIPS-related magical thinking about the status register's
   contents for user programs.
o) Conditionalize the installation of an XTLB handler on ABI, not CPU family.
Use ABI to determine bus_addr_t for cnMIPS.
Add brackets around bare '-1' used as the macro body.

Noted by:	bde
MFC after:	1 week