libusb-devel Mailing List for libusb

I've worked with these chips and their predecessors for longer than I care
to remember.  About all you can say is that anything you write to the bulk
endpoint on one end comes out on the read endpoint on the other end...
usually.  Subject to it not being a multiple of the USB max packet size, it
will come out the same size if you set up the endpoints correctly.

You have to be able to recover from the data transfer freezing by flushing
and resetting the pipes.  This means you need some kind of reliable
protocol.  The later chips are getting better in this respect.  Early USB
to USB chips (not necessarily Prolific) would freeze after a few GB and
practically need unplugging before they'd work again.

I've not found the interrupt pipe useful.  In fact, on some of the chips, I
never got any data on it!

So, I've found you are best hanging multiple bulk reads on the read
endpoint, and sending data on the write endpoint as necessary.  Put
timeouts around the writes and flush/reset the pipe if the write times
out.  Pick a protocol of choice out of Tannenbaum's "Computer Networks" to
make it reliable.

Orin.

On Fri, Jun 24, 2016 at 12:08 PM, Tim Roberts <ti...@pr...> wrote:

> Isaachsen, Erin K. wrote:
> > Yes.  I would like to create my own application to transfer messages
> over this cable from between hosts.
> >
> > On Host A we have an app that does a libusb_bulk_transfer (with a long
> timeout) on the IN Bulk Transfer Endpoint (0x83) and it blocks.  Then on
> Host B we have an app that does a libusb_bulk_transfer on the OUT Bulk
> Transfer Endpoint (0x02).  The Host A app never gets the transfer and
> eventually times out.
> >
> > Using this Data Sheet for the chip:
> http://prolificusa.com/files/ds_pl25A1B_v1.0B.pdf
> >
> > There is another endpoint indicated in the Data Sheet, Endpoint 1 IN,
> Interrupt Transfer, but it is not clear how that is involved in getting
> data to go back and forth on the Bulk Transfer endpoints.  The cable is
> advertised as being expressly made for the Windows Easy Transfer Program;
> it does work with that.
>
> It's not impossible that there is a protocol involved here, so that the
> bulk packets have to have some kind of header to exchange information.
> I'm guessing the interrupt pipe is used to notify one end when data is
> available.  Waiting on an interrupt pipe is much more efficient than
> waiting on a bulk pipe, which ends up flooding the bus with continuous
> IN requests.
>
> You're poking in the dark.  Have you tried using a bus monitor to see
> what actually happens in the "Easy Transfer" process?
>
> --
> Tim Roberts, ti...@pr...
> Providenza & Boekelheide, Inc.
>
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

Isaachsen, Erin K. wrote:
> Yes.  I would like to create my own application to transfer messages over this cable from between hosts.    
>
> On Host A we have an app that does a libusb_bulk_transfer (with a long timeout) on the IN Bulk Transfer Endpoint (0x83) and it blocks.  Then on Host B we have an app that does a libusb_bulk_transfer on the OUT Bulk Transfer Endpoint (0x02).  The Host A app never gets the transfer and eventually times out.
>
> Using this Data Sheet for the chip: http://prolificusa.com/files/ds_pl25A1B_v1.0B.pdf 
>
> There is another endpoint indicated in the Data Sheet, Endpoint 1 IN, Interrupt Transfer, but it is not clear how that is involved in getting data to go back and forth on the Bulk Transfer endpoints.  The cable is advertised as being expressly made for the Windows Easy Transfer Program; it does work with that. 

It's not impossible that there is a protocol involved here, so that the
bulk packets have to have some kind of header to exchange information. 
I'm guessing the interrupt pipe is used to notify one end when data is
available.  Waiting on an interrupt pipe is much more efficient than
waiting on a bulk pipe, which ends up flooding the bus with continuous
IN requests.

You're poking in the dark.  Have you tried using a bus monitor to see
what actually happens in the "Easy Transfer" process?

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

I have used a cable that's remarkably close to the one you are describing.
It acts like a virtual network adapter, allowing two machines to
communicate with each other through various services.  Mine did not come
with a DHCP server and I did not use the company's software, so I had to
configure the network interface with a static IP on both sides.  Next, I
used a server of some sort (HTTP, FTP and SSH all worked fine) over this
network and shared files.

--
Tyler Akins

On Fri, Jun 24, 2016 at 1:45 PM, Isaachsen, Erin K. <
Eri...@gd...> wrote:

> Yes.  I would like to create my own application to transfer messages over
> this cable from between hosts.
>
> On Host A we have an app that does a libusb_bulk_transfer (with a long
> timeout) on the IN Bulk Transfer Endpoint (0x83) and it blocks.  Then on
> Host B we have an app that does a libusb_bulk_transfer on the OUT Bulk
> Transfer Endpoint (0x02).  The Host A app never gets the transfer and
> eventually times out.
>
> Using this Data Sheet for the chip:
> http://prolificusa.com/files/ds_pl25A1B_v1.0B.pdf
>
> There is another endpoint indicated in the Data Sheet, Endpoint 1 IN,
> Interrupt Transfer, but it is not clear how that is involved in getting
> data to go back and forth on the Bulk Transfer endpoints.  The cable is
> advertised as being expressly made for the Windows Easy Transfer Program;
> it does work with that.
>
> This is the cable we are using: http://plugable.com/products/usb-easy-tran
>
>
> Erin Kenna Isaachsen
> Sr. Advanced Engineer 1-Software
> General Dynamics Mission Systems
> Fair Lakes, VA
> 703-263-7687 (office)
>
>
> -----Original Message-----
> From: Tim Roberts [mailto:ti...@pr...]
> Sent: Friday, June 24, 2016 1:24 PM
> To: Libusb Mailing List
> Subject: Re: [libusb] USB Host to Host Bridge Cable with Prolific PL25A1
> chip question
>
> Isaachsen, Erin K. wrote:
> >
> > Has anyone gotten bulk transfers to work between two hosts using a
> > bridge cable with this chip in it?
> >
>
> Clearly, file transfers work.  Are you asking if people have been able to
> hack into this to do custom transfers without using the vendor supplied
> application?
>
> --
> Tim Roberts, ti...@pr...
> Providenza & Boekelheide, Inc.
>
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

