Re: Test Results (was: Re: Do _any_ USB 3.0 cards actually work?)

2014-05-26 Thread Daniel O'Connor

On 26 May 2014, at 12:46, Ronald F. Guilmette r...@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-2
 
 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








signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Test Results (was: Re: Do _any_ USB 3.0 cards actually work?)

2014-05-26 Thread Warren Block

On Sun, 25 May 2014, Ronald F. Guilmette wrote:


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


This article about USB 3.0 controllers from 2011 is interesting in 
general, but specifically because it talks about the USB controller 
integrated in some AMD chipsets:


http://vr-zone.com/articles/usb-3-0-speed-tests-7-way-host-controllers-roundup/13358.html

Hopefully the situation has improved since then.
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


Test Results (was: Re: Do _any_ USB 3.0 cards actually work?)

2014-05-25 Thread Ronald F. Guilmette

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-2

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  # 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  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