usb/190204: Please add an empty #define LIBUSB_CALL in libusb.h (1.0+ API)

2014-05-25 Thread Scott Howard

Number: 190204
Category:   usb
Synopsis:   Please add an empty #define LIBUSB_CALL in libusb.h (1.0+ API)
Confidential:   no
Severity:   non-critical
Priority:   low
Responsible:freebsd-usb
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Sun May 25 17:00:00 UTC 2014
Closed-Date:
Last-Modified:
Originator: Scott Howard
Release:
Organization:
Debian
Environment:
Description:
libusb 1.0 API has an empty
#define LIBUSB_CALL

Described here:
http://git.libusb.org/?p=libusb.git;a=blob;f=libusb/libusb.h;hb=7634714aa696175b08016b6f2185a75a2f55a113;js=1#l100

Implemented here:
http://libusb.sourceforge.net/api-1.0/group__misc.html#gaa7d6035eb2692d455d27144560a0f68d

Cross platform applications need LIBUSB_CALL, even if it is empty. 
How-To-Repeat:

Fix:
Add
#define LIBUSB_CALL
to one of the libusb headers (maybe libusb10.h?)

Release-Note:
Audit-Trail:
Unformatted:
___
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


Re: usb/190204: commit references a PR

2014-05-25 Thread dfilter service
The following reply was made to PR usb/190204; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: usb/190204: commit references a PR
Date: Sun, 25 May 2014 18:06:35 + (UTC)

 Author: hselasky
 Date: Sun May 25 18:06:32 2014
 New Revision: 24
 URL: http://svnweb.freebsd.org/changeset/base/24
 
 Log:
   Add empty LIBUSB_CALL macro, to be compatible to the libusb 1.0-API
   from sourceforge.
   
   PR:  usb/190204
   MFC after:   1 week
 
 Modified:
   head/lib/libusb/libusb.h
 
 Modified: head/lib/libusb/libusb.h
 ==
 --- head/lib/libusb/libusb.h   Sun May 25 18:06:28 2014(r23)
 +++ head/lib/libusb/libusb.h   Sun May 25 18:06:32 2014(r24)
 @@ -33,6 +33,8 @@
  #include sys/types.h
  #endif
  
 +#define   LIBUSB_CALL
 +
  #ifdef __cplusplus
  externC {
  #endif
 ___
 svn-src-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
 
___
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


Re: Do _any_ USB 3.0 cards actually work?

2014-05-25 Thread Daniel O'Connor

On 25 May 2014, at 12:36, Daniel O'Connor docon...@gsoft.com.au wrote:
 I'll take pictures of them on Monday.

http://imgur.com/a/N8Dto

The non-working one uses an EtronTech EJ188H
The working one uses a VLI VL800 (I think, my photo was pretty hard to read)

--
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: Do _any_ USB 3.0 cards actually work?

2014-05-25 Thread Daniel O'Connor

On 26 May 2014, at 11:59, Daniel O'Connor docon...@gsoft.com.au wrote:
 On 25 May 2014, at 12:36, Daniel O'Connor docon...@gsoft.com.au wrote:
 I'll take pictures of them on Monday.
 
 http://imgur.com/a/N8Dto
 
 The non-working one uses an EtronTech EJ188H
 The working one uses a VLI VL800 (I think, my photo was pretty hard to read)

FWIW the Etron is pretty poorly regarded (many threads about crashes and so on).

Searching Linux shows..
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb?id=ded737fe6a2fe5d18005e6e97e40e0d728a6619b
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/host?id=001fd3826f4c736ce292315782d015f768399080
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/host?id=5cb7df2b2d3afee7638b3ef23a5bcb89c6f07bd9

Although I am not sure either are relevant to the symptoms I see.

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


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