Yes.  I would like to create my own application to transfer messages over this cable from between hosts.    

On Host A we have an app that does a libusb_bulk_transfer (with a long timeout) on the IN Bulk Transfer Endpoint (0x83) and it blocks.  Then on Host B we have an app that does a libusb_bulk_transfer on the OUT Bulk Transfer Endpoint (0x02).  The Host A app never gets the transfer and eventually times out.

Using this Data Sheet for the chip: http://prolificusa.com/files/ds_pl25A1B_v1.0B.pdf 

There is another endpoint indicated in the Data Sheet, Endpoint 1 IN, Interrupt Transfer, but it is not clear how that is involved in getting data to go back and forth on the Bulk Transfer endpoints.  The cable is advertised as being expressly made for the Windows Easy Transfer Program; it does work with that. 

This is the cable we are using: http://plugable.com/products/usb-easy-tran


Erin Kenna Isaachsen
Sr. Advanced Engineer 1-Software
General Dynamics Mission Systems
Fair Lakes, VA
703-263-7687 (office)


-----Original Message-----
From: Tim Roberts [mailto:ti...@pr...] 
Sent: Friday, June 24, 2016 1:24 PM
To: Libusb Mailing List
Subject: Re: [libusb] USB Host to Host Bridge Cable with Prolific PL25A1 chip question

Isaachsen, Erin K. wrote:
>
> Has anyone gotten bulk transfers to work between two hosts using a 
> bridge cable with this chip in it?
>

Clearly, file transfers work.  Are you asking if people have been able to hack into this to do custom transfers without using the vendor supplied application?

--
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.


------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
libusb-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Isaachsen, Erin K. wrote:
>
> Has anyone gotten bulk transfers to work between two hosts using a
> bridge cable with this chip in it?
>

Clearly, file transfers work.  Are you asking if people have been able
to hack into this to do custom transfers without using the vendor
supplied application?

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

This would be on Windows 10.

Erin Kenna Isaachsen
Sr. Advanced Engineer 1-Software
General Dynamics Mission Systems
Fair Lakes, VA
703-263-7687 (office)

From: Isaachsen, Erin K. [mailto:Eri...@gd...]
Sent: Friday, June 24, 2016 1:02 PM
To: lib...@li...
Cc: Hartzog, Danny G.
Subject: [libusb] USB Host to Host Bridge Cable with Prolific PL25A1 chip question

Has anyone gotten bulk transfers to work between two hosts using a bridge cable with this chip in it?

Erin Kenna Isaachsen
Sr. Advanced Engineer 1-Software
General Dynamics Mission Systems
Fair Lakes, VA
703-263-7687 (office)

Has anyone gotten bulk transfers to work between two hosts using a bridge cable with this chip in it?

Erin Kenna Isaachsen
Sr. Advanced Engineer 1-Software
General Dynamics Mission Systems
Fair Lakes, VA
703-263-7687 (office)

hmidi amine wrote:
> > Is this a physical device or a VM?
> it's a physical device
>
> > Can you get the PCI identifier from Device Manager?
> the device manager shows, "USB-IF xHCI USB Host Controller" as PCI
> identifier and intel as a provider, however the chipset used by the
> USB3.0 card has an assy : ME252513 REV A and a serial: CTS481JME4566

That's not a PCI identifier.  The PCI identifier looks like
VEN_1234&DEV_5678.  You should be able to find that in Device Manager,
Properties, Details, Hardware Ids.

What is the computer make and model?  Are you using an add-in card for
USB 3.0?  If so, what's the make?

This seems like a lot of trivial detail, but my hunch here is that you
just have a driver incompatibility.  Maybe if we get enough details, we
can figure out where the disconnect lies.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Apologies for the previous post with wrong title. Too quick with my send key.

br Kusti


>Sorry (again) for posting here as this is not really a libusb question but since this is the most likely place for people who know these things to hang out I'm trying to pick their brain.
>
>I'm trying to read a feature report from a device in Windows 7 (this is related to my PureJavaHidApi project).
>
>This device is an Atari Joystick adapter (not created by me).
>
>I runs in two modes depending on a hardware signal.
>
>In normal mode it appears as 'Retro Joystick Adapter v3.0" along other HID devies in Devices and Printers.
>
>In boot mode it appears a 'HIDBoot' device in Unspecified category of Devices and Printers.
>
>In normal mode my enumeration code cannot find the device at all. Maybe that is normal if and when the system has grabbed the device.
>
>In boot mode the device is found and can be opened but when I do a get feature request (either with the HidD_GetFeature call or DeviceIoControl call, see below for the code) I get GetLastError()==23 i.e. CRC error.
>
>Any idea what this could mean.
>
>Under Mac OS everything works.
>
>See here for Mac OS USB Prober view of the device descriptors:
>
>http://www.sparetimelabs.com/temp/pic3.png
>
>Any ideas where to go from here?
>
>wbr Kusti
>
>
>The code (this is Java but should be readable):
>
>   public int getFeatureReport(byte[] data, int length) {
>      if (!m_Open)
>         throw new IllegalStateException("device not open");
>      if (false) {
>         if (!HidD_GetFeature(m_Handle, data, length)) {
>            System.out.println(GetLastError());
>            return -1;
>         }
>      } else {
>         int[] bytes_returned = { 0 };
>
>         OVERLAPPED ol = new OVERLAPPED();
>         Pointer datap = new Memory(data.length);
>         if (!DeviceIoControl(m_Handle, IOCTL_HID_GET_FEATURE, datap, length, datap, length, bytes_returned, ol)) {
>            if (GetLastError() != ERROR_IO_PENDING)
>               return -1;
>            return bytes_returned[0];
>         }
>
>         if (!GetOverlappedResult(m_Handle, ol, bytes_returned, true/* wait */)) {
>            return -1;
>         }
>         return bytes_returned[0];
>      }
>   }
>
>
>
>
>
>

