Date: Sun, 25 May 2014 20:16:43 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-usb@freebsd.org Subject: Test Results (was: Re: Do _any_ USB 3.0 cards actually work?) Message-ID: <1986.1401074203@server1.tristatelogic.com> In-Reply-To: <alpine.BSF.2.00.1405242123150.97320@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1986.1401074203>