Fix final bugs in memory barriers on PowerPC:
- Use isync/lwsync unconditionally for acquire/release. Use of isync
  guarantees a complete memory barrier, which is important for serialization
  of bus space accesses with mutexes on multi-processor systems.
- Go back to using sync as the I/O memory barrier, which solves the same
  problem as above with respect to mutex release using lwsync, while not
  penalizing non-I/O operations like a return to sync on the atomic release
  operations would.
- Place an acquisition barrier around thread lock acquisition in
  cpu_switchin().
First fix pr 167226:
	ThunderBolt cannot read sector >= 2^32 or 2^21
with supplied patch.

Second the bigger change, fix RAID operation on ThunderBolt base
card such as physically removing a disk from a RAID and replacing
it.  The current situation is the RAID firmware effectively hangs
waiting for an acknowledgement from the driver.  This is due to
the firmware support of the driver actually accessing the RAID
from under the firmware.  This is an interesting feature that
the FreeBSD driver does not use.  However, when the firmare
detects the driver has attached it then expects the driver will
synchronize LD's with the firmware.  If the driver does not sync.
then the management part of the firmware will hang waiting for
it so a pulled driver will listed as still there.

The fix for this problem isn't extremely difficult.  However,
figuring out why some of the code was the way it was and then
redoing it was involved.  Not have a spec. made it harder to
try to figure out.  The existing driver would send a
MFI_DCMD_LD_MAP_GET_INFO command in write mode to acknowledge
a LD state change.  In read mode it gets the RAID map from the
firmware.  The FreeBSD driver doesn't do that currently.  It
could be added in the future with the appropriate structures.
To simplify things, get the current LD state and then build
the MFI_DCMD_LD_MAP_GET_INFO/write command so that it sends
an acknowledgement for each LD.  The map would probably state
which LD's changed so then the driver could probably just
acknowledge the LD's that changed versus all.  This doesn't seem
to be a problem.  When a MFI_DCMD_LD_MAP_GET_INFO/write command
is sent to the firmware, it will complete later when a change
to the LD's happen.  So it is very much like an AEN command
returning when something happened.  When the
MFI_DCMD_LD_MAP_GET_INFO/write command completes, we refire the
sync'ing of the LD state.  This needs to be done in as an event
so that MFI_DCMD_LD_GET_LIST can wait for that command to
complete before issuing the MFI_DCMD_LD_MAP_GET_INFO/write.
The prior code didn't use the call-back function and tried
to intercept the MFI_DCMD_LD_MAP_GET_INFO/write command when
processing an interrupt.  This added a bunch of code complexity
to the interrupt handler.  Using the call-back that is done
for other commands got rid of this need.  So the interrupt
handler is greatly simplified.  It seems that even commands
that shouldn't be acknowledged end up in the interrupt handler.
To deal with this, code was added to check to see if a command
is in the busy queue or not.  This might have contributed to the
interrupt storm happening without MSI enabled on these cards.

Note that MFI_DCMD_LD_MAP_GET_INFO/read returns right away.

It would be interesting to see what other complexity could
be removed from the ThunderBolt driver that really isn't
needed in our mode of operation.  Letting the RAID firmware
do all of the I/O to disks is a lot faster since it can
use its caches.  It greatly simplifies what the driver has
to do and potential bugs if the driver and firmware are
not in sync.

Simplify the aen_abort/cm_map_abort and put it in the softc
versus in the command structure.

This should get merged to 9 before the driver is merged to
8.

PR:		167226
Submitted by:	Petr Lampa
MFC after:	3 days