This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general.

>Sorry (again) for posting here as this is not really a libusb question but since this is the most likely place for people who know these things to hang out I'm trying to pick their brain.
>
>I'm trying to read a feature report from a device in Windows 7 (this is related to my PureJavaHidApi project).
>
>This device is an Atari Joystick adapter (not created by me).
>
>I runs in two modes depending on a hardware signal.
>
>In normal mode it appears as 'Retro Joystick Adapter v3.0" along other HID devies in Devices and Printers.
>
>In boot mode it appears a 'HIDBoot' device in Unspecified category of Devices and Printers.
>
>In normal mode my enumeration code cannot find the device at all. Maybe that is normal if and when the system has grabbed the device.
>
>In boot mode the device is found and can be opened but when I do a get feature request (either with the HidD_GetFeature call or DeviceIoControl call, see below for the code) I get GetLastError()==23 i.e. CRC error.
>
>Any idea what this could mean.
>
>Under Mac OS everything works.
>
>See here for Mac OS USB Prober view of the device descriptors:
>
>http://www.sparetimelabs.com/temp/pic3.png
>
>Any ideas where to go from here?
>
>wbr Kusti
>
>
>The code (this is Java but should be readable):
>
>   public int getFeatureReport(byte[] data, int length) {
>      if (!m_Open)
>         throw new IllegalStateException("device not open");
>      if (false) {
>         if (!HidD_GetFeature(m_Handle, data, length)) {
>            System.out.println(GetLastError());
>            return -1;
>         }
>      } else {
>         int[] bytes_returned = { 0 };
>
>         OVERLAPPED ol = new OVERLAPPED();
>         Pointer datap = new Memory(data.length);
>         if (!DeviceIoControl(m_Handle, IOCTL_HID_GET_FEATURE, datap, length, datap, length, bytes_returned, ol)) {
>            if (GetLastError() != ERROR_IO_PENDING)
>               return -1;
>            return bytes_returned[0];
>         }
>
>         if (!GetOverlappedResult(m_Handle, ol, bytes_returned, true/* wait */)) {
>            return -1;
>         }
>         return bytes_returned[0];
>      }
>   }
>
>
>
>
>
>

This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general.

hmidi amine wrote:
>
> Currently, i'm developing an application using libusb-1.0.19, on
> Windows 7(64 bits). The target device is connected to the machine via
> "USB-IF xHCI USB Host Controller"(usb3) with a driver version: 1.0.3.11.

Isn't that the fake XHCI driver that is installed by the USB-IF
compatibility test suite?  If so, that driver is only intended to
support the test suite.  There's no guarantee that is supports
everything that the Windows driver stack expects.

One of the problems in using USB 3 prior to Windows 8 is that there is
no Microsoft support.  The only available drivers come from the
manufacturer of your host controller, and not all of those manufacturers
followed Microsoft's poorly documented rules for host controllers and
hubs.  Thus, they don't always respond to the requests libusb needs in
order to operate.

Is this a physical device or a VM?  What USB chipset do you have?  Can
you get the PCI identifier from Device Manager?   Are the results any
different with libusb 1.0.20?

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Hello,

Currently, i'm developing an application using libusb-1.0.19, on Windows
7(64 bits). The target device is connected to the machine via "USB-IF xHCI
USB Host Controller"(usb3) with a driver version: 1.0.3.11.
I've already installed the libusb driver using Zadig. However, after a
searching for my target device using  libusb_get_device_list(), i'm not
able to find it in the devices' list and i get the following message
regarding my target device:
libusb: warning [init_device] could not get node connection information for
device '\\.\USB#VID_0483&PID_DF11#6&20F069C&0&0000': [1] Incorrect function.

I've already searched for this error message but all i've got is some
results regarding a similar message which is related to usb3 drivers
problem with libusb:
libusb: warning [init_device] could not get node connection information for
device '................................': [87] The parameter is incorrect.

Please find below libusb log message fallowing libusb_get_device_list() :

[timestamp] [threadID] facility level [function call] <message>

--------------------------------------------------------------------------------



[ 0.002001] [0000045c] libusb: debug [libusb_get_device_list]

[ 0.006002] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [2F]

[ 0.006002] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [17F]

[ 0.006002] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [287]

[ 0.006002] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [396]

[ 0.006002] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [6E]

[ 0.007002] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [176]

[ 0.007002] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [27E]

[ 0.007002] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [2F1]

[ 0.010002] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [D2]

[ 0.016004] [0000045c] libusb: debug [get_api_type] driver(s): usbhub

[ 0.018004] [0000045c] libusb: debug [get_api_type] matched driver name
against

