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
- 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
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.
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
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
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
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
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
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
