Commit Graph

14 Commits

Author SHA1 Message Date
Kenneth D. Merry
6c0541fa8e Add FreeBSD stable/10 version checks for the availability of the
CDAI_FLAG_NONE advanced information CCB flag.

Support for the flag was merged to stable/10 in r279329, and the
__FreeBSD_version in stable/10 was bumped to 1001510.

Check for that version in the mps(4) and mpr(4) drivers when determining
whether to use the flag.

Sponsored by:	Spectra Logic
MFC after:	3 days
2015-02-26 22:22:06 +00:00
Kenneth D. Merry
e8577fb489 Make sure that the flags for the XPT_DEV_ADVINFO CCB are initialized
properly.

If there is garbage in the flags field, it can sometimes include a
set CDAI_FLAG_STORE flag, which may cause either an error or
perhaps result in overwriting the field that was intended to be
read.

sys/cam/cam_ccb.h:
	Add a new flag to the XPT_DEV_ADVINFO CCB, CDAI_FLAG_NONE,
	that callers can use to set the flags field when no store
	is desired.

sys/cam/scsi/scsi_enc_ses.c:
	In ses_setphyspath_callback(), explicitly set the
	XPT_DEV_ADVINFO flags to CDAI_FLAG_NONE when fetching the
	physical path information.  Instead of ORing in the
	CDAI_FLAG_STORE flag when storing the physical path, set
	the flags field to CDAI_FLAG_STORE.

sys/cam/scsi/scsi_sa.c:
	Set the XPT_DEV_ADVINFO flags field to CDAI_FLAG_NONE when
	fetching extended inquiry information.

sys/cam/scsi/scsi_da.c:
	When storing extended READ CAPACITY information, set the
	XPT_DEV_ADVINFO flags field to CDAI_FLAG_STORE instead of
	ORing it into a field that isn't initialized.

sys/dev/mpr/mpr_sas.c,
sys/dev/mps/mps_sas.c:
	When fetching extended READ CAPACITY information, set the
	XPT_DEV_ADVINFO flags field to CDAI_FLAG_NONE instead of
	setting it to 0.

sbin/camcontrol/camcontrol.c:
	When fetching a device ID, set the XPT_DEV_ADVINFO flags
	field to CDAI_FLAG_NONE instead of 0.

sys/sys/param.h:
	Bump __FreeBSD_version to 1100061 for the new XPT_DEV_ADVINFO
	CCB flag, CDAI_FLAG_NONE.

Sponsored by:	Spectra Logic
MFC after:	1 week
2015-02-18 18:30:19 +00:00
Steven Hartland
85c9dd9d89 Prevent overflow issues in timeout processing
Previously, any timeout value for which (timeout * hz) will overflow the
signed integer, will give weird results, since callout(9) routines will
convert negative values of ticks to '1'. For unsigned integer overflow we
will get sufficiently smaller timeout values than expected.

Switch from callout_reset, which requires conversion to int based ticks
to callout_reset_sbt to avoid this.

Also correct isci to correctly resolve ccb timeout.

This was based on the original work done by Eygene Ryabinkin
<rea@freebsd.org> back in 5 Aug 2011 which used a macro to help avoid
the overlow.

Differential Revision:	https://reviews.freebsd.org/D1157
Reviewed by:	mav, davide
MFC after:	1 month
Sponsored by:	Multiplay
2014-11-21 21:01:24 +00:00
Hans Petter Selasky
f0188618f2 Fix multiple incorrect SYSCTL arguments in the kernel:
- Wrong integer type was specified.

- Wrong or missing "access" specifier. The "access" specifier
sometimes included the SYSCTL type, which it should not, except for
procedural SYSCTL nodes.

- Logical OR where binary OR was expected.

- Properly assert the "access" argument passed to all SYSCTL macros,
using the CTASSERT macro. This applies to both static- and dynamically
created SYSCTLs.

- Properly assert the the data type for both static and dynamic
SYSCTLs. In the case of static SYSCTLs we only assert that the data
pointed to by the SYSCTL data pointer has the correct size, hence
there is no easy way to assert types in the C language outside a
C-function.

- Rewrote some code which doesn't pass a constant "access" specifier
when creating dynamic SYSCTL nodes, which is now a requirement.

- Updated "EXAMPLES" section in SYSCTL manual page.

MFC after:	3 days
Sponsored by:	Mellanox Technologies
2014-10-21 07:31:21 +00:00
Alexander Motin
82315915e0 Properly report 12Gbps connection rate.
Reviewed by:	kadesai, slm
MFC after:	1 week
2014-10-08 16:22:26 +00:00
Alexander Motin
c2a0f07a10 Increase taskqueue thread priority from idle to PRIBIO.
Idle priority is not even time-share, so if system is busy in any way,
those events may never be executed.  Since in some cases system waits
for events processed by that thread, that may cause deadlocks.
2014-05-24 13:00:49 +00:00
Kenneth D. Merry
a371d6f964 Add #ifdefs in the mpr(4) driver so that versions of stable/9 that
have implemented the PIM_NOSCAN rescan functionality will have it
enabled.

This is a no-op for head.

Reviewed by:	slm
Sponsored by:	Spectra Logic Corporation
MFC after:	3 days
2014-05-08 20:46:46 +00:00
Kenneth D. Merry
d2b4e18b21 Fix TLR (Transport Layer Retry) support in the mps(4) and mpr(4) drivers.
TLR is necessary for reliable communication with SAS tape drives.

This was broken by change 246713 in the mps(4) driver.  It changed the
cm_data field for SCSI I/O requests to point to the CCB instead of the data
buffer.  So, instead, look at the CCB's data pointer to determine whether
or not we're talking to a tape drive.

Also, take the residual into account to make sure that we don't go off the
end of the request.

MFC after:	3 days
Sponsored by:	Spectra Logic Corporation
2014-05-08 20:28:22 +00:00
Kenneth D. Merry
63941e9834 Hold the SIM lock when calling xpt_create_path() and xpt_action() in
mprsas_SSU_to_SATA_devices().

This fixes an assertion on shutdown with INVARIANTS enabled with SATA
drives present on an IR firmware controller.

Reviewed by:	Steve McConnell <stephen.mcconnell@avagotech.com>.
MFC after:	3 days
2014-05-07 05:14:48 +00:00
Kenneth D. Merry
09e25c0e8a Remove some debugging code.
Submitted by:	Steve McConnell <stephen.mcconnell@avagotech.com>
MFC after:	3 days
2014-05-07 05:11:16 +00:00
Kenneth D. Merry
c0ba1535a4 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>
MFC after:	3 days
2014-05-06 22:13:38 +00:00
Kenneth D. Merry
07aa4de131 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.

MFC After:	3 days
Sponsored by:	Spectra Logic Corporation
2014-05-06 06:18:43 +00:00
Kenneth D. Merry
c503306dc6 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.

MFC after:	3 days
Sponsored by:	Spectra Logic Corporation
2014-05-05 19:53:03 +00:00
Kenneth D. Merry
991554f2c4 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@lsi.com>
MFC after:	3 days
Tested by:	Chris Reeves <chrisr@spectralogic.com>
Sponsored by:	LSI, Spectra Logic
Relnotes:	LSI 12Gb SAS driver mpr(4) added
2014-05-02 20:25:09 +00:00