HUB API

[ 0.021005] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [31A]

[ 0.026006] [0000045c] libusb: debug [get_api_type] driver(s): usbhub

[ 0.029006] [0000045c] libusb: debug [get_api_type] matched driver name
against

HUB API

[ 0.033007] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [76]

[ 0.038008] [0000045c] libusb: debug [get_api_type] driver(s): usbhub

[ 0.041009] [0000045c] libusb: debug [get_api_type] matched driver name
against

HUB API

[ 0.046010] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [18F]

[ 0.056012] [0000045c] libusb: debug [get_api_type] driver(s): usbhub

[ 0.061013] [0000045c] libusb: debug [get_api_type] matched driver name
against

HUB API

[ 0.071015] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [195]

[ 0.081017] [0000045c] libusb: debug [get_api_type] driver(s): usbhub

[ 0.085017] [0000045c] libusb: debug [get_api_type] matched driver name
against

HUB API

[ 0.095019] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [4A]

[ 0.106022] [0000045c] libusb: debug [get_api_type] driver(s): usbhub

[ 0.111023] [0000045c] libusb: debug [get_api_type] matched driver name
against

HUB API

[ 0.121025] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [62]

[ 0.132027] [0000045c] libusb: debug [get_api_type] driver(s): usbhub

[ 0.136028] [0000045c] libusb: debug [get_api_type] matched driver name
against

HUB API

[ 0.146030] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [19C]

[ 0.156032] [0000045c] libusb: debug [get_api_type] driver(s): usbhub

[ 0.165033] [0000045c] libusb: debug [get_api_type] matched driver name
against

HUB API

[ 0.176036] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [E1]

[ 0.188038] [0000045c] libusb: debug [get_api_type] driver(s): usb3Hub

[ 0.196040] [0000045c] libusb: debug [get_api_type] matched driver name
against

HUB API

[ 0.202041] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [205]

[ 0.208042] [0000045c] libusb: debug [windows_get_device_list] found
existing de

vice for session [31A] (0.0)

[ 0.212043] [0000045c] libusb: debug [init_device] (bus: 5, addr: 1, depth:
0, p

ort: 0): '\\.\USB#ROOT_HUB#4&1D1F9EFF&0'

[ 0.216044] [0000045c] libusb: debug [windows_get_device_list] found
existing de

vice for session [76] (0.0)

[ 0.220044] [0000045c] libusb: debug [init_device] (bus: 2, addr: 1, depth:
0, p

ort: 0): '\\.\USB#ROOT_HUB#4&1D34ED58&0'

[ 0.226046] [0000045c] libusb: debug [windows_get_device_list] found
existing de

vice for session [18F] (0.0)

[ 0.231047] [0000045c] libusb: debug [init_device] (bus: 6, addr: 1, depth:
0, p

ort: 0): '\\.\USB#ROOT_HUB#4&328EE772&0'

[ 0.236048] [0000045c] libusb: debug [windows_get_device_list] found
existing de

vice for session [195] (0.0)

[ 0.241049] [0000045c] libusb: debug [init_device] (bus: 4, addr: 1, depth:
0, p

ort: 0): '\\.\USB#ROOT_HUB#4&39CF66EE&0'

[ 0.246050] [0000045c] libusb: debug [windows_get_device_list] found
existing de

vice for session [4A] (0.0)

[ 0.250050] [0000045c] libusb: debug [init_device] (bus: 7, addr: 1, depth:
0, p

ort: 0): '\\.\USB#ROOT_HUB#4&5317206&0'

[ 0.256052] [0000045c] libusb: debug [windows_get_device_list] found
existing de

vice for session [62] (0.0)

[ 0.261053] [0000045c] libusb: debug [init_device] (bus: 3, addr: 1, depth:
0, p

ort: 0): '\\.\USB#ROOT_HUB#4&7C5A4E5&0'

[ 0.266054] [0000045c] libusb: debug [windows_get_device_list] found
existing de

vice for session [19C] (0.0)

[ 0.271055] [0000045c] libusb: debug [init_device] (bus: 8, addr: 1, depth:
0, p

ort: 0): '\\.\USB#ROOT_HUB20#4&126BADCB&0'

[ 0.276056] [0000045c] libusb: debug [windows_get_device_list] found
existing de

vice for session [E1] (0.0)

[ 0.281057] [0000045c] libusb: debug [init_device] (bus: 9, addr: 1, depth:
0, p

ort: 0): '\\.\USB#ROOT_HUB20#4&B9E25E9&0'

[ 0.286058] [0000045c] libusb: debug [windows_get_device_list] extra GUID:
{0110

5872-BF45-43BE-8B67-3C0F2B8CF0D9}

[ 0.291059] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [EF]

[ 0.296060] [0000045c] libusb: debug [init_device] got bus number from
ancestor

#2

[ 0.301061] [0000045c] libusb: warning [init_device] could not get node
connecti

on information for device '\\.\USB#VID_0483&PID_DF11#6&20F069C&0&0000': [1]
Inco

rrect function.

[ 0.309062] [0000045c] libusb: debug [windows_get_device_list] allocating
new de

vice for session [E3]

[ 0.314063] [0000045c] libusb: debug [init_device] found 1 configurations
(activ

e conf: 1)

[ 0.319064] [0000045c] libusb: debug [cache_config_descriptors] cached
config de

scriptor 0 (bConfigurationValue=1, 32 bytes)

[ 0.323065] [0000045c] libusb: debug [init_device] (bus: 8, addr: 2, depth:
1, p

ort: 6): '\\.\USB#VID_14CD&PID_125C#125C20100726'

