From owner-freebsd-scsi@FreeBSD.ORG Mon Dec 19 11:07:14 2011 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25F6B1065672 for ; Mon, 19 Dec 2011 11:07:14 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0A5B88FC16 for ; Mon, 19 Dec 2011 11:07:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBJB7Dpt011059 for ; Mon, 19 Dec 2011 11:07:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBJB7Dow011057 for freebsd-scsi@FreeBSD.org; Mon, 19 Dec 2011 11:07:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Dec 2011 11:07:13 GMT Message-Id: <201112191107.pBJB7Dow011057@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 11:07:14 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/163130 scsi [mpt] cannot dumpon to mpt connected disk o kern/162256 scsi [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0' o kern/161809 scsi [cam] [patch] set kern.cam.boot_delay via build option o kern/159412 scsi [ciss] 7.3 RELEASE: ciss0 ADAPTER HEARTBEAT FAILED err o kern/157770 scsi [iscsi] [panic] iscsi_initiator panic o kern/154432 scsi [xpt] run_interrupt_driven_hooks: still waiting after o kern/153514 scsi [cam] [panic] CAM related panic o kern/153361 scsi [ciss] Smart Array 5300 boot/detect drive problem o kern/152250 scsi [ciss] [patch] Kernel panic when hw.ciss.expose_hidden o kern/151564 scsi [ciss] ciss(4) should increase CISS_MAX_LOGICAL to 10 o docs/151336 scsi Missing documentation of scsi_ and ata_ functions in c s kern/149927 scsi [cam] hard drive not stopped before removing power dur o kern/148083 scsi [aac] Strange device reporting o kern/147704 scsi [mpt] sys/dev/mpt: new chip revision, partially unsupp o kern/146287 scsi [ciss] ciss(4) cannot see more than one SmartArray con o kern/145768 scsi [mpt] can't perform I/O on SAS based SAN disk in freeb o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/144301 scsi [ciss] [hang] HP proliant server locks when using ciss o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/127717 scsi [ata] [patch] [request] - support write cache toggling o kern/123674 scsi [ahc] ahc driver dumping o kern/123520 scsi [ahd] unable to boot from net while using ahd o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o bin/57088 scsi [cam] [patch] for a possible fd leak in libcam.c o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 49 problems total. From owner-freebsd-scsi@FreeBSD.ORG Wed Dec 21 05:53:28 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBB3C106564A for ; Wed, 21 Dec 2011 05:53:28 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 621808FC13 for ; Wed, 21 Dec 2011 05:53:28 +0000 (UTC) Received: by eekc50 with SMTP id c50so8529112eek.13 for ; Tue, 20 Dec 2011 21:53:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=2MZkV/LWp2jrTIK3S0kCzCLST5L6CfPC8eqyCDhauTo=; b=txoHC5Rs+FSxjgYrAmiVcSDNf2i1zbbw6SV+1+wKjaAP0cInAVKEDa3dsW3shOKcTo GqJ7PIka6UqgvcNcQhWEEnBkxCup4maRxcuw9DwsGTcLttRD1oZda8x8h88UbIQVRhJX 06u7QzaYL7k8NzwMDvMLtwmgr/HYhFcz7P/Wo= Received: by 10.14.32.145 with SMTP id o17mr2125653eea.52.1324446807407; Tue, 20 Dec 2011 21:53:27 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id z43sm16500759eef.7.2011.12.20.21.53.25 (version=SSLv3 cipher=OTHER); Tue, 20 Dec 2011 21:53:26 -0800 (PST) Sender: Alexander Motin Message-ID: <4EF1744A.9070703@FreeBSD.org> Date: Wed, 21 Dec 2011 07:53:14 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-scsi Content-Type: multipart/mixed; boundary="------------080900040203040002060006" Subject: Reading audio CD X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 05:53:29 -0000 This is a multi-part message in MIME format. --------------080900040203040002060006 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hi. Comparing cd and acd drivers I've found that acd driver handles reading of full 2352 bytes audio sectors via READ CD command, while cd driver doesn't. In particular that causes error messages about wrong access mode during boot/taste if audio CD inserted. Experimenting with it I've made a small patch for the cd driver (attached) to allow reading 2352 bytes sectors. As positive result those errors gone now. But looking for some real consumer of this I've found that at least both cdparanoia and libcdio are working with device directly with SCSI commands not using kernel drivers. So the question is: are there applications that reading audio cd via /dev/cdX device as previously they could do via /dev/acdX? Is this functionality used/needed? -- Alexander Motin --------------080900040203040002060006 Content-Type: text/plain; name="cdda.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cdda.patch" Index: scsi/scsi_all.h =================================================================== --- scsi/scsi_all.h (revision 228743) +++ scsi/scsi_all.h (working copy) @@ -932,6 +932,7 @@ #define WRITE_12 0xAA #define WRITE_VERIFY_12 0xAE #define READ_ELEMENT_STATUS 0xB8 +#define READ_CD 0xBE /* Maintenance In Service Action Codes */ #define REPORT_IDENTIFYING_INFRMATION 0x05 Index: scsi/scsi_cd.c =================================================================== --- scsi/scsi_cd.c (revision 228743) +++ scsi/scsi_cd.c (working copy) @@ -1483,6 +1483,11 @@ /* dxfer_len */ bp->bio_bcount, /* sense_len */ SSD_FULL_SIZE, /* timeout */ 30000); + /* Use READ CD command for audio tracks. */ + if (softc->params.blksize == 2352) { + start_ccb->csio.cdb_io.cdb_bytes[0] = READ_CD; + start_ccb->csio.cdb_io.cdb_bytes[9] = 0xf8; + } start_ccb->ccb_h.ccb_state = CD_CCB_BUFFER_IO; @@ -2880,6 +2885,13 @@ softc->flags |= CD_FLAG_VALID_TOC; + /* If the first track is audio, correct sector size. */ + if ((softc->toc.entries[0].control & 4) == 0) { + softc->disk->d_sectorsize = softc->params.blksize = 2352; + softc->disk->d_mediasize = + (off_t)softc->params.blksize * softc->params.disksize; + } + bailout: /* --------------080900040203040002060006-- From owner-freebsd-scsi@FreeBSD.ORG Wed Dec 21 15:04:11 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72D90106566C for ; Wed, 21 Dec 2011 15:04:11 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 245E08FC14 for ; Wed, 21 Dec 2011 15:04:10 +0000 (UTC) Received: from localhost.localdomain (c-76-126-166-136.hsd1.ca.comcast.net [76.126.166.136]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id pBLF407c035191 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 21 Dec 2011 07:04:10 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4EF1F4EB.2050905@feral.com> Date: Wed, 21 Dec 2011 07:02:03 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4EF1744A.9070703@FreeBSD.org> In-Reply-To: <4EF1744A.9070703@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Wed, 21 Dec 2011 07:04:10 -0800 (PST) Subject: Re: Reading audio CD X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 15:04:11 -0000 On 12/20/11 21:53, Alexander Motin wrote: > H > > So the question is: are there applications that reading audio cd via > /dev/cdX device as previously they could do via /dev/acdX? Is this > functionality used/needed? It doesn't matter, really. The patches are so small that you might as well just put them in. From owner-freebsd-scsi@FreeBSD.ORG Sat Dec 24 14:27:05 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79D93106566B for ; Sat, 24 Dec 2011 14:27:05 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id D2DD38FC12 for ; Sat, 24 Dec 2011 14:27:04 +0000 (UTC) Received: by eekc50 with SMTP id c50so11854042eek.13 for ; Sat, 24 Dec 2011 06:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=2E4ZSRME6EpjjgJppQRSrPEcItdFeBXlp55WITAgLJ8=; b=gncboF6w210tSFIiZY/26df4IolCBG72lVupnTjlifQAg31idVSual+hMSUBG6BOIw MnfbkfNbTs8RoGpMAoL3/HIrQmMA9UCxrR4BFTeGZd56gQ81lyehprUecrvYwu2uccLG BAYPHSoDUnKjDZc1E8DLm1cd9PTJkwUSsev38= Received: by 10.213.17.146 with SMTP id s18mr6695895eba.109.1324736823528; Sat, 24 Dec 2011 06:27:03 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id b49sm32495505eec.9.2011.12.24.06.27.02 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Dec 2011 06:27:02 -0800 (PST) Sender: Alexander Motin Message-ID: <4EF5E134.9040903@FreeBSD.org> Date: Sat, 24 Dec 2011 16:27:00 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111123 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: RFC: SCSI UNMAP (TRIM) support X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 14:27:05 -0000 Hi. I've implemented patch for logical block provisioning (aka UNMAP, TRIM, BIO_DELETE) support for the CAM da driver in HEAD and would like to ask for review, testing and hardware support information. Depending on device capabilities I use several different methods to implement it. Method can be read/set via kern.cam.da.X.delete_method sysctls. Possible values are: NONE - no provisioning support reported by the device; DISABLE - provisioning support was disabled because of errors; ZERO - use WRITE SAME (10) command to write zeroes; WS10 - use WRITE SAME (10) command with UNMAP bit set; WS16 - use WRITE SAME (16) command with UNMAP bit set; UNMAP - use UNMAP command. Last two methods (UNMAP and WS16) are defined by SBC specification and UNMAP method is the most advanced one. The rest of methods I've found supported in Linux, and as soon as they were trivial to implement, then why not? Hope they will be useful in some cases. Unluckily at this moment I have no devices reporting parameters of the logical block provisioning support via respective VPD pages (0xB0 and 0xB2). So all info I have/use now is the flag telling whether logical block provisioning is supported or not. As result specific methods chosen now by trying different ones in order (UNMAP, WS16, DISABLE) and checking completion status to fallback if needed. I don't expect problems from this, as if something go wrong, it should just disable itself. It may disable even too aggressively. Unlike Linux, which executes each delete with separate request, I've implemented here the same request aggregation as implemented in ada driver. Tests on SSDs I have show much better results doing it this way: above 8GB/s of the linear delete on Intel SATA SSD on LSI SAS HBA (mps). The patch can be found here: http://people.freebsd.org/~mav/scsi_unmap.patch Work sponsored by iXsystems, Inc. If somebody has SAS SSDs with UNMAP support, I would be grateful for additional information about them, such as: camcontrol cmd da0 -c "12 01 00 00 ff 00" -i 255 - >pages camcontrol cmd da0 -c "12 01 b0 00 ff 00" -i 255 - >page_b0 camcontrol cmd da0 -c "12 01 b2 00 ff 00" -i 255 - >page_b2 camcontrol cmd da0 -c "9e 10 00 00 00 00 00 00 00 00 00 00 00 ff 00 00" -i 255 - >rc16 Thank you! -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Sat Dec 24 17:35:02 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF9F0106564A; Sat, 24 Dec 2011 17:35:01 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6858FC0A; Sat, 24 Dec 2011 17:35:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id DA6B42041B4; Sat, 24 Dec 2011 18:17:34 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPKY7HZvpYXq; Sat, 24 Dec 2011 18:17:29 +0100 (CET) Received: from [192.168.48.66] (unknown [216.99.50.73]) by smtp.infotech.no (Postfix) with ESMTPA id 3D507204189; Sat, 24 Dec 2011 18:17:27 +0100 (CET) Message-ID: <4EF60926.7030204@interlog.com> Date: Sat, 24 Dec 2011 12:17:26 -0500 From: Douglas Gilbert User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Motin References: <4EF5E134.9040903@FreeBSD.org> In-Reply-To: <4EF5E134.9040903@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: RFC: SCSI UNMAP (TRIM) support X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dgilbert@interlog.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 17:35:02 -0000 On 11-12-24 09:27 AM, Alexander Motin wrote: > Hi. > > I've implemented patch for logical block provisioning (aka UNMAP, TRIM, > BIO_DELETE) support for the CAM da driver in HEAD and would like to ask for > review, testing and hardware support information. > > Depending on device capabilities I use several different methods to implement > it. Method can be read/set via kern.cam.da.X.delete_method sysctls. Possible > values are: > NONE - no provisioning support reported by the device; > DISABLE - provisioning support was disabled because of errors; > ZERO - use WRITE SAME (10) command to write zeroes; > WS10 - use WRITE SAME (10) command with UNMAP bit set; > WS16 - use WRITE SAME (16) command with UNMAP bit set; > UNMAP - use UNMAP command. > Last two methods (UNMAP and WS16) are defined by SBC specification and UNMAP > method is the most advanced one. The rest of methods I've found supported in > Linux, and as soon as they were trivial to implement, then why not? Hope they > will be useful in some cases. > > Unluckily at this moment I have no devices reporting parameters of the logical > block provisioning support via respective VPD pages (0xB0 and 0xB2). So all info > I have/use now is the flag telling whether logical block provisioning is > supported or not. As result specific methods chosen now by trying different ones > in order (UNMAP, WS16, DISABLE) and checking completion status to fallback if > needed. I don't expect problems from this, as if something go wrong, it should > just disable itself. It may disable even too aggressively. > > Unlike Linux, which executes each delete with separate request, I've implemented > here the same request aggregation as implemented in ada driver. Tests on SSDs I > have show much better results doing it this way: above 8GB/s of the linear > delete on Intel SATA SSD on LSI SAS HBA (mps). > > The patch can be found here: > http://people.freebsd.org/~mav/scsi_unmap.patch > > Work sponsored by iXsystems, Inc. > > If somebody has SAS SSDs with UNMAP support, I would be grateful for additional > information about them, such as: > camcontrol cmd da0 -c "12 01 00 00 ff 00" -i 255 - >pages > camcontrol cmd da0 -c "12 01 b0 00 ff 00" -i 255 - >page_b0 > camcontrol cmd da0 -c "12 01 b2 00 ff 00" -i 255 - >page_b2 > camcontrol cmd da0 -c "9e 10 00 00 00 00 00 00 00 00 00 00 00 ff 00 00" -i 255 - > >rc16 You might find my sg3_utils package useful. It builds on FreeBSD and contains sg_vpd, sg_readcap and sg_unmap which may be more convenient than "bit-banging" through 'camcontrol cmd'. See: http://sg.danny.cz/sg/sg3_utils.html The above sequence would be: sg_vpd /dev/da0 sg_vpd -p 0xb0 /dev/da0 sg_vpd -p 0xb2 /dev/da0 sg_readcap -l /dev/da0 If you want the response in hex rather than decoded, add a '-H' option (for binary add a '-r' option). In Linux we can test the SCSI UNMAP command against SATA SSDs due to the SATL inside libata. It is actually a lousy SATL, LSI have a much better one in firmware in their MPT Fusion SAS-2 HBAs (but I think "IT" rather than "IR" firmware may be needed). True SAS SSDs are a bit thin on the ground. Hopefully more will emerge with SAS-3 (12 Gbps) and perhaps using the dual phys on a standard SAS disk connector as a single port: more bandwidth, less redundancy. Doug Gilbert