FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=stable%2F7 2013-07-03T23:24:53Z 2013-07-03T23:24:53Z Jim Harris jimharris@FreeBSD.org 2013-07-03T23:24:53Z urn:sha1:a560b12bed554c09bb048ac07a3d553832b27c33 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 2012-09-17T16:12:53Z Jim Harris jimharris@FreeBSD.org 2012-09-17T16:12:53Z urn:sha1:5236e9174d469853d22a3782a028321457ab9b97 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. 2012-09-04T17:15:19Z Jim Harris jimharris@FreeBSD.org 2012-09-04T17:15:19Z urn:sha1:f0294f40b84000b4d987ebe447996207fa1b30e5 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 2012-08-27T15:54:51Z Jim Harris jimharris@FreeBSD.org 2012-08-27T15:54:51Z urn:sha1:163a0fb28b344ceda2dfab5a05db06eb12dde74e 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 2012-05-16T00:01:39Z Jim Harris jimharris@FreeBSD.org 2012-05-16T00:01:39Z urn:sha1:43152fdcee47a43fb9ef551d1255067209247bad 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 2012-04-02T16:37:46Z Jim Harris jimharris@FreeBSD.org 2012-04-02T16:37:46Z urn:sha1:d9c15b180e40a5defa934fdc307f3e04f24e463b 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 2012-02-17T06:58:40Z Sean Bruno sbruno@FreeBSD.org 2012-02-17T06:58:40Z urn:sha1:d45e8a1a00467eb94148056f4aa52901513b629d r230843, 231134, 231136, 231296, 231615, 231693, 231860 Obtained from: Intel (Jim Harris jimharris@)