Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

MFC the mpr(4) driver for LSI's 12Gb SAS cards.

This includes r265236, r265237, r265241, r265261, r265386, r265424, and
r265473.

------------------------------------------------------------------------
r265236 | ken | 2014-05-02 14:25:09 -0600 (Fri, 02 May 2014) | 51 lines

Bring in the mpr(4) driver for LSI's MPT3 12Gb SAS controllers.

This is derived from the mps(4) driver, but it supports only the 12Gb
IT and IR hardware including the SAS 3004, SAS 3008 and SAS 3108.

Some notes about this driver:
o The 12Gb hardware can do "FastPath" I/O, and that capability is included in
this driver.

o WarpDrive functionality has been removed, since it isn't supported in
the 12Gb driver interface.

o The Scatter/Gather list handling code is significantly different between
the 6Gb and 12Gb hardware. The 12Gb boards support IEEE Scatter/Gather
lists.

Thanks to LSI for developing and testing this driver for FreeBSD.

share/man/man4/mpr.4:
mpr(4) man page.

sys/dev/mpr/*:
mpr(4) driver files.

sys/modules/Makefile,
sys/modules/mpr/Makefile:
Add a module Makefile for the mpr(4) driver.

sys/conf/files:
Add the mpr(4) driver.

sys/amd64/conf/GENERIC,
sys/i386/conf/GENERIC,
sys/mips/conf/OCTEON1,
sys/sparc64/conf/GENERIC:
Add the mpr(4) driver to all config files that currently
have the mps(4) driver.

sys/ia64/conf/GENERIC:
Add the mps(4) and mpr(4) drivers to the ia64 GENERIC
config file.

sys/i386/conf/XEN:
Exclude the mpr module from building here.

Submitted by: Steve McConnell <Stephen.McConnell@avagotech.com>
Tested by: Chris Reeves <chrisr@spectralogic.com>
Sponsored by: LSI, Spectra Logic
Relnotes: LSI 12Gb SAS driver mpr(4) added

------------------------------------------------------------------------
------------------------------------------------------------------------
r265237 | ken | 2014-05-02 14:36:20 -0600 (Fri, 02 May 2014) | 8 lines

Add the mpr(4) man page to the man4 Makefile.

This should have been included in r265236.

Submitted by: Steve McConnell <Stephen.McConnell@avagotech.com>
Sponsored by: LSI, Spectra Logic

------------------------------------------------------------------------
------------------------------------------------------------------------
r265241 | brueffer | 2014-05-02 15:14:28 -0600 (Fri, 02 May 2014) | 2 lines

Use our standard SYNOPSIS wording; perform some cleanup while here.

------------------------------------------------------------------------
------------------------------------------------------------------------
r265261 | brueffer | 2014-05-03 05:15:28 -0600 (Sat, 03 May 2014) | 2 lines

Add a missing colon.

------------------------------------------------------------------------
------------------------------------------------------------------------
r265386 | ken | 2014-05-05 13:53:03 -0600 (Mon, 05 May 2014) | 15 lines

Adjust #if statements inside mprsas_send_smpcmd() to more accurately
reflect when unmapped I/O support was added.

For FreeBSD 10, it arrived just prior to __FreeBSD_version 1000028.
For FreeBSD 9, it arrived just prior to __FreeBSD_version 902001.

Also, fix compiler warnings in mprsas_send_smpcmd() that happen in the
i386 PAE build for non-unmapped I/O builds. These were fixed in mps(4)
in revision 241145, but didn't make it into the mpr(4) driver. This
change should only affect FreeBSD versions outside the above revisions,
and thus doesn't affect head.

Sponsored by: Spectra Logic Corporation

------------------------------------------------------------------------
------------------------------------------------------------------------
r265424 | ken | 2014-05-06 00:18:43 -0600 (Tue, 06 May 2014) | 33 lines

Fix a problem with async notifications in the mpr(4) driver.

This problem only occurs on versions of FreeBSD prior to the recent CAM
locking changes. (i.e. stable/9 and older versions of stable/10) This
change should be a no-op for head and stable/10.

If a path isn't specified, xpt_register_async() will create a fully
wildcarded path and acquire a lock (the XPT lock in older versions,
and via xpt_path_lock() in newer versions) to call xpt_action() for the
XPT_SASYNC_CB CCB. It will then drop the lock and if the requested event
includes AC_FOUND_DEVICE or AC_PATH_REGISTERED, it will get the caller up
to date with any device arrivals or path registrations.

The issue is that before the locking changes, each SIM lock would get
acquired in turn during the EDT tree traversal process. If a path is
specified for xpt_register_async(), it won't acquire and drop its own lock,
but instead expects the caller to hold its own SIM lock. That works for
the first part of xpt_register_async(), but causes a recursive lock
acquisition once the EDT traversal happens and it comes to the SIM in
question. And it isn't possible to call xpt_action() without holding a SIM
lock.

The locking changes fix this by using the XPT topology lock for EDT
traversal, so it is no longer an issue to hold the SIM lock while calling
xpt_register_async().

The solution for FreeBSD versions before the locking changes is to request
notification of all device arrivals (so we pass a NULL path into
xpt_register_async()) and then filter out the arrivals that are not ours.

Sponsored by: Spectra Logic Corporation

------------------------------------------------------------------------
------------------------------------------------------------------------
r265473 | ken | 2014-05-06 16:13:38 -0600 (Tue, 06 May 2014) | 7 lines

Change the device name for mpr(4) from /dev/mpr_N to /dev/mprN.

This is more consistent with the existing mps(4) behavior.

Reviewed by: Steve McConnell <stephen.mcconnell@avagotech.com>

------------------------------------------------------------------------

Submitted by: Steve McConnell <Stephen.McConnell@avagotech.com>
Tested by: Chris Reeves <chrisr@spectralogic.com>
Sponsored by: LSI, Spectra Logic
Relnotes: LSI 12Gb SAS driver mpr(4) added

MFC: r228005

Change another instance of amd(4) to esp(4) missed in r227006 (MFC'ed to
stable/9 in r227305).

Submitted by: Garrett Cooper

Copy head to stable/9 as part of 9.0-RELEASE release cycle.

Approved by: re (implicit)

Fix a zyd(4) comment typo that was copy+pasted into most kernel config files.

PR: 160276
Submitted by: MATSUMIYA Ryo <matsumiya@mma.club.uec.ac.jp>
Approved by: re (kib)
MFC after: 1 week

Use new option names for NFS client and NFS server

See UPDATING entry for 20110427

- Add shim to simplify migration to the CAM-based ATA. For each new adaX
device in /dev/ create symbolic link with adY name, trying to mimic old ATA
numbering. Imitation is not complete, but should be enough in most cases to
mount file systems without touching /etc/fstab.
- To know what behavior to mimic, restore ATA_STATIC_ID option in cases
where it was present before.
- Add some more details to UPDATING.

Switch the GENERIC kernels for all architectures to the new CAM-based ATA
stack. It means that all legacy ATA drivers are disabled and replaced by
respective CAM drivers. If you are using ATA device names in /etc/fstab or
other places, make sure to update them respectively (adX -> adaY,
acdX -> cdY, afdX -> daY, astX -> saY, where 'Y's are the sequential
numbers for each type in order of detection, unless configured otherwise
with tunables, see cam(4)).

ataraid(4) functionality is now supported by the RAID GEOM class.
To use it you can load geom_raid kernel module and use graid(8) tool
for management. Instead of /dev/arX device names, use /dev/raid/rX.

Break out the ath PCI logic into a separate device/module.

Introduce the AHB glue for Atheros embedded systems. Right now it's
hard-coded for the AR9130 chip whose support isn't yet in this HAL;
it'll be added in a subsequent commit.

Kernel configuration files now need both 'ath' and 'ath_pci' devices; both
modules need to be loaded for the ath device to work.

For now remove options FLOWTABLE from the remaining GENERIC kernel
configurations and make it opt-in for those who want it. LINT will
still build it.

While it may be a perfect win in some scenarios, it still troubles users
(see PRs) in general cases. In addition we are still allocating resources
even if disabled by sysctl and still leak arp/nd6 entries in case of
interface destruction.

Discussed with: qingli (2010-11-24, just never executed)
Discussed with: juli (OCTEON1)
PR: kern/148018, kern/155604, kern/144917, kern/146792
MFC after: 2 weeks

Use simplified ldscripts rather than specific ones

Kill redundant cpu line

o) Expand the CIU driver to be aware of newly-allocated parts of the IRQ range.
o) Add 'octm', a trivial driver for the 10/100 management ports found on some
Octeon systems.
o) Make the Simple Executive's management port helper routines compile on
FreeBSD (namely by not doing math on void pointers.)
o) Add a cvmx_mgmt_port_sendm routine to the Simple Executive to send an mbuf
so there is only one copy in the transmit path, rather than having to first
copy the mbuf to an intermediate buffer and then copy that to the Simple
Executive's transmit ring.
o) Properly work out MII addresses of management ports on the Lanner MR-730.
XXX The MR-730 also needs some patches to the MII read/write routines, but
this is sufficient for now. Media detection will be fixed in the future
when I can spend more time reading the vendor-supplied patches.

Remove the 'machine mips' from DEFAULTS. Put the proper 'machine mips
mipsel' or 'machine mips mipseb' into the config file (with a few 64's
tossed in for good measure). This will let us build the proper
kernels with different worlds as part of make universe.

o) Make it possible to attach a PHY directly to an octe device rather than
using miibus, since for some devices that use multiple addresses on the bus,
going through miibus may be unclear, and for devices that are not standard
MII PHYs, miibus may throw a fit, necessitating complicated interfaces to
fake the interface that it expects during probe/attach.
o) Make the mv88e61xx SMI interface in octe attach a PHY directly and fix some
mistakes in the code that resulted from trying too hard to present a nice
interface to miibus.
o) Add a PHY driver for the mv88e61xx. If attached (it is optional in kernel
compiles so the default behavior of having a dumb switch is preserved) it
will place the switch in a VLAN-tagging mode such that each physical port
has a VLAN associated with it and interfaces for the VLANs can be created to
address or bridge between them.
XXX It would be nice for this to be part of a single module including the
SMI interface, and for it to fit into a generic switch configuration
framework and for it to use DSA rather than VLANs, but this is a start
and gives some sense of the parameters of such frameworks that are not
currently present in FreeBSD. In lieu of a switch configuration
interface, per-port media status and VLAN settings are in a sysctl tree.
XXX There may be some minor nits remaining in the handling of broadcast,
multicast and unknown destination traffic. It would also be nice to go
through and replace the few remaining magic numbers with macros at some
point in the future.
XXX This has only been tested with the MV88E6161, but it should work with
minimal or no modification on related switches, so support for probing
them was included.

Thanks to Pat Saavedra of TELoIP and Rafal Jaworowski of Semihalf for their
assistance in understanding the switch chipset.

Make the OCTEON1 configuration look like a normal GENERIC configuration. In
particular, add PCI and USB buses and most devices. Also move to using ULE,
adding INET6, turning on WITNESS by default, etc.

TARGET_64BIT isn't needed anymore, GC it (partial merge from tbemd).

Update the port of FreeBSD to Cavium Octeon to use the Cavium Simple Executive
library:
o) Increase inline unit / large function growth limits for MIPS to accommodate
the needs of the Simple Executive, which uses a shocking amount of inlining.
o) Remove TARGET_OCTEON and use CPU_CNMIPS to do things required by cnMIPS and
the Octeon SoC.
o) Add OCTEON_VENDOR_LANNER to use Lanner's allocation of vendor-specific
board numbers, specifically to support the MR320.
o) Add OCTEON_BOARD_CAPK_0100ND to hard-wire configuration for the CAPK-0100nd,
which improperly uses an evaluation board's board number and breaks board
detection at runtime. This board is sold by Portwell as the CAM-0100.
o) Add support for the RTC available on some Octeon boards.
o) Add support for the Octeon PCI bus. Note that rman_[sg]et_virtual for IO
ports can not work unless building for n64.
o) Clean up the CompactFlash driver to use Simple Executive macros and
structures where possible (it would be advisable to use the Simple Executive
API to set the PIO mode, too, but that is not done presently.) Also use
structures from FreeBSD's ATA layer rather than structures copied from
Linux.
o) Print available Octeon SoC features on boot.
o) Add support for the Octeon timecounter.
o) Use the Simple Executive's routines rather than local copies for doing reads
and writes to 64-bit addresses and use its macros for various device
addresses rather than using local copies.
o) Rename octeon_board_real to octeon_is_simulation to reduce differences with
Cavium-provided code originally written for Linux. Also make it use the
same simplified test that the Simple Executive and Linux both use rather
than our complex one.
o) Add support for the Octeon CIU, which is the main interrupt unit, as a bus
to use normal interrupt allocation and setup routines.
o) Use the Simple Executive's bootmem facility to allocate physical memory for
the kernel, rather than assuming we know which addresses we can steal.
NB: This may reduce the amount of RAM the kernel reports you as having if
you are leaving large temporary allocations made by U-Boot allocated
when starting FreeBSD.
o) Add a port of the Cavium-provided Ethernet driver for Linux. This changes
Ethernet interface naming from rgmxN to octeN. The new driver has vast
improvements over the old one, both in performance and functionality, but
does still have some features which have not been ported entirely and there
may be unimplemented code that can be hit in everyday use. I will make
every effort to correct those as they are reported.
o) Support loading the kernel on non-contiguous cores.
o) Add very conservative support for harvesting randomness from the Octeon
random number device.
o) Turn SMP on by default.
o) Clean up the style of the Octeon kernel configurations a little and make
them compile with -march=octeon.
o) Add support for the Lanner MR320 and the CAPK-0100nd to the Simple
Executive.
o) Modify the Simple Executive to build on FreeBSD and to build without
executive-config.h or cvmx-config.h. In the future we may want to
revert part of these changes and supply executive-config.h and
cvmx-config.h and access to the options contained in those files via
kernel configuration files.
o) Modify the Simple Executive USB routines to support getting and setting
of the USB PID.

Add bpf and random to Octeon configurations, since they're needed to run
dhclient and ssh respectively.

Reviewed by: imp

Get rid of unused options: KERNPHYSADDR, KERNVIRTADDR, PHYSADDR, PHYS_ADDR_64BIT

Discussed with: gonzo, imp

Adjust style (following the already existing rules) for the newly
introduced option DEADLKRES.

Reported by: danfe, julian, avg

Add the options DEADLKRES (introducing the deadlock resolver thread) in
the 'debugging' section of any HEAD kernel and enable for the mainstream
ones, excluding the embedded architectures.
It may, of course, enabled on a case-by-case basis.

Sponsored by: Sandvine Incorporated
Requested by: emaste
Discussed with: kib

Make a note that this file is the 64-bit version and experimental and
point people at the OCTEON1-32 file instead.

Set the svn:eol-style = native and svn:mime-type = text/plain
properties on all files in this tree.

Submitted by: rpaulo@

Using svn cp rather than cp to copy these files over had the benefit
of preserving their history. It had the problem that it also copied
over mergeinfo data. Since we're retiring the projects/mips branch,
I'm removing the svn:mergeinfo property from them all.

Submitted by: jhb

Cope with the octeon1->cavium move.

Merge from projects/mips to head by hand:

Copy over the OCTEON1 kernel config file. This is the 64-bit version.

Sync to r201658 on head.

Merge from head at r201628.

# This hasn't been tested, and there are at least three bad commits
# that need to be backed out before the branch will be stable again.

Include opt_cputype.h for all .c and .S files referencing TARGET_OCTEON.
Spell ld script name right.

# for the most part, we need to enhance infrastructure to obviate the need
# for such an intrusive option.

Get rid of redundant .kernel in these names.

MFC @199204

- MFC

- MFC from head@196987

Use new ldscript.mips.mips64
Also, declare this to be a 64-bit target.

We get to the final link now and die in the linker script..

- MFC @196061

Go for broke: configure this to build mips64 N64 binary.

- MFC

Kludge: pretend to be ISA_MIPS32 for the moment.

o Move the driveid.h file
o lots of tweaks to header paths.
o comment out SMP for the moment

# we now make it through the .c make depend, the .s needs more work.

Actually rename the files this time. Also, start to fix OCTEON1 so it
can configure.

Move the octeon port to its more correct location. Any port for the
OCTEON2 family of processors should live in mips/octeon2. Not enough
is know abotu the former to know if the same port can be used for both
yet.

Import Cavium's FreeBSD port, or the Octeon specific pieces, verbatim.
Yes, this puts things in the wrong place, doesn't compile and is
woefully incomplete. However, it will allow us to more easily track
against the upstream sources without needing to import the entire
Cavium tree under vendor.

This port is based on FreeBSD 7.0 as of April 2007 and the pre-import
MIPS tree (aka mips2), so much work is necessary here.