| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For ATA_PASSTHROUGH commands, pretend isci(4) supports multiword DMA
by treating it as UDMA.
This fixes a problem introduced in r249933/r249939, where CAM sends
ATA_DSM_TRIM to SATA devices using ATA_PASSTHROUGH_16. scsi_ata_trim()
sets protocol as DMA (not UDMA) which is for multi-word DMA, even
though no such mode is selected for the device. isci(4) would fail
these commands which is the correct behavior but not consistent with
other HBAs, namely LSI's.
smh@ did some further testing on an LSI controller, which rejected
ATA_PASSTHROUGH_16 commands with mode=UDMA_OUT, even though only
a UDMA mode was selected on the device. So this precludes adding
any kind of mode detection in CAM to determine which mode to use on
a per-device basis.
Note: The reasons behind this change do not apply to stable/7. This MFC
is to keep the driver consistent across stable branches and current.
Sponsored by: Intel
Notes:
svn path=/stable/7/; revision=252647
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
Notes:
svn path=/stable/7/; revision=244130
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isci(4): Fix SCSI/ATA translation for SCSI_WRITE_BUFFER w/ mode==0x7
(download microcode with offsets, save, and activate).
SATI translation layer was incorrectly using allocation length instead
of blocks, and was constructing the ATA command incorrectly.
Also change #define to specify that the 512 block size here is
specific for DOWNLOAD_MICROCODE, and does not relate to the device's
logical block size.
Notes:
svn path=/stable/7/; revision=240613
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not call sati_check_data_io() for SATI_UNMAP sequences.
This routine is intended only for commands such as INQUIRY where
the controller may fill out a smaller amount of data than allocated
by the host.
The end result of this bug was that isci(4) would report non-zero
resid for successful SCSI_UNMAP commands.
Sponsored by: Intel
Notes:
svn path=/stable/7/; revision=240092
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix/add support for SCSI UNMAP to ATA DSM translation.
(Note: scsi_da does not support BIO_DELETE->SCSI_UNMAP on this
stable branch, but I am MFC'ing the changes to keep a
consistent driver across all stable releases.)
This addresses kernel panic observed when sending SCSI UNMAP
commands to SATA disks attached to isci(4).
1) Flesh out callback routines to allocate/free buffers needed for
translating SCSI UNMAP data to ATA DSM data.
2) Add controller-level pool for storing buffers previously allocated
for UNMAP translation, to lessen chance of no buffer available
under memory pressure.
3) Ensure driver properly handles case where buffer pool is empty
and contigmalloc returns NULL.
4) Clear freeze bit in isci_remote_device_release_lun_queue() before
calling xpt_release_devq to ensure that any ccbs which immediately
start during the call to xpt_release_devq() see an accurate picture
of the frozen_lun_mask. This code path is extensively exercised
when tagged read/write commands mix with non-tagged DSM commands.
Sponsored by: Intel
Notes:
svn path=/stable/7/; revision=239736
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
Notes:
svn path=/stable/7/; revision=236265
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix off-by-one error in sati_inquiry_block_device_translate_data(). Bug would
result in INQUIRY VPD 0x81 to SATA devices to return only 63 bytes of data
instead of 64 during SCSI/ATA translation.
Sponsored by: Intel
Notes:
svn path=/stable/7/; revision=235492
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix bug where isci(4) would report only 15 bytes of returned data on a
READ_CAP_16 command to a SATA target.
Sponsored by: Intel
Approved by: sbruno
Notes:
svn path=/stable/7/; revision=233790
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Ensure consistent target IDs for direct-attached devices.
Sponsored by: Intel
Reported by: sbruno, Ravi Pokala <rpokala at panasas dot com>
Tested by: Ravi Pokala <rpokala at panasas dot com>
Approved by: sbruno
Notes:
svn path=/stable/7/; revision=233786
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Call xpt_bus_register during attach context, then freeze and do not release
until domain discovery is complete. This fixes an isci(4) bug on FreeBSD 7.x
where devices weren't always appearing after boot without an explicit rescan.
Sponsored by: Intel
Reported and tested by: <rpokala at panasas dot com>
Reviewed by: scottl
Approved by: scottl
Notes:
svn path=/stable/7/; revision=233375
|
| |
|
|
|
|
|
|
|
| |
Update PCI-IDs with devices found on Intel SDP
Return BUS_PROBE_DEFAULT so that non-default drivers may be loaded
Notes:
svn path=/stable/7/; revision=232369
|
|
|
r230843, 231134, 231136, 231296, 231615, 231693, 231860
Obtained from: Intel (Jim Harris jimharris@)
Notes:
svn path=/stable/7/; revision=231861
|
