#
259065 |
|
07-Dec-2013 |
gjb |
- Copy stable/10 (r259064) to releng/10.0 as part of the 10.0-RELEASE cycle. - Update __FreeBSD_version [1] - Set branch name to -RC1
[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so start releng/10.0 at '100' so the branch is started with a value ending in zero.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
256231 |
|
09-Oct-2013 |
jimharris |
Improve logging around some of the isci(4) reset and recovery paths.
Sponsored by: Intel Discussed with: scottl Approved by: re (marius) MFC after: 1 week
|
#
248778 |
|
26-Mar-2013 |
jimharris |
Panic should the SCI framework ever request a pointer into the ccb's data buffer for a ccb that is unmapped.
This case is currently not possible, since the SCI framework only requests these pointers for doing SCSI/ATA translation of non- READ/WRITE commands. The panic is more to protect against the unlikely future scenario where additional commands could be unmapped.
Sponsored by: Intel
|
#
248775 |
|
26-Mar-2013 |
jimharris |
Report support for unmapped I/O by adding PIM_UNMAPPED flag.
Submitted by: jhb, scottl
|
#
246713 |
|
12-Feb-2013 |
kib |
Reform the busdma API so that new types may be added without modifying every architecture's busdma_machdep.c. It is done by unifying the bus_dmamap_load_buffer() routines so that they may be called from MI code. The MD busdma is then given a chance to do any final processing in the complete() callback.
The cam changes unify the bus_dmamap_load* handling in cam drivers.
The arm and mips implementations are updated to track virtual addresses for sync(). Previously this was done in a type specific way. Now it is done in a generic way by recording the list of virtuals in the map.
Submitted by: jeff (sponsored by EMC/Isilon) Reviewed by: kan (previous version), scottl, mjacob (isp(4), no objections for target mode changes) Discussed with: ian (arm changes) Tested by: marius (sparc64), mips (jmallet), isci(4) on x86 (jharris), amd64 (Fabian Keil <freebsd-listen@fabiankeil.de>)
|
#
243904 |
|
05-Dec-2012 |
jimharris |
Don't call bus_dmamap_load in CAM_DIR_NONE case, since there is nothing to map, and technically this isn't allowed.
Functionally, it works OK (at least on x86) to call bus_dmamap_load with a NULL data pointer and zero length, so this is primarily for correctness and consistency with other drivers.
While here, remove check in isci_io_request_construct for nseg==0. Previously, bus_dmamap_load would pass nseg==1, even for case where buffer is NULL and length = 0, which allowed CAM_DIR_NONE CCBs to get processed. This check is not correct though, and needed to be removed both for the changes elsewhere in this patch, as well as jeff's preliminary bus_dmamap_load_ccb patch (which uncovered all of this in the first place).
MFC after: 3 days
|
#
235751 |
|
21-May-2012 |
jimharris |
Wait until completion context unwinds before retrying CCBs that have been queued internally. This works around issue in the isci HAL where it cannot accept new I/O to a device after a resetting->ready state transition until the completion context has unwound.
This issue was found by submitting non-tagged CCBs through pass(4) interface to a SATA disk with an extremely small timeout value (5ms). This would trigger internal resets with I/O in the isci(4) internal queues.
The small timeout value had not been intentional (and original reporter has since changed his test to use 5sec instead), but it did uncover this corner case that would result in a hung disk.
Sponsored by: Intel Reported and tested by: Ravi Pokala <rpokala at panasas dot com> Reviewed by: scottl (earlier version) MFC after: 1 week
|
#
234106 |
|
10-Apr-2012 |
jimharris |
Queue CCBs internally instead of using CAM_REQUEUE_REQ status. This fixes problem where userspace apps such as smartctl fail due to CAM_REQUEUE_REQ status getting returned when tagged commands are outstanding when smartctl sends its I/O using the pass(4) interface.
Sponsored by: Intel Found and tested by: Ravi Pokala <rpokala at panasas dot com> Reviewed by: scottl Approved by: scottl MFC after: 1 week
|
#
231296 |
|
09-Feb-2012 |
jimharris |
Remove explicit CC assignment in isci(4) Makefile to allow for building with clang. Also fix a number of warnings uncovered when building with clang around some implicit enum conversions.
Sponsored by: Intel Approved by: scottl
|
#
231136 |
|
07-Feb-2012 |
jimharris |
Fix r231134. svn:keywords needs to be 'FreeBSD=%H', not 'FreeBSD:%H'.
Approved by: scottl
|
#
231134 |
|
07-Feb-2012 |
jimharris |
Add svn:keywords for isci driver files.
Sponsored by: Intel Approved by: scottl
|
#
230843 |
|
31-Jan-2012 |
jimharris |
Add isci(4) driver for amd64 and i386 targets.
The isci driver is for the integrated SAS controller in the Intel C600 (Patsburg) chipset. Source files in sys/dev/isci directory are FreeBSD-specific, and sys/dev/isci/scil subdirectory contains an OS-agnostic library (SCIL) published by Intel to control the SAS controller. This library is used primarily as-is in this driver, with some post-processing to better integrate into the kernel build environment.
isci.4 and a README in the sys/dev/isci directory contain a few additional details.
This driver is only built for amd64 and i386 targets.
Sponsored by: Intel Reviewed by: scottl Approved by: scottl
|
#
230557 |
|
25-Jan-2012 |
jimharris |
Add all isci driver source code to sys/dev/isci for the Intel C600 (Patsburg) integrated SAS controller.
sys/dev/isci contains all files specific to FreeBSD. sys/dev/isci/scil contains OS-agnostic library maintained by Intel and modified to best integrate into FreeBSD kernel build environment.
Sponsored by: Intel Reviewed by: scottl
|