Date: Mon, 26 May 2014 18:30:43 +0930 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-usb@freebsd.org Subject: Re: Test Results (was: Re: Do _any_ USB 3.0 cards actually work?) Message-ID: <104A4A54-FAA6-4631-ACB5-7753125F05C1@gsoft.com.au> In-Reply-To: <1986.1401074203@server1.tristatelogic.com> References: <1986.1401074203@server1.tristatelogic.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 26 May 2014, at 12:46, Ronald F. Guilmette <rfg@tristatelogic.com> wrote: > My desktop#1 system contains this dual port USB 3.0 PCIe interface card > that I've already mentioned (VIA LV800 chipset): > > http://www.newegg.com/Product/Product.aspx?Item=17Z-0002-00002 > > My desktop#2 system contains this Anker 2-port USB 3.0 PCIe card: > > http://www.amazon.com/Anker%C2%AE-Uspeed-Express-20-pin-Connector/dp/B007SJGGAE/ref=pd_cp_pc_2/181-8193670-6916000 > > I have just now checked that, and the big chip on that has written on > the top of the chip "VL800-Q8", so apparentlty this also contained the > VIA[tm] VL 800 "chipset". So, this is the same USB3 controller I am using with success, the plot thickens :) > My HTPC system contains whatever the heck kind of USB 3.0 controller > Foxconn elected in include on the board for this system: > > http://www.newegg.com/Product/Product.aspx?Item=N82E16856119070 Your dmesg says it is a "ASMedia ASM1042 USB 3.0 controller" > 1) On all three test systems, the current FreeBSD USB driver doesn't > entirely like the Hitachi Touro Moble 500GB USB 3.0 drive. In each case, > connecting this drive results in a set of error messages like the following: > > (probe0:umass-sim2:2:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 > (probe0:umass-sim2:2:0:0): CAM status: SCSI Status Error > (probe0:umass-sim2:2:0:0): SCSI status: Check Condition > (probe0:umass-sim2:2:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) > (probe0:umass-sim2:2:0:0): Error 22, Unretryable error > > That last line is clearly incorrect, and at the very least needs to be > rephrased. Speaking from personal experience, I can attest to the fact > that there are no such things, in life or anywhere else, as an error that > cannot be retried, ad infinitum. (And I have the scars to priove it!) You're reading too much into what the SCSI standard says, it wasn't written with human beings in mind ;) It just means there is no point retrying because it isn't a transient error (I believe). This is typically caused by devices which reject legal SCSI commands hence HPS's suggestion to add a quirk so the SCSI stack doesn't try sending that command to the device. Not sure on the rest of your stuff though, sorry. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTgwK75ZPcIHs/zowRAlENAJ9npom4f5MgpyB/cobdmMLBhf7n6gCgiMON qucABdsmvXcxDPjG0pV/7BQ= =kb55 -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?104A4A54-FAA6-4631-ACB5-7753125F05C1>