[ 0.329066] [0000045c] libusb: debug [discovered_devs_append] need to
increase c

apacity

[ 0.337068] [0000045c] libusb: debug [windows_get_device_list] found
existing de

vice for session [205] (1.0)

[ 0.340068] [0000045c] libusb: debug [init_device] (bus: 1, addr: 1, depth:
0, p

ort: 0): '\\.\USB#VID_8086&PID_1111#5&20AAF99C&0&0001'

[ 0.347070] [0000045c] libusb: debug [get_api_type] driver(s): USBSTOR

[ 0.349070] [0000045c] libusb: debug [windows_get_device_list] found
existing de

vice for session [E3] (8.2)

[ 0.354071] [0000045c] libusb: debug [get_api_type] driver(s): WinUSB

[ 0.355071] [0000045c] libusb: debug [get_api_type] matched driver name
against

WinUSB
[ 0.360072] [0000045c] libusb: debug [libusb_unref_device] destroy device
1.0

Best regards.

Hans Petter Selasky wrote:
> The following 16-bit field is prefixed "b" while it should be "w" in 
> libusb.h :
>
> 	/** U2 Device Exit Latency. */
> 	uint16_t bU2DevExitLat;
>
> Correct:
>
> 	/** U2 Device Exit Latency. */
> 	uint16_t wU2DevExitLat;
>
> ??

True, but it's easy enough to understand how it happened, given that
bU1DevExitLat IS an 8-bit field.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Hi,

The following 16-bit field is prefixed "b" while it should be "w" in 
libusb.h :

	/** U2 Device Exit Latency. */
	uint16_t bU2DevExitLat;

Correct:

	/** U2 Device Exit Latency. */
	uint16_t wU2DevExitLat;

??

--HPS

Ludovic Rousseau wrote:
> This device has "Cls=0b(scard)" and so is/should be impacted by the udev
> rules:
> ENV{ID_USB_INTERFACES}==":0b0000:", RUN+="/bin/sh -c 'echo auto >
> /sys/$devpath/power/control'"

Ah yes - you're absolutely right. Thanks for the correction!


//Peter

2016-06-15 20:37 GMT+02:00 Peter Stuge <pe...@st...>:

> John Simpson wrote:
> > We were able to get it to work by compiling libusb-1.0.20 with the
> > option “—enable-udev=no”.
>
> Excellent news - glad to hear that it works now.
>
>
> > Not sure why that would have an effect, but that gets me past this
> > hurdle.
>
> I guess the hotplug code (which is what --enable-udev enables)
> doesn't handle coldplugging on Linux in a way that works with
> your kernel and udev, but it's only a guess - I avoid that code.
>
> --enable-udev=no is a fine solution. You could probably tune another
> part of the system to be able to use a binary libusb package, but I'm
> not sure if that would be any easier..?
>
>
> > [root@QL0002 ~]# ls -R /dev/bus/usb
> ..
> > /dev/bus/usb/001:
> > 001  002  003  004  005  006  007  008  009  010  011  012
>
> Looks great!
>
>
> > [root@QL0002 ~]# cat /etc/udev/rules.d/92_pcscd_ccid.rules
> > # udev rules for CCID devices
>
> None of the rules in this file seem to actually apply to your device.
> But it also does no harm to have it there.
>
>
John has 1 CCID smart card reader device.

T:  Bus=01 Lev=04 Prnt=10 Port=03 Cnt=02 Dev#= 12 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=076b ProdID=a024 Rev= 2.04
S:  Manufacturer=OMNIKEY AG
S:  Product=Smart Card Reader USB
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=0b(scard) Sub=00 Prot=00 Driver=(none)
E:  Ad=83(I) Atr=03(Int.) MxPS=   8 Ivl=24ms
E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

This device has "Cls=0b(scard)" and so is/should be impacted by the udev
rules:
ENV{ID_USB_INTERFACES}==":0b0000:", RUN+="/bin/sh -c 'echo auto >
/sys/$devpath/power/control'"

Have a look at "libccid and USB selective suspend"
https://ludovicrousseau.blogspot.fr/2011/04/libccid-and-usb-selective-suspend.html
for more details.


But this is not related to the libusb issue he had.

Bye

-- 
 Dr. Ludovic Rousseau

John Simpson wrote:
> We were able to get it to work by compiling libusb-1.0.20 with the
> option “—enable-udev=no”.

Excellent news - glad to hear that it works now.


> Not sure why that would have an effect, but that gets me past this
> hurdle.

I guess the hotplug code (which is what --enable-udev enables)
doesn't handle coldplugging on Linux in a way that works with
your kernel and udev, but it's only a guess - I avoid that code.

--enable-udev=no is a fine solution. You could probably tune another
part of the system to be able to use a binary libusb package, but I'm
not sure if that would be any easier..?


> [root@QL0002 ~]# ls -R /dev/bus/usb
..
> /dev/bus/usb/001:
> 001  002  003  004  005  006  007  008  009  010  011  012

Looks great!


> [root@QL0002 ~]# cat /etc/udev/rules.d/92_pcscd_ccid.rules
> # udev rules for CCID devices

None of the rules in this file seem to actually apply to your device.
But it also does no harm to have it there.


//Peter

We were able to get it to work by compiling libusb-1.0.20 with the option
“—enable-udev=no”.

Not sure why that would have an effect, but that gets me past this hurdle.

[root@QL0002 ~]# ls -R /dev/bus/usb
/dev/bus/usb:
001/

