As a result of Warren Block's suggestion, I decided to try a number of new and additional tests in order to try to further pin down and/or at least document the current set of USB 3.0 problems I've been grappling with.
I have also gathered further information about which chips, specifically are contained within my various devices and controllers. I do hope that all of the following information will prove useful. I am fortunate to have here three (3) different (amd) x86-based systems which each contain a dual USB 3.0 interface card of one kind or another. I am also fortunate to also have several different kinds of USB 2.0 and USB 3.0 external devices that I can run tests with. First, in order to make sure that I am reporting _current_ issues relating tro USB support, today I downloaded the following image file and installed this onto a USB 2.0 stick I had lying around (i.e. a "SanDisk Switch" 8GB): FreeBSD-10.0-STABLE-amd64-20140506-r265408-memstick.img All test results reported below are from systems that were booted to the above FreeBSD image. The results I gathered are all in the form of copies of /var/log/messages files. (At first I was going to provide just output from dmesg(8), but then I noticed that those don't have date/time stamps, so I went back and re-did all of my tests and collected the /var/log/messags files instead.) The following files show the results of the numerous tests I did on the three different system I own that contain USB 3.0 interfaces: ftp://ftp.tristatelogic.com/pub/fbsd-usb3/desktop1-varlogmessages.txt ftp://ftp.tristatelogic.com/pub/fbsd-usb3/desktop2-varlogmessages.txt ftp://ftp.tristatelogic.com/pub/fbsd-usb3/htcp-varlogmessages.txt Please note that during my tests every time I performed some manual action, in particular plugging or unplugging a USD device, I used the logger(1) program to write a line starting with "====================" to the system log (/var/log/messages). This helps a lot to see what was really (physically) going on at each step during the tests. 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". 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 For my tests, I used the following 4 external devices, which I list here (and which I tested) in what I believed might be incresing levels of probable non-working-ness: <SanDisk Cruzer Blade 1.20> # USB 2.0 device http://www.amazon.com/SanDisk-Cruzer-Frustration-Free-Packaging-SDCZ50-004G-AFFP/dp/B007KFAG8O <ADATA USB Flash Drive 1.00> # USB 3.0 device http://www.newegg.com/Product/Product.aspx?Item=N82E16820211572 http://www.amazon.com/ADATA-Superior-Series-Flash-AS102P-16G-RGY/dp/B005Y8C0H4 <HitachiG ST 0000> # USB 3.0 device http://www.newegg.com/Product/Product.aspx?Item=N82E16822145582 http://www.amazon.com/HGST-Touro-Mobile-External-HTOLMX3NA5001ABB/dp/B0062FZ3PY <Hitachi HTS541010A9E680 JA0O> # USB 3.0 device http://www.newegg.com/Product/Product.aspx?Item=N82E16817826002 http://www.amazon.com/Patriot-PCGTII25S-Gauntlet-2/dp/B006ICNRUO Please note that the <HitachiG ST 0000> device is a PERMANENTLY SEALED unit, so there is no way for me to find out what sort of interface chip is inside that. What I am listing here as <Hitachi HTS541010A9E680 JA0O> is actually a rather ordinary 2.5" 1TB laptop drive which I have installed inside of a Patroit[tm] brand "Gauntlet 2" external 2.5" USB 3.0 enclosure. (See links above for pictures and more technical information.) In the case of the Patriot[tm] Gauntlet2 2.5" USB 3.0 enclosure (aka <Hitachi HTS541010A9E680 JA0O>) I took the time to actually disassemble that so that I could look and see what sort of chip was in it. Written on the chip that is inside the Gauntlet2 is a set of three designators, the first of which is "GL3310". Googling that plus up lots of relevant information. As a boot device on all 3 test systems I also used a USB 2.0 flash stick which is identified within the system logs as <SanDisk Cruzer Switch 1.26>. That was pulgged into a USB 2.0 port on all three test systems during boot up. My test procedure for all three systems was as follows: 1) Insert the SanDisk Cruzer Blade (USB 2.0) into one of the two USB 3.0 ports. 2) Insert the ADATA USB Flash Drive into the second USB 3.0 port and then remove it. 3) Insert the (sealed) Hitachi Touro Moble 500GB USB 3.0 drive into the second USB 3.0 port and then remove it. 4) Insert the Patroit Gauntlet II (containing a Hitachi 2.5" 1TB laptop drive) into the second USB 3.0 port and then remove it. Several things are apparent from these tests, specifically: 0) Both USB 2.0 and USB 3.0 flash sticks seem to be accepted and properly recognized with no apparent problems. 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!) Anyway, after all this noise in the system log, the Hitachi Touro Moble external USB 3.0 drive does seem to be recognized sufficiently well (by the driver) so that it at least gets assigned a proper /dev/ node and so that its serial number, speed, and capacity all appear in the logs. (Sorry, no, I did not have time to test actual functioning of all of the 3x4 combinations I tried during these tests.) But it is still quite entirely disconcerting to be getting all of these error messages relating to what I firmly believe to be a perfectly good and perfectly working external drive. (So I do wish that these "error" messages could be eliminated. They do not seem to be useful for anything except inducing fear and/or panic into the hearts and minds of us end- lusers.) 2) As can be seen in the "desktop2-varlogmessages.txt' log file, on that one system there were also a number of additional errors logged after the Hitachi Touro Mobile drive was plugged in: (probe0:umass-sim2:2:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim2:2:0:0): CAM status: CCB request completed with an error (probe0:umass-sim2:2:0:0): Retrying command (probe0:umass-sim2:2:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim2:2:0:0): CAM status: CCB request completed with an error (probe0:umass-sim2:2:0:0): Retrying command (probe0:umass-sim2:2:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim2:2:0:0): CAM status: CCB request completed with an error (probe0:umass-sim2:2:0:0): Retrying command These are also very very worrying. 3) The Patroit Gauntlet2 (containing a Hitachi 1TB drive) was apparently recognized with no problems whatsoever, after being plugged in, on my HTPC system. However there are VERY evident problems with this device on both of my two desktop systems. In the case of desktop#1 system, I get an error immediately after the Gauntlet2 is plugged in: usb_alloc_device: set address 4 failed (USB_ERR_TIMEOUT, ignored) but after that it seems to be OK. In the case of my desktop#2 system, plugging in the Gauntlet2 caused a BIG mess of errors, as can be seen in the relevant log file... *and*, as can be seen from the date/time stamps it takes approximately 2 full minuts to recover from its confusion in this case. Also, the problems here are not, apparently, confined to just the Gauntlet2 device itself. Rather, after plugging that in, the driver+controller appear to have briefly lost contact with the SanDisk Cruzer Blade also!! Eventually, as can be seen in the log, the driver does seem to manage to figure out that everything is OK after all, and eventually it reconnects to the SanDisk Cruzer Blade and it also finally correctly detects the Gauntlet2 (aka <Hitachi HTS541010A9E680 JA0O>). Please note that my desktop#2 system contains a Gigabyte GA-M55Plus-S3G motherboard. I don't know if that is even relevant, but this specific botherboard is already known to me to have at least two specific BIOS bugs. (But as FreeBSD probably isn't using any part of the BIOS, those issues are, I think, irrelevant.) I can spare instances of any and all of the equipment described above that seems to be causing problems. Specifically, if it will help any, I will be happy to snail-mail any or all of the following to whoever is developing or maintaining the FreeBSD USB driver(s), provided that this equipment is returned to me afterwards. (I will pay the postage or shipping charges both ways.) *) Patriot Gaultlet2 external USB 3.0 enclosure [**] *) Hitachi Touro Mobile 500GB USB 3.0 portable external drive *) Aanker 2-port USB 3.0 PCIe card [**] *) HooToo 2-port USB 3.0 PCIe card [**] ** It might be cheaper for me to just purchase spares of these and have them shipped directly to whoever might work on them. _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"