/dev/bus/usb/001:
001  002  003  004  005  006  007  008  009  010  011  012

[root@QL0002 ~]# ls -R /proc/bus/usb
ls: cannot access /proc/bus/usb: No such file or directory

[root@QL0002 ~]# ls -l /dev/usbdev*.*
ls: cannot access /dev/usbdev*.*: No such file or directory

[root@QL0002 ~]# ls /etc/udev/rules.d
92_pcscd_ccid.rules

[root@QL0002 ~]# cat /etc/udev/rules.d/92_pcscd_ccid.rules
# udev rules for CCID devices

# Gemplus PCMCIA Card
#SUBSYSTEMS=="pcmcia", DRIVERS=="serial_cs", ACTION=="add",
ATTRS{prod_id1}=="Gemplus", ATTRS{prod_id2}=="SerialPort",
ATTRS{prod_id3}=="GemPC Card", RUN+="/usr/sbin/pcscd --hotplug"

# If not adding the device, go away
ACTION!="add", GOTO="pcscd_ccid_rules_end"
SUBSYSTEM!="usb", GOTO="pcscd_ccid_rules_end"
ENV{DEVTYPE}!="usb_device", GOTO="pcscd_ccid_rules_end"

# Kobil mIDentity
ATTRS{idVendor}=="0d46", ATTRS{idProduct}=="4081",
RUN+="/usr/sbin/Kobil_mIDentity_switch"

# set USB power management to auto.
ENV{ID_USB_INTERFACES}==":0b0000:", RUN+="/bin/sh -c 'echo auto >
/sys/$devpath/power/control'"

# All done
LABEL="pcscd_ccid_rules_end"

The device of interest is /dev/bus/usb/001/012.

On Wed, Jun 15, 2016 at 9:44 AM, Peter Stuge <pe...@st...> wrote:

> John Simpson wrote:
> > > What kernel is this? RT-Linux? Maybe it doesn't have all the userspace
> > > APIs enabled that libusb needs. Debug your kernel situation.
> ..
> > It is a custom built kernel with support for udev & multicast.
>
> Also some/all custom udev rules?
>
>
> > [root@QL0002 ccid-1.4.24]# cat /sys/kernel/debug/usb/devices
> ..
> > T:  Bus=01 Lev=04 Prnt=10 Port=03 Cnt=02 Dev#= 12 Spd=12   MxCh= 0
> > D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> > P:  Vendor=076b ProdID=a024 Rev= 2.04
> > S:  Manufacturer=OMNIKEY AG
> > S:  Product=Smart Card Reader USB
> > C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
> > I:* If#= 0 Alt= 0 #EPs= 3 Cls=0b(scard) Sub=00 Prot=00 Driver=(none)
> > E:  Ad=83(I) Atr=03(Int.) MxPS=   8 Ivl=24ms
> > E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> > E:  Ad=05(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> >
> > The last device in the list is the one I'm trying to load via pcscd.
>
> Normally the usbfs driver will be assigned, as a kind of catch-all
> for USB devices/interfaces without an explicit kernel driver, which
> is the case for CCID.
>
> Together with libusb_get_device_list() not returning any devices this
> suggests that your kernel and/or udev is indeed not providing
> everything that libusb requires.
>
> ls -R /dev/bus/usb
> ls -R /proc/bus/usb
> ls -l /dev/usbdev*.*
>
> Make sure one of them exists, then it'll work fine.
>
>
> //Peter
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.
> http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

John Simpson wrote:
> > What kernel is this? RT-Linux? Maybe it doesn't have all the userspace
> > APIs enabled that libusb needs. Debug your kernel situation.
..
> It is a custom built kernel with support for udev & multicast.

Also some/all custom udev rules?


> [root@QL0002 ccid-1.4.24]# cat /sys/kernel/debug/usb/devices
..
> T:  Bus=01 Lev=04 Prnt=10 Port=03 Cnt=02 Dev#= 12 Spd=12   MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=076b ProdID=a024 Rev= 2.04
> S:  Manufacturer=OMNIKEY AG
> S:  Product=Smart Card Reader USB
> C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=0b(scard) Sub=00 Prot=00 Driver=(none)
> E:  Ad=83(I) Atr=03(Int.) MxPS=   8 Ivl=24ms
> E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=05(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> 
> The last device in the list is the one I'm trying to load via pcscd.

Normally the usbfs driver will be assigned, as a kind of catch-all
for USB devices/interfaces without an explicit kernel driver, which
is the case for CCID.

Together with libusb_get_device_list() not returning any devices this
suggests that your kernel and/or udev is indeed not providing
everything that libusb requires.

ls -R /dev/bus/usb
ls -R /proc/bus/usb
ls -l /dev/usbdev*.*

Make sure one of them exists, then it'll work fine.


//Peter

(Sorry, accidentally replied off-list)

It is a custom built kernel with support for udev & multicast.

[root@QL0002 ccid-1.4.24]# grep sysfs /proc/filesystems
nodev sysfs
[root@QL0002 ccid-1.4.24]# grep debugfs /proc/filesystems
nodev debugfs
[root@QL0002 ccid-1.4.24]# mount -t debugfs debugfs /sys/kernel/debug
[root@QL0002 ccid-1.4.24]# cat /sys/kernel/debug/usb/devices

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 8
B:  Alloc=  0/800 us ( 0%), #Int=  3, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 3.18
S:  Manufacturer=Linux 3.18.9-rt5 ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 4
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=8087 ProdID=07e6 Rev= 0.17
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  3 Spd=480  MxCh= 7
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
P:  Vendor=0424 ProdID=2517 Rev= 0.02
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  2mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

T:  Bus=01 Lev=03 Prnt=03 Port=00 Cnt=01 Dev#=  4 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0403 ProdID=6015 Rev=10.00
S:  Manufacturer=FTDI
S:  Product=FT230X Basic UART
S:  SerialNumber=DN00HXC4
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 90mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

T:  Bus=01 Lev=03 Prnt=03 Port=01 Cnt=02 Dev#=  5 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0403 ProdID=6015 Rev=10.00
S:  Manufacturer=FTDI
S:  Product=FT230X Basic UART
S:  SerialNumber=DN00INYY
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 90mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

T:  Bus=01 Lev=03 Prnt=03 Port=02 Cnt=03 Dev#=  6 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0403 ProdID=6015 Rev=10.00
S:  Manufacturer=FTDI
S:  Product=FT230X Basic UART
S:  SerialNumber=DN00HY1J
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 90mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

T:  Bus=01 Lev=03 Prnt=03 Port=03 Cnt=04 Dev#=  7 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0403 ProdID=6015 Rev=10.00
S:  Manufacturer=FTDI
S:  Product=FT230X Basic UART
S:  SerialNumber=DN00I1CZ
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 90mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

T:  Bus=01 Lev=03 Prnt=03 Port=04 Cnt=05 Dev#=  8 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0403 ProdID=6015 Rev=10.00
S:  Manufacturer=FTDI
S:  Product=FT230X Basic UART
S:  SerialNumber=DN00HTXL
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 90mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

T:  Bus=01 Lev=03 Prnt=03 Port=05 Cnt=06 Dev#=  9 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0403 ProdID=6015 Rev=10.00
S:  Manufacturer=FTDI
S:  Product=FT230X Basic UART
S:  SerialNumber=DN00IB2M
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 90mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

T:  Bus=01 Lev=03 Prnt=03 Port=06 Cnt=07 Dev#= 10 Spd=480  MxCh= 4
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
P:  Vendor=0451 ProdID=8142 Rev= 1.00
S:  SerialNumber=0E000089BA20
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

T:  Bus=01 Lev=04 Prnt=10 Port=02 Cnt=01 Dev#= 11 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0403 ProdID=6015 Rev=10.00
S:  Manufacturer=FTDI
S:  Product=FT230X Basic UART
S:  SerialNumber=DJ00TIIK
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 90mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

T:  Bus=01 Lev=04 Prnt=10 Port=03 Cnt=02 Dev#= 12 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=076b ProdID=a024 Rev= 2.04
S:  Manufacturer=OMNIKEY AG
S:  Product=Smart Card Reader USB
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=0b(scard) Sub=00 Prot=00 Driver=(none)
E:  Ad=83(I) Atr=03(Int.) MxPS=   8 Ivl=24ms
E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

The last device in the list is the one I'm trying to load via pcscd.

On Tue, Jun 14, 2016 at 12:07 PM, Peter Stuge <pe...@st...> wrote:

> John Simpson wrote:
> > If anybody can help me find out why libusb_get_device list is returning
> > an empty list on this system, it will be greatly appreciated.
> >
> > # uname -a
> > Linux QL0002 3.18.9-rt5 #1 SMP PREEMPT RT Tue Apr 19 12:49:49 EDT 2016
> i686
> > i686 i386 GNU/Linux
>
> What kernel is this? RT-Linux? Maybe it doesn't have all the userspace
> APIs enabled that libusb needs. Debug your kernel situation.
>
> grep sysfs /proc/filesystems
> grep debugfs /proc/filesystems
> mount -t debugfs debugfs /sys/kernel/debug
> cat /sys/kernel/debug/usb/devices
>
> Run as root of course.
>
> You can also look at plain dmesg output to see what the kernel
> reports in terms of USB activity.
>
> I recommend to compare your problem system to an x86 machine with as
> similar hardware as possible but any plain desktop or server Linux
> distribution. debian, Fedora, Ubuntu, Arch, anything mainstream.
>
>
> //Peter
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

Can confirm on Ubuntu 16.04 and 14.04 LTS that this works. Might 
possibly have to resort to sudo if you aren't a member of the `udev' group.

============================================================
Matthew Giassa, MASc, BASc, EIT
Security and Embedded Systems Specialist
linkedin: https://ca.linkedin.com/in/giassa
e-mail:   ma...@gi...
website:  www.giassa.net

On 06/14/16 09:07, Peter Stuge wrote:
> John Simpson wrote:
>> If anybody can help me find out why libusb_get_device list is returning
>> an empty list on this system, it will be greatly appreciated.
>>
>> # uname -a
>> Linux QL0002 3.18.9-rt5 #1 SMP PREEMPT RT Tue Apr 19 12:49:49 EDT 2016 i686
>> i686 i386 GNU/Linux
>
> What kernel is this? RT-Linux? Maybe it doesn't have all the userspace
> APIs enabled that libusb needs. Debug your kernel situation.
>
> grep sysfs /proc/filesystems
> grep debugfs /proc/filesystems
> mount -t debugfs debugfs /sys/kernel/debug
> cat /sys/kernel/debug/usb/devices
>
> Run as root of course.
>
> You can also look at plain dmesg output to see what the kernel
> reports in terms of USB activity.
>
> I recommend to compare your problem system to an x86 machine with as
> similar hardware as possible but any plain desktop or server Linux
> distribution. debian, Fedora, Ubuntu, Arch, anything mainstream.
>
>
> //Peter
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

John Simpson wrote:
> If anybody can help me find out why libusb_get_device list is returning
> an empty list on this system, it will be greatly appreciated.
> 
> # uname -a
> Linux QL0002 3.18.9-rt5 #1 SMP PREEMPT RT Tue Apr 19 12:49:49 EDT 2016 i686
> i686 i386 GNU/Linux

What kernel is this? RT-Linux? Maybe it doesn't have all the userspace
APIs enabled that libusb needs. Debug your kernel situation.

grep sysfs /proc/filesystems
grep debugfs /proc/filesystems
mount -t debugfs debugfs /sys/kernel/debug
cat /sys/kernel/debug/usb/devices

Run as root of course.

You can also look at plain dmesg output to see what the kernel
reports in terms of USB activity.

I recommend to compare your problem system to an x86 machine with as
similar hardware as possible but any plain desktop or server Linux
distribution. debian, Fedora, Ubuntu, Arch, anything mainstream.


//Peter

I'm looking in the source for libusb-1.0.20

I've traced into the code as far as this point:

                list_for_each_entry(dev, &ctx->usb_devs, list, struct
libusb_device) {
// this line is never executed
                        discdevs = discovered_devs_append(discdevs, dev);

                        if (!discdevs) {
                                r = LIBUSB_ERROR_NO_MEM;
                                break;
                        }
                }

Not sure how to troubleshoot past this point, as list_for_each_entry is
#defined.

If anybody can help me find out why libusb_get_device list is returning an
empty list on this system, it will be greatly appreciated.

# uname -a
Linux QL0002 3.18.9-rt5 #1 SMP PREEMPT RT Tue Apr 19 12:49:49 EDT 2016 i686
i686 i386 GNU/Linux

Will provide any further info requested as needed.  Not sure what info
would be needed to troubleshoot further.

Thanks,

John

Thank you for this information. I disagree on the comment on the lack of
testing though. We paid a pretty penny for specialized USB3 hubs that
trigger disconnects/reconnects, have proper impedance matching, etc, on
the boards. The previous behavior I described occurred every time on
Ubuntu 14.04 (.1 through .4) with thousands of hours of automated
testing on dozens of different host controllers.

============================================================
Matthew Giassa, MASc, BASc, EIT
Security and Embedded Systems Specialist
linkedin: https://ca.linkedin.com/in/giassa
e-mail:   ma...@gi...
website:  www.giassa.net

> -------- Original Message --------
> Subject: Re: [libusb] Potential regression in libusb-1.0-0 v1.20.0 on
> Ubuntu Xenial 16.04LTS
> From: Hans de Goede <hde...@re...>
> Date: Wed, June 08, 2016 8:38 am
> To: Matthew Giassa <ma...@gi...>,        Libusb Mailing List
> <lib...@li...>
> 
> 
> Hi,
> 
> On 08-06-16 16:22, Matthew Giassa wrote:
> > Correction to my earlier message. After physically disconnecting a
> > device, the callbacks have an error code of "LIBUSB_TRANSFER_ERROR",
> > when we would normally expect "LIBUSB_ERROR_NO_DEVICE".
> 
> I think you mean: LIBUSB_TRANSFER_NO_DEVICE, callback  status codes do
> not use the LIBUSB_ERROR_FOO namespace.
> 
> Anyways you cannot expect callbacks to always report a status of
> LIBUSB_TRANSFER_NO_DEVICE on disconnect. When the connector is
> being pulled out one may very well see one or more transfers
> complete with io-errors before the usb(root)hub signals disconnection,
> in which case the callbacks will report a status of LIBUSB_TRANSFER_ERROR.
> 
> Also note that callbacks are not the only place where you may see
> a disconnect, you can also have your (re-)submission of transfers
> fail with e.g. LIBUSB_ERROR_NO_DEVICE.
> 
> The only reliable way to detect disconnection is to use libusb's
> new hotplug functionality *and* be prepared to handle errors
> (any type of error) during transfer submission and completion.
> 
> > Is this  necessarily a change/regression in libusb, or is it more likely to be a
> > USBFS issue?
> 
> Neither if so-far you've only seen transfers complete with
> LIBUSB_TRANSFER_NO_DEVICE on disconnection you've simply been
> lucky and/or not done really thorough testing.
> 
> Regards,
> 
> Hans

Hi,

On 08-06-16 16:22, Matthew Giassa wrote:
> Correction to my earlier message. After physically disconnecting a
> device, the callbacks have an error code of "LIBUSB_TRANSFER_ERROR",
> when we would normally expect "LIBUSB_ERROR_NO_DEVICE".

I think you mean: LIBUSB_TRANSFER_NO_DEVICE, callback  status codes do
not use the LIBUSB_ERROR_FOO namespace.

Anyways you cannot expect callbacks to always report a status of
LIBUSB_TRANSFER_NO_DEVICE on disconnect. When the connector is
being pulled out one may very well see one or more transfers
complete with io-errors before the usb(root)hub signals disconnection,
in which case the callbacks will report a status of LIBUSB_TRANSFER_ERROR.

Also note that callbacks are not the only place where you may see
a disconnect, you can also have your (re-)submission of transfers
fail with e.g. LIBUSB_ERROR_NO_DEVICE.

The only reliable way to detect disconnection is to use libusb's
new hotplug functionality *and* be prepared to handle errors
(any type of error) during transfer submission and completion.

> Is this  necessarily a change/regression in libusb, or is it more likely to be a
> USBFS issue?

Neither if so-far you've only seen transfers complete with
LIBUSB_TRANSFER_NO_DEVICE on disconnection you've simply been
lucky and/or not done really thorough testing.

Regards,

Hans