libusb-devel Mailing List for libusb

Thanks.

 <<there is libusb build for Windows so you could use that to test on
windows.
What do I need to do here ? It talks about using mingw-32 and stuff. I
haven't yet used mingw enviroment , so I dont know what needs to be done
here to compile my code and run the tests.

Is it good to work on cygwin or some other environment on Windows to use my
libusb tests ?


Also I tried compiling my code in MINGW-32 environment but got this below
error :
libusb.h - No such file or directory


Thanks,




On Mon, Jun 30, 2014 at 1:04 PM, dineshkumar muthusamy <
dsp...@gm...> wrote:

> Nice, there is libusb build for Windows so you could use that to test on
> windows.
>
> https://github.com/libusbx/libusbx/wiki/Windows-Backend
>
> This is looks like some enumeration issue If Windows turns down the device
> then there is something that Widnows does not like, for instance the
> information in the descriptor string descriptor and conf desc. Becasue
> Linux and Windows handle devices differently so even if it works in Linux
> does not necessarily work in Windows.
> Check the basic descriptor info if it is as per USB spec ? What end points
> does ur device use bulk or intpt or isoc ?
>
> Try connecting a powered USB 3.0 hub in between so this will eliminate any
> power issues and sometime signal quality issues.
>
> I understand USB 3.0 and device connection can be tricky, so try hub while
> using analyzer as well.( might help)
>
> On Windows 7 check for recent drivers from USB 3.0 vendor if possible try
> another PCIe-USB card on Windows. or Windows 8 or 8.1 on same machine
>
> Good luck!
>
>
>
> On Mon, Jun 30, 2014 at 9:22 AM, Thejus.. <mee...@gm...> wrote:
>
>> <<1. if the request from host actually reaches the device,
>> <<    I would do it by checking the device code by adding debug in device
>> firmware
>> <<2. Use USB protocol anaylzer ( this requires hardware and cost )
>> <<3. If the USB packet from the host reaches the device then check if the
>> device actually sends proper packet within time.
>>
>> Thanks will try and check it out with the analyzer. Currently there seems
>> to be some issue with the link on connecting the analyzer in between the
>> device and the host controller.
>>
>>
>> <<On ther other hand I have faced lot of issues with Windows and
>> corresponding USB 3.0 driver. From Windows 8 you native <<USB 3.0 support (
>> atleast I think so) and USB 3.0 is comparatively stable. If you are
>> starting new with this custom device I <<would suggest to test in a
>> complete Linux system or Windows system just to rule out other unknowns
>> from Cywin and so <<on.
>>
>> <<Once the you know the device can communicate in Linux or Windows then
>> you can come back to Cygwin if you need.
>>
>> The same test works perfectly fine on Linux environment. I am able to do
>> GB's of data transfer without any issue.
>>
>> When you say communicate with Windows and then come back to Cygwin,is
>> there any other way to do test the device using libusb on Windows ? Since
>> I have a set of libusb tests already written and they all work fine on
>> Linux !
>> This above test was tested on Windows 7 machine.
>>
>> As far as Windows 8 is concerned , I am unable to detect my device on
>> Device Manager (it says device is connected intermittently and then does
>> off ). This is the message that I get in Windows 8 device manager window
>> on connecting the device -
>>
>> "This device cannot start. (Code 10)
>>
>> {Device Timeout}
>> The specified I/O operation on %hs was not completed before the time-out
>> period expired."
>>
>>
>> Do you sense any USB3.0 driver issue here because it is easily detected
>> on my Windows 7 setup ?
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>> On Mon, Jun 30, 2014 at 12:34 PM, dineshkumar muthusamy <
>> dsp...@gm...> wrote:
>>
>>> So good, it looks like the control transfer timesout. To debug further,
>>> I would suggest to check
>>>
>>> 1. if the request from host actually reaches the device,
>>>      I would do it by checking the device code by adding debug in device
>>> firmware
>>> 2. Use USB protocol anaylzer ( this requires hardware and cost )
>>> 3. If the USB packet from the host reaches the device then check if the
>>> device actually sends proper packet within time.
>>>
>>> Onther other hand I have faced lot of issues with Windows and
>>> corresponding USB 3.0 driver. From Windows 8 you native USB 3.0 support (
>>> atleast I think so) and USB 3.0 is comparatively stable. If you are
>>> starting new with this custom device I would suggest to test in a complete
>>> Linux system or Windows system just to rule out other unknowns from Cywin
>>> and so on.
>>>
>>> Once the you know the device can communicate in Linux or Windows then
>>> you can come back to Cygwin if you need.
>>>
>>> These are just my suggestions or my thoughts, based on what I have faced.
>>>
>>> Best regards,
>>> Dinesh.
>>>
>>>
>>> On Mon, Jun 30, 2014 at 8:51 AM, Thejus.. <mee...@gm...> wrote:
>>>
>>>> Thanks Dinesh !
>>>>
>>>> Also I had set the level to 3 initially and this is what I see when I
>>>> change it to 4
>>>>
>>>> INFO: Claimed Device Interface 0
>>>> INFO: Transfer Size-0 : 1024
>>>> INFO:Programming IN data generator for endpoint 1 with seed value
>>>> 706050403020100
>>>> [ 3.135180] [00000c68] libusbx: debug [winusb_submit_control_transfer]
>>>> will use interface 0
>>>> [ 3.136180] [00000c68] libusbx: debug [usbi_add_pollfd] add fd 4 events
>>>> 1
>>>> [ 3.136180] [00000c68] libusbx: debug [libusb_get_next_timeout] next
>>>> timeout in 4.999669s
>>>> [ 3.136180] [00000c68] libusbx: debug
>>>> [libusb_handle_events_timeout_completed] doing our own event handling
>>>> [ 3.136180] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
>>>> timeout in 5000ms
>>>> [ 8.136466] [00000c68] libusbx: debug [handle_events] poll() returned 0
>>>> [ 8.136466] [00000c68] libusbx: debug [libusb_cancel_transfer]
>>>> [ 8.136466] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
>>>> with timeout or all handled by OS; no timeout!
>>>> [ 8.136466] [00000c68] libusbx: debug
>>>> [libusb_handle_events_timeout_completed] doing our own event handling
>>>> [ 8.136466] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
>>>> timeout in 60000ms
>>>> [68.136898] [00000c68] libusbx: debug [handle_events] poll() returned 0
>>>> [68.136898] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
>>>> with timeout or all handled by OS; no timeout!
>>>> [68.136898] [00000c68] libusbx: debug
>>>> [libusb_handle_events_timeout_completed] doing our own event handling
>>>> [68.136898] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
>>>> timeout in 60000ms
>>>> [128.137329] [00000c68] libusbx: debug [handle_events] poll() returned 0
>>>> [128.137329] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
>>>> with timeout or all handled by OS; no timeout!
>>>> [128.137329] [00000c68] libusbx: debug
>>>> [libusb_handle_events_timeout_completed] doing our own event handling
>>>> [128.137329] [00000c68] libusbx: debug [handle_events] poll() 2 fds
>>>> with timeout in 60000ms
>>>>
>>>> It keeps on printing after every 6000ms.
>>>>
>>>> Any idea what this means ?
>>>>
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jun 30, 2014 at 12:06 PM, dineshkumar muthusamy <
>>>> dsp...@gm...> wrote:
>>>>
>>>>> Hi,
>>>>> In this case I would suggest to either use some use some debug trace
>>>>> or USB protocol analyzer or enable highest level of debug info in libusb.
>>>>> i.e.
>>>>>
>>>>> void libusb_set_debug(libusb_context
>>>>> <http://libusb.sourceforge.net/api-1.0/group__lib.html#ga4ec088aa7b79c4a9599e39bf36a72833>
>>>>>  *  ctx, int level ) enum   libusb_log_level
>>>>> <http://libusb.sourceforge.net/api-1.0/group__lib.html#ga2d6144203f0fc6d373677f6e2e89d2d2>
>>>>>  {
>>>>>   *LIBUSB_LOG_LEVEL_NONE* = 0, *LIBUSB_LOG_LEVEL_ERROR*,
>>>>> *LIBUSB_LOG_LEVEL_WARNING*, *LIBUSB_LOG_LEVEL_INFO*,
>>>>>   *LIBUSB_LOG_LEVEL_DEBUG*
>>>>> }
>>>>>
>>>>> I hope this will give you some more info to debug.
>>>>>
>>>>> *Regards,*
>>>>> *Dinesh.*
>>>>>
>>>>>
>>>>> On Mon, Jun 30, 2014 at 8:05 AM, Thejus.. <mee...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I am trying run some tests using a custom usb3.0 device on a Windows
>>>>>> 7 machine. This device has been loaded onto a FPGA board and I am trying to
>>>>>> access this device using a cygwin environment. I have also installed WinUSB
>>>>>> driver(v6.1.7600.16385) using Zadig.
>>>>>>
>>>>>> Device is able to detect itself and on giving lsusb I am able to see
>>>>>> it with VID?PID and the name. This means that the there is no issue with
>>>>>> driver,right ?
>>>>>>
>>>>>> But on running the test I see the test getting stuck on doing the
>>>>>> FIRST libusb_control_transfer. It doesn't print anything after that and
>>>>>> remains stuck (not even a timeout)
>>>>>>
>>>>>> This is what I do in the test before sending that control transfer :
>>>>>> 1. libusb_init()
>>>>>> 2. libusb_open_device_with_vid_pid()
>>>>>> 3. libusb_kernel_drive_active()
>>>>>> 4. libusb_set_configuration()
>>>>>> 5. libusb_claim_interface().
>>>>>>
>>>>>> 6. Call libusb_control_transfer(*)
>>>>>>
>>>>>> All these steps are being processed and I am able to claim the
>>>>>> interface as well but when I try to call libsub_control_transfer() it gets
>>>>>> stuck. I tried debugging using gdb but couldn't figure out much.
>>>>>>
>>>>>> Any idea what might be going wrong OR how to go about debugging the
>>>>>> issue ?
>>>>>>
>>>>>>
>>>>>> Note: This same test works completely fine on Linux !
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Open source business process management suite built on Java and
>>>>>> Eclipse
>>>>>> Turn processes into business applications with Bonita BPM Community
>>>>>> Edition
>>>>>> Quickly connect people, data, and systems into organized workflows
>>>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>>>> http://p.sf.net/sfu/Bonitasoft
>>>>>> _______________________________________________
>>>>>> libusb-devel mailing list
>>>>>> lib...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Dineshkumar M.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Dineshkumar M.
>>>
>>
>>
>
>
> --
> Best regards,
> Dineshkumar M.
>

Nice, there is libusb build for Windows so you could use that to test on
windows.

https://github.com/libusbx/libusbx/wiki/Windows-Backend

This is looks like some enumeration issue If Windows turns down the device
then there is something that Widnows does not like, for instance the
information in the descriptor string descriptor and conf desc. Becasue
Linux and Windows handle devices differently so even if it works in Linux
does not necessarily work in Windows.
Check the basic descriptor info if it is as per USB spec ? What end points
does ur device use bulk or intpt or isoc ?

Try connecting a powered USB 3.0 hub in between so this will eliminate any
power issues and sometime signal quality issues.

I understand USB 3.0 and device connection can be tricky, so try hub while
using analyzer as well.( might help)

On Windows 7 check for recent drivers from USB 3.0 vendor if possible try
another PCIe-USB card on Windows. or Windows 8 or 8.1 on same machine

Good luck!



On Mon, Jun 30, 2014 at 9:22 AM, Thejus.. <mee...@gm...> wrote:

> <<1. if the request from host actually reaches the device,
> <<    I would do it by checking the device code by adding debug in device
> firmware
> <<2. Use USB protocol anaylzer ( this requires hardware and cost )
> <<3. If the USB packet from the host reaches the device then check if the
> device actually sends proper packet within time.
>
> Thanks will try and check it out with the analyzer. Currently there seems
> to be some issue with the link on connecting the analyzer in between the
> device and the host controller.
>
>
> <<On ther other hand I have faced lot of issues with Windows and
> corresponding USB 3.0 driver. From Windows 8 you native <<USB 3.0 support (
> atleast I think so) and USB 3.0 is comparatively stable. If you are
> starting new with this custom device I <<would suggest to test in a
> complete Linux system or Windows system just to rule out other unknowns
> from Cywin and so <<on.
>
> <<Once the you know the device can communicate in Linux or Windows then
> you can come back to Cygwin if you need.
>
> The same test works perfectly fine on Linux environment. I am able to do
> GB's of data transfer without any issue.
>
> When you say communicate with Windows and then come back to Cygwin,is
> there any other way to do test the device using libusb on Windows ? Since
> I have a set of libusb tests already written and they all work fine on
> Linux !
> This above test was tested on Windows 7 machine.
>
> As far as Windows 8 is concerned , I am unable to detect my device on
> Device Manager (it says device is connected intermittently and then does
> off ). This is the message that I get in Windows 8 device manager window
> on connecting the device -
>
> "This device cannot start. (Code 10)
>
> {Device Timeout}
> The specified I/O operation on %hs was not completed before the time-out
> period expired."
>
>
> Do you sense any USB3.0 driver issue here because it is easily detected on
> my Windows 7 setup ?
>
>
> Thanks
>
>
>
>
>
> On Mon, Jun 30, 2014 at 12:34 PM, dineshkumar muthusamy <
> dsp...@gm...> wrote:
>
>> So good, it looks like the control transfer timesout. To debug further, I
>> would suggest to check
>>
>> 1. if the request from host actually reaches the device,
>>      I would do it by checking the device code by adding debug in device
>> firmware
>> 2. Use USB protocol anaylzer ( this requires hardware and cost )
>> 3. If the USB packet from the host reaches the device then check if the
>> device actually sends proper packet within time.
>>
>> Onther other hand I have faced lot of issues with Windows and
>> corresponding USB 3.0 driver. From Windows 8 you native USB 3.0 support (
>> atleast I think so) and USB 3.0 is comparatively stable. If you are
>> starting new with this custom device I would suggest to test in a complete
>> Linux system or Windows system just to rule out other unknowns from Cywin
>> and so on.
>>
>> Once the you know the device can communicate in Linux or Windows then you
>> can come back to Cygwin if you need.
>>
>> These are just my suggestions or my thoughts, based on what I have faced.
>>
>> Best regards,
>> Dinesh.
>>
>>
>> On Mon, Jun 30, 2014 at 8:51 AM, Thejus.. <mee...@gm...> wrote:
>>
>>> Thanks Dinesh !
>>>
>>> Also I had set the level to 3 initially and this is what I see when I
>>> change it to 4
>>>
>>> INFO: Claimed Device Interface 0
>>> INFO: Transfer Size-0 : 1024
>>> INFO:Programming IN data generator for endpoint 1 with seed value
>>> 706050403020100
>>> [ 3.135180] [00000c68] libusbx: debug [winusb_submit_control_transfer]
>>> will use interface 0
>>> [ 3.136180] [00000c68] libusbx: debug [usbi_add_pollfd] add fd 4 events 1
>>> [ 3.136180] [00000c68] libusbx: debug [libusb_get_next_timeout] next
>>> timeout in 4.999669s
>>> [ 3.136180] [00000c68] libusbx: debug
>>> [libusb_handle_events_timeout_completed] doing our own event handling
>>> [ 3.136180] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
>>> timeout in 5000ms
>>> [ 8.136466] [00000c68] libusbx: debug [handle_events] poll() returned 0
>>> [ 8.136466] [00000c68] libusbx: debug [libusb_cancel_transfer]
>>> [ 8.136466] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
>>> with timeout or all handled by OS; no timeout!
>>> [ 8.136466] [00000c68] libusbx: debug
>>> [libusb_handle_events_timeout_completed] doing our own event handling
>>> [ 8.136466] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
>>> timeout in 60000ms
>>> [68.136898] [00000c68] libusbx: debug [handle_events] poll() returned 0
>>> [68.136898] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
>>> with timeout or all handled by OS; no timeout!
>>> [68.136898] [00000c68] libusbx: debug
>>> [libusb_handle_events_timeout_completed] doing our own event handling
>>> [68.136898] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
>>> timeout in 60000ms
>>> [128.137329] [00000c68] libusbx: debug [handle_events] poll() returned 0
>>> [128.137329] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
>>> with timeout or all handled by OS; no timeout!
>>> [128.137329] [00000c68] libusbx: debug
>>> [libusb_handle_events_timeout_completed] doing our own event handling
>>> [128.137329] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
>>> timeout in 60000ms
>>>
>>> It keeps on printing after every 6000ms.
>>>
>>> Any idea what this means ?
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jun 30, 2014 at 12:06 PM, dineshkumar muthusamy <
>>> dsp...@gm...> wrote:
>>>
>>>> Hi,
>>>> In this case I would suggest to either use some use some debug trace or
>>>> USB protocol analyzer or enable highest level of debug info in libusb. i.e.
>>>>
>>>> void libusb_set_debug(libusb_context
>>>> <http://libusb.sourceforge.net/api-1.0/group__lib.html#ga4ec088aa7b79c4a9599e39bf36a72833>
>>>>  *  ctx, int level ) enum   libusb_log_level
>>>> <http://libusb.sourceforge.net/api-1.0/group__lib.html#ga2d6144203f0fc6d373677f6e2e89d2d2>
>>>>  {
>>>>   *LIBUSB_LOG_LEVEL_NONE* = 0, *LIBUSB_LOG_LEVEL_ERROR*,
>>>> *LIBUSB_LOG_LEVEL_WARNING*, *LIBUSB_LOG_LEVEL_INFO*,
>>>>   *LIBUSB_LOG_LEVEL_DEBUG*
>>>> }
>>>>
>>>> I hope this will give you some more info to debug.
>>>>
>>>> *Regards,*
>>>> *Dinesh.*
>>>>
>>>>
>>>> On Mon, Jun 30, 2014 at 8:05 AM, Thejus.. <mee...@gm...> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I am trying run some tests using a custom usb3.0 device on a Windows 7
>>>>> machine. This device has been loaded onto a FPGA board and I am trying to
>>>>> access this device using a cygwin environment. I have also installed WinUSB
>>>>> driver(v6.1.7600.16385) using Zadig.
>>>>>
>>>>> Device is able to detect itself and on giving lsusb I am able to see
>>>>> it with VID?PID and the name. This means that the there is no issue with
>>>>> driver,right ?
>>>>>
>>>>> But on running the test I see the test getting stuck on doing the
>>>>> FIRST libusb_control_transfer. It doesn't print anything after that and
>>>>> remains stuck (not even a timeout)
>>>>>
>>>>> This is what I do in the test before sending that control transfer :
>>>>> 1. libusb_init()
>>>>> 2. libusb_open_device_with_vid_pid()
>>>>> 3. libusb_kernel_drive_active()
>>>>> 4. libusb_set_configuration()
>>>>> 5. libusb_claim_interface().
>>>>>
>>>>> 6. Call libusb_control_transfer(*)
>>>>>
>>>>> All these steps are being processed and I am able to claim the
>>>>> interface as well but when I try to call libsub_control_transfer() it gets
>>>>> stuck. I tried debugging using gdb but couldn't figure out much.
>>>>>
>>>>> Any idea what might be going wrong OR how to go about debugging the
>>>>> issue ?
>>>>>
>>>>>
>>>>> Note: This same test works completely fine on Linux !
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Open source business process management suite built on Java and Eclipse
>>>>> Turn processes into business applications with Bonita BPM Community
>>>>> Edition
>>>>> Quickly connect people, data, and systems into organized workflows
>>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>>> http://p.sf.net/sfu/Bonitasoft
>>>>> _______________________________________________
>>>>> libusb-devel mailing list
>>>>> lib...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Dineshkumar M.
>>>>
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Dineshkumar M.
>>
>
>


-- 
Best regards,
Dineshkumar M.

<<1. if the request from host actually reaches the device,
<<    I would do it by checking the device code by adding debug in device
firmware
<<2. Use USB protocol anaylzer ( this requires hardware and cost )
<<3. If the USB packet from the host reaches the device then check if the
device actually sends proper packet within time.

Thanks will try and check it out with the analyzer. Currently there seems
to be some issue with the link on connecting the analyzer in between the
device and the host controller.


<<On ther other hand I have faced lot of issues with Windows and
corresponding USB 3.0 driver. From Windows 8 you native <<USB 3.0 support (
atleast I think so) and USB 3.0 is comparatively stable. If you are
starting new with this custom device I <<would suggest to test in a
complete Linux system or Windows system just to rule out other unknowns
from Cywin and so <<on.
<<Once the you know the device can communicate in Linux or Windows then you
can come back to Cygwin if you need.

The same test works perfectly fine on Linux environment. I am able to do
GB's of data transfer without any issue.

When you say communicate with Windows and then come back to Cygwin,is there
any other way to do test the device using libusb on Windows ? Since I have
a set of libusb tests already written and they all work fine on Linux !
This above test was tested on Windows 7 machine.

As far as Windows 8 is concerned , I am unable to detect my device on
Device Manager (it says device is connected intermittently and then does
off ). This is the message that I get in Windows 8 device manager window on
connecting the device -

"This device cannot start. (Code 10)

{Device Timeout}
The specified I/O operation on %hs was not completed before the time-out
period expired."


Do you sense any USB3.0 driver issue here because it is easily detected on
my Windows 7 setup ?


Thanks





On Mon, Jun 30, 2014 at 12:34 PM, dineshkumar muthusamy <
dsp...@gm...> wrote:

> So good, it looks like the control transfer timesout. To debug further, I
> would suggest to check
>
> 1. if the request from host actually reaches the device,
>      I would do it by checking the device code by adding debug in device
> firmware
> 2. Use USB protocol anaylzer ( this requires hardware and cost )
> 3. If the USB packet from the host reaches the device then check if the
> device actually sends proper packet within time.
>
> Onther other hand I have faced lot of issues with Windows and
> corresponding USB 3.0 driver. From Windows 8 you native USB 3.0 support (
> atleast I think so) and USB 3.0 is comparatively stable. If you are
> starting new with this custom device I would suggest to test in a complete
> Linux system or Windows system just to rule out other unknowns from Cywin
> and so on.
>
> Once the you know the device can communicate in Linux or Windows then you
> can come back to Cygwin if you need.
>
> These are just my suggestions or my thoughts, based on what I have faced.
>
> Best regards,
> Dinesh.
>
>
> On Mon, Jun 30, 2014 at 8:51 AM, Thejus.. <mee...@gm...> wrote:
>
>> Thanks Dinesh !
>>
>> Also I had set the level to 3 initially and this is what I see when I
>> change it to 4
>>
>> INFO: Claimed Device Interface 0
>> INFO: Transfer Size-0 : 1024
>> INFO:Programming IN data generator for endpoint 1 with seed value
>> 706050403020100
>> [ 3.135180] [00000c68] libusbx: debug [winusb_submit_control_transfer]
>> will use interface 0
>> [ 3.136180] [00000c68] libusbx: debug [usbi_add_pollfd] add fd 4 events 1
>> [ 3.136180] [00000c68] libusbx: debug [libusb_get_next_timeout] next
>> timeout in 4.999669s
>> [ 3.136180] [00000c68] libusbx: debug
>> [libusb_handle_events_timeout_completed] doing our own event handling
>> [ 3.136180] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
>> timeout in 5000ms
>> [ 8.136466] [00000c68] libusbx: debug [handle_events] poll() returned 0
>> [ 8.136466] [00000c68] libusbx: debug [libusb_cancel_transfer]
>> [ 8.136466] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
>> with timeout or all handled by OS; no timeout!
>> [ 8.136466] [00000c68] libusbx: debug
>> [libusb_handle_events_timeout_completed] doing our own event handling
>> [ 8.136466] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
>> timeout in 60000ms
>> [68.136898] [00000c68] libusbx: debug [handle_events] poll() returned 0
>> [68.136898] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
>> with timeout or all handled by OS; no timeout!
>> [68.136898] [00000c68] libusbx: debug
>> [libusb_handle_events_timeout_completed] doing our own event handling
>> [68.136898] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
>> timeout in 60000ms
>> [128.137329] [00000c68] libusbx: debug [handle_events] poll() returned 0
>> [128.137329] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
>> with timeout or all handled by OS; no timeout!
>> [128.137329] [00000c68] libusbx: debug
>> [libusb_handle_events_timeout_completed] doing our own event handling
>> [128.137329] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
>> timeout in 60000ms
>>
>> It keeps on printing after every 6000ms.
>>
>> Any idea what this means ?
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>> On Mon, Jun 30, 2014 at 12:06 PM, dineshkumar muthusamy <
>> dsp...@gm...> wrote:
>>
>>> Hi,
>>> In this case I would suggest to either use some use some debug trace or
>>> USB protocol analyzer or enable highest level of debug info in libusb. i.e.
>>>
>>> void libusb_set_debug(libusb_context
>>> <http://libusb.sourceforge.net/api-1.0/group__lib.html#ga4ec088aa7b79c4a9599e39bf36a72833>
>>>  *  ctx, int level ) enum   libusb_log_level
>>> <http://libusb.sourceforge.net/api-1.0/group__lib.html#ga2d6144203f0fc6d373677f6e2e89d2d2>
>>>  {
>>>   *LIBUSB_LOG_LEVEL_NONE* = 0, *LIBUSB_LOG_LEVEL_ERROR*,
>>> *LIBUSB_LOG_LEVEL_WARNING*, *LIBUSB_LOG_LEVEL_INFO*,
>>>   *LIBUSB_LOG_LEVEL_DEBUG*
>>> }
>>>
>>> I hope this will give you some more info to debug.
>>>
>>> *Regards,*
>>> *Dinesh.*
>>>
>>>
>>> On Mon, Jun 30, 2014 at 8:05 AM, Thejus.. <mee...@gm...> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I am trying run some tests using a custom usb3.0 device on a Windows 7
>>>> machine. This device has been loaded onto a FPGA board and I am trying to
>>>> access this device using a cygwin environment. I have also installed WinUSB
>>>> driver(v6.1.7600.16385) using Zadig.
>>>>
>>>> Device is able to detect itself and on giving lsusb I am able to see it
>>>> with VID?PID and the name. This means that the there is no issue with
>>>> driver,right ?
>>>>
>>>> But on running the test I see the test getting stuck on doing the FIRST
>>>> libusb_control_transfer. It doesn't print anything after that and remains
>>>> stuck (not even a timeout)
>>>>
>>>> This is what I do in the test before sending that control transfer :
>>>> 1. libusb_init()
>>>> 2. libusb_open_device_with_vid_pid()
>>>> 3. libusb_kernel_drive_active()
>>>> 4. libusb_set_configuration()
>>>> 5. libusb_claim_interface().
>>>>
>>>> 6. Call libusb_control_transfer(*)
>>>>
>>>> All these steps are being processed and I am able to claim the
>>>> interface as well but when I try to call libsub_control_transfer() it gets
>>>> stuck. I tried debugging using gdb but couldn't figure out much.
>>>>
>>>> Any idea what might be going wrong OR how to go about debugging the
>>>> issue ?
>>>>
>>>>
>>>> Note: This same test works completely fine on Linux !
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Open source business process management suite built on Java and Eclipse
>>>> Turn processes into business applications with Bonita BPM Community
>>>> Edition
>>>> Quickly connect people, data, and systems into organized workflows
>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>> http://p.sf.net/sfu/Bonitasoft
>>>> _______________________________________________
>>>> libusb-devel mailing list
>>>> lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>>>>
>>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Dineshkumar M.
>>>
>>
>>
>
>
> --
> Best regards,
> Dineshkumar M.
>

So good, it looks like the control transfer timesout. To debug further, I
would suggest to check

1. if the request from host actually reaches the device,
     I would do it by checking the device code by adding debug in device
firmware
2. Use USB protocol anaylzer ( this requires hardware and cost )
3. If the USB packet from the host reaches the device then check if the
device actually sends proper packet within time.

Onther other hand I have faced lot of issues with Windows and corresponding
USB 3.0 driver. From Windows 8 you native USB 3.0 support ( atleast I think
so) and USB 3.0 is comparatively stable. If you are starting new with this
custom device I would suggest to test in a complete Linux system or Windows
system just to rule out other unknowns from Cywin and so on.

Once the you know the device can communicate in Linux or Windows then you
can come back to Cygwin if you need.

These are just my suggestions or my thoughts, based on what I have faced.

Best regards,
Dinesh.


On Mon, Jun 30, 2014 at 8:51 AM, Thejus.. <mee...@gm...> wrote:

> Thanks Dinesh !
>
> Also I had set the level to 3 initially and this is what I see when I
> change it to 4
>
> INFO: Claimed Device Interface 0
> INFO: Transfer Size-0 : 1024
> INFO:Programming IN data generator for endpoint 1 with seed value
> 706050403020100
> [ 3.135180] [00000c68] libusbx: debug [winusb_submit_control_transfer]
> will use interface 0
> [ 3.136180] [00000c68] libusbx: debug [usbi_add_pollfd] add fd 4 events 1
> [ 3.136180] [00000c68] libusbx: debug [libusb_get_next_timeout] next
> timeout in 4.999669s
> [ 3.136180] [00000c68] libusbx: debug
> [libusb_handle_events_timeout_completed] doing our own event handling
> [ 3.136180] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
> timeout in 5000ms
> [ 8.136466] [00000c68] libusbx: debug [handle_events] poll() returned 0
> [ 8.136466] [00000c68] libusbx: debug [libusb_cancel_transfer]
> [ 8.136466] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
> with timeout or all handled by OS; no timeout!
> [ 8.136466] [00000c68] libusbx: debug
> [libusb_handle_events_timeout_completed] doing our own event handling
> [ 8.136466] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
> timeout in 60000ms
> [68.136898] [00000c68] libusbx: debug [handle_events] poll() returned 0
> [68.136898] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
> with timeout or all handled by OS; no timeout!
> [68.136898] [00000c68] libusbx: debug
> [libusb_handle_events_timeout_completed] doing our own event handling
> [68.136898] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
> timeout in 60000ms
> [128.137329] [00000c68] libusbx: debug [handle_events] poll() returned 0
> [128.137329] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
> with timeout or all handled by OS; no timeout!
> [128.137329] [00000c68] libusbx: debug
> [libusb_handle_events_timeout_completed] doing our own event handling
> [128.137329] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
> timeout in 60000ms
>
> It keeps on printing after every 6000ms.
>
> Any idea what this means ?
>
>
> Thanks
>
>
>
>
>
> On Mon, Jun 30, 2014 at 12:06 PM, dineshkumar muthusamy <
> dsp...@gm...> wrote:
>
>> Hi,
>> In this case I would suggest to either use some use some debug trace or
>> USB protocol analyzer or enable highest level of debug info in libusb. i.e.
>>
>> void libusb_set_debug(libusb_context
>> <http://libusb.sourceforge.net/api-1.0/group__lib.html#ga4ec088aa7b79c4a9599e39bf36a72833>
>>  *  ctx, int level ) enum   libusb_log_level
>> <http://libusb.sourceforge.net/api-1.0/group__lib.html#ga2d6144203f0fc6d373677f6e2e89d2d2>
>>  {
>>   *LIBUSB_LOG_LEVEL_NONE* = 0, *LIBUSB_LOG_LEVEL_ERROR*,
>> *LIBUSB_LOG_LEVEL_WARNING*, *LIBUSB_LOG_LEVEL_INFO*,
>>   *LIBUSB_LOG_LEVEL_DEBUG*
>> }
>>
>> I hope this will give you some more info to debug.
>>
>> *Regards,*
>> *Dinesh.*
>>
>>
>> On Mon, Jun 30, 2014 at 8:05 AM, Thejus.. <mee...@gm...> wrote:
>>
>>> Hi All,
>>>
>>> I am trying run some tests using a custom usb3.0 device on a Windows 7
>>> machine. This device has been loaded onto a FPGA board and I am trying to
>>> access this device using a cygwin environment. I have also installed WinUSB
>>> driver(v6.1.7600.16385) using Zadig.
>>>
>>> Device is able to detect itself and on giving lsusb I am able to see it
>>> with VID?PID and the name. This means that the there is no issue with
>>> driver,right ?
>>>
>>> But on running the test I see the test getting stuck on doing the FIRST
>>> libusb_control_transfer. It doesn't print anything after that and remains
>>> stuck (not even a timeout)
>>>
>>> This is what I do in the test before sending that control transfer :
>>> 1. libusb_init()
>>> 2. libusb_open_device_with_vid_pid()
>>> 3. libusb_kernel_drive_active()
>>> 4. libusb_set_configuration()
>>> 5. libusb_claim_interface().
>>>
>>> 6. Call libusb_control_transfer(*)
>>>
>>> All these steps are being processed and I am able to claim the interface
>>> as well but when I try to call libsub_control_transfer() it gets stuck. I
>>> tried debugging using gdb but couldn't figure out much.
>>>
>>> Any idea what might be going wrong OR how to go about debugging the
>>> issue ?
>>>
>>>
>>> Note: This same test works completely fine on Linux !
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Open source business process management suite built on Java and Eclipse
>>> Turn processes into business applications with Bonita BPM Community
>>> Edition
>>> Quickly connect people, data, and systems into organized workflows
>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>> http://p.sf.net/sfu/Bonitasoft
>>> _______________________________________________
>>> libusb-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Dineshkumar M.
>>
>
>


-- 
Best regards,
Dineshkumar M.

Thanks Dinesh !

Also I had set the level to 3 initially and this is what I see when I
change it to 4

INFO: Claimed Device Interface 0
INFO: Transfer Size-0 : 1024
INFO:Programming IN data generator for endpoint 1 with seed value
706050403020100
[ 3.135180] [00000c68] libusbx: debug [winusb_submit_control_transfer] will
use interface 0
[ 3.136180] [00000c68] libusbx: debug [usbi_add_pollfd] add fd 4 events 1
[ 3.136180] [00000c68] libusbx: debug [libusb_get_next_timeout] next
timeout in 4.999669s
[ 3.136180] [00000c68] libusbx: debug
[libusb_handle_events_timeout_completed] doing our own event handling
[ 3.136180] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
timeout in 5000ms
[ 8.136466] [00000c68] libusbx: debug [handle_events] poll() returned 0
[ 8.136466] [00000c68] libusbx: debug [libusb_cancel_transfer]
[ 8.136466] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB with
timeout or all handled by OS; no timeout!
[ 8.136466] [00000c68] libusbx: debug
[libusb_handle_events_timeout_completed] doing our own event handling
[ 8.136466] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
timeout in 60000ms
[68.136898] [00000c68] libusbx: debug [handle_events] poll() returned 0
[68.136898] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB with
timeout or all handled by OS; no timeout!
[68.136898] [00000c68] libusbx: debug
[libusb_handle_events_timeout_completed] doing our own event handling
[68.136898] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
timeout in 60000ms
[128.137329] [00000c68] libusbx: debug [handle_events] poll() returned 0
[128.137329] [00000c68] libusbx: debug [libusb_get_next_timeout] no URB
with timeout or all handled by OS; no timeout!
[128.137329] [00000c68] libusbx: debug
[libusb_handle_events_timeout_completed] doing our own event handling
[128.137329] [00000c68] libusbx: debug [handle_events] poll() 2 fds with
timeout in 60000ms

It keeps on printing after every 6000ms.

Any idea what this means ?


Thanks





On Mon, Jun 30, 2014 at 12:06 PM, dineshkumar muthusamy <
dsp...@gm...> wrote:

> Hi,
> In this case I would suggest to either use some use some debug trace or
> USB protocol analyzer or enable highest level of debug info in libusb. i.e.
>
> void libusb_set_debug(libusb_context
> <http://libusb.sourceforge.net/api-1.0/group__lib.html#ga4ec088aa7b79c4a9599e39bf36a72833>
>  *  ctx, int level ) enum   libusb_log_level
> <http://libusb.sourceforge.net/api-1.0/group__lib.html#ga2d6144203f0fc6d373677f6e2e89d2d2>
>  {
>   *LIBUSB_LOG_LEVEL_NONE* = 0, *LIBUSB_LOG_LEVEL_ERROR*,
> *LIBUSB_LOG_LEVEL_WARNING*, *LIBUSB_LOG_LEVEL_INFO*,
>   *LIBUSB_LOG_LEVEL_DEBUG*
> }
>
> I hope this will give you some more info to debug.
>
> *Regards,*
> *Dinesh.*
>
>
> On Mon, Jun 30, 2014 at 8:05 AM, Thejus.. <mee...@gm...> wrote:
>
>> Hi All,
>>
>> I am trying run some tests using a custom usb3.0 device on a Windows 7
>> machine. This device has been loaded onto a FPGA board and I am trying to
>> access this device using a cygwin environment. I have also installed WinUSB
>> driver(v6.1.7600.16385) using Zadig.
>>
>> Device is able to detect itself and on giving lsusb I am able to see it
>> with VID?PID and the name. This means that the there is no issue with
>> driver,right ?
>>
>> But on running the test I see the test getting stuck on doing the FIRST
>> libusb_control_transfer. It doesn't print anything after that and remains
>> stuck (not even a timeout)
>>
>> This is what I do in the test before sending that control transfer :
>> 1. libusb_init()
>> 2. libusb_open_device_with_vid_pid()
>> 3. libusb_kernel_drive_active()
>> 4. libusb_set_configuration()
>> 5. libusb_claim_interface().
>>
>> 6. Call libusb_control_transfer(*)
>>
>> All these steps are being processed and I am able to claim the interface
>> as well but when I try to call libsub_control_transfer() it gets stuck. I
>> tried debugging using gdb but couldn't figure out much.
>>
>> Any idea what might be going wrong OR how to go about debugging the issue
>> ?
>>
>>
>> Note: This same test works completely fine on Linux !
>>
>>
>> Thanks,
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community
>> Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> libusb-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>>
>>
>
>
> --
> Best regards,
> Dineshkumar M.
>

Hi,
In this case I would suggest to either use some use some debug trace or USB
protocol analyzer or enable highest level of debug info in libusb. i.e.

void libusb_set_debug(libusb_context
<http://libusb.sourceforge.net/api-1.0/group__lib.html#ga4ec088aa7b79c4a9599e39bf36a72833>
 * ctx,int level )enum  libusb_log_level
<http://libusb.sourceforge.net/api-1.0/group__lib.html#ga2d6144203f0fc6d373677f6e2e89d2d2>
 {
  *LIBUSB_LOG_LEVEL_NONE* = 0, *LIBUSB_LOG_LEVEL_ERROR*,
*LIBUSB_LOG_LEVEL_WARNING*, *LIBUSB_LOG_LEVEL_INFO*,
  *LIBUSB_LOG_LEVEL_DEBUG*
}

I hope this will give you some more info to debug.

*Regards,*
*Dinesh.*


On Mon, Jun 30, 2014 at 8:05 AM, Thejus.. <mee...@gm...> wrote:

> Hi All,
>
> I am trying run some tests using a custom usb3.0 device on a Windows 7
> machine. This device has been loaded onto a FPGA board and I am trying to
> access this device using a cygwin environment. I have also installed WinUSB
> driver(v6.1.7600.16385) using Zadig.
>
> Device is able to detect itself and on giving lsusb I am able to see it
> with VID?PID and the name. This means that the there is no issue with
> driver,right ?
>
> But on running the test I see the test getting stuck on doing the FIRST
> libusb_control_transfer. It doesn't print anything after that and remains
> stuck (not even a timeout)
>
> This is what I do in the test before sending that control transfer :
> 1. libusb_init()
> 2. libusb_open_device_with_vid_pid()
> 3. libusb_kernel_drive_active()
> 4. libusb_set_configuration()
> 5. libusb_claim_interface().
>
> 6. Call libusb_control_transfer(*)
>
> All these steps are being processed and I am able to claim the interface
> as well but when I try to call libsub_control_transfer() it gets stuck. I
> tried debugging using gdb but couldn't figure out much.
>
> Any idea what might be going wrong OR how to go about debugging the issue ?
>
>
> Note: This same test works completely fine on Linux !
>
>
> Thanks,
>
>
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>


-- 
Best regards,
Dineshkumar M.

+Adding one more point

I am getting this error when I try to compile my code in Cygwin on Windows
environment.

gcc -g -O2 -Wall -lm -I/usr/local/include/libusb-1.0 -I. -I../api
-L/usr/local/lib/ -L../api -c ../api/AtekInclude.c -lusb-1.0
../api/AtekInclude.c:31:20: fatal error: sys/io.h: No such file or directory

Any idea ? What should I do to fix this ?


Thanks,



On Mon, Jun 30, 2014 at 11:35 AM, Thejus.. <mee...@gm...> wrote:

> Hi All,
>
> I am trying run some tests using a custom usb3.0 device on a Windows 7
> machine. This device has been loaded onto a FPGA board and I am trying to
> access this device using a cygwin environment. I have also installed WinUSB
> driver(v6.1.7600.16385) using Zadig.
>
> Device is able to detect itself and on giving lsusb I am able to see it
> with VID?PID and the name. This means that the there is no issue with
> driver,right ?
>
> But on running the test I see the test getting stuck on doing the FIRST
> libusb_control_transfer. It doesn't print anything after that and remains
> stuck (not even a timeout)
>
> This is what I do in the test before sending that control transfer :
> 1. libusb_init()
> 2. libusb_open_device_with_vid_pid()
> 3. libusb_kernel_drive_active()
> 4. libusb_set_configuration()
> 5. libusb_claim_interface().
>
> 6. Call libusb_control_transfer(*)
>
> All these steps are being processed and I am able to claim the interface
> as well but when I try to call libsub_control_transfer() it gets stuck. I
> tried debugging using gdb but couldn't figure out much.
>
> Any idea what might be going wrong OR how to go about debugging the issue ?
>
>
> Note: This same test works completely fine on Linux !
>
>
> Thanks,
>
>
>
>

Hi All,

I am trying run some tests using a custom usb3.0 device on a Windows 7
machine. This device has been loaded onto a FPGA board and I am trying to
access this device using a cygwin environment. I have also installed WinUSB
driver(v6.1.7600.16385) using Zadig.

Device is able to detect itself and on giving lsusb I am able to see it
with VID?PID and the name. This means that the there is no issue with
driver,right ?

But on running the test I see the test getting stuck on doing the FIRST
libusb_control_transfer. It doesn't print anything after that and remains
stuck (not even a timeout)

This is what I do in the test before sending that control transfer :
1. libusb_init()
2. libusb_open_device_with_vid_pid()
3. libusb_kernel_drive_active()
4. libusb_set_configuration()
5. libusb_claim_interface().

6. Call libusb_control_transfer(*)

All these steps are being processed and I am able to claim the interface as
well but when I try to call libsub_control_transfer() it gets stuck. I
tried debugging using gdb but couldn't figure out much.

Any idea what might be going wrong OR how to go about debugging the issue ?


Note: This same test works completely fine on Linux !


Thanks,

Hello, 

I tried to search for nearly 2 hours about this, but couldn't find anything. 

I have separate threads for send and recieve. Send is pretty
straightforward, but i have problem with receive. 

I'm using libusb 1.0.19, windows 7 and asynchronous API, bulk transfer. 

When I'm calling usb transfer on endpoint IN transfer ends succesfully if
nothing is to read. That is triggering a lot of interrupts on my device,
which is actually a problem. 

What is the proper way to check if there is something to read before
starting the transfer?

Seems that libusb_get_pollfds is not implemented on Windows, so I can't use
it. 

Thanks in advance!



--
View this message in context: http://libusb.6.n5.nabble.com/LIBUSB-proper-receive-thread-tp5713409.html
Sent from the LibUSB Dev mailing list archive at Nabble.com.

On Mon, Jun 23, 2014 at 10:50 AM, Tim Roberts <ti...@pr...> wrote:
>
> Did you check the API documentation?  The last parameter to usb_control_msg is the timeout in milliseconds.

TNX for the hint.  I've tried to increase the timeout, It did not help.

> To a certain extent, however, I am just blowing smoke.  Control messages usually complete very quickly.  Your symptoms seem to indicate some more fundamental problem, and I don't know what to suggest.

Since I am not a programmer,  I really do not know how to proceed from
here. In any case, thanks for the help.
>
> One of the advantages of libusb is that it crosses platforms.  Why don't you run your code on Windows?

Yes I could,,, but I wrote already few other utilities on LINUX
(mostly GPIB related). I would like to continue on Linux. On top of
that, licensing is free, no virues,  upgrading linux require just a
recompile of my utilities, stability, reliability, abundance of
programming/scripting tools   so, the users can use my utilities
within any programming environment they are comfortable with. Like
octave, shells,c, C++, Ruby, Perl, Pascal adn as a command line.
Working remotely is a plus...  etc ..    Stuff I wrote in 2002/03 in
my former company is still in use today, 12 years later. It was
written for RedHat 8 2012 and just recompiled on CentOS 6.





-- 
"You can't run an economy where the financial sector is making 40
percent of the profits."


        former Fed Chairman Paul Volcker 2009

On Sun, Jun 22, 2014 at 11:41 PM, Tim Roberts <ti...@pr...> wrote:

> On Jun 22, 2014, at 1:00 PM, Igor Furlan <igo...@gm...> wrote:
> .
> > It returns -110 (aka it fails).
>
> You know that -110 tells you more than just “it fails”, right?  Errno 110
> is ETIMEDOUT.  Do you have a very short timeout?  Timing in a VM is
> somewhat “flexible”.
>

​No, I did not know. To be honest with you, I did not look for. My bad.
Sorry.

About "​Do you have a very short timeout?"
    I do not know. How do I change (increase) the 'timeout' ?

> I am running this on a CentOS 6.5 as the __guest__ using VirtualBOX
>​on
​ ​
WIN7 as the host.
> Running the program on CentOS 6.5 on  REAL hardware works flawlessly.

At some point, you have to decide what this is worth to you.  Some of the
> VM managers don’t do a perfect job of USB forwarding.


​Yes, I was afraid about that. Unfortunately, not using VM​

​ would be a major setback. In a company I work, we do not want to have in
a lab too many PCs on benches. But, all of the app engineers do have MS
Windows desktops/laptops​. So, using VM, with Lunux installed, is a nice
solution. I was able to make GPIB working with GPIB-USB addapter (Agilent
and National Instrument).


-- 
"You can't run an economy where the financial sector is making 40 percent
of the profits."


   former Fed Chairman Paul Volcker 2009

Tim, thanks for the reply.


I've removed the call to usb_set_configuration. The Error message went away.

Now I am facing another problem.

A call to  usb_claim_interface returns 0 (meaning call was OK).

The next call, after the usb_claim_interface, is a call to usb_control_msg.

It returns -110 (aka it fails).

What should I do to debug this ?
Or, even better, what should I do to make this call pass ?

Igor

P.S:

Reminder:
I am running this on a CentOS 6.5 as the __guest__ using VirtualBOX on
WIN7 as the host.

Running the program on CentOS 6.5 on  REAL hardware works flawlessly.

I am trying to run I2C interface board
(http://nanorivertech.com/viperboard.html) on CentOS 6.5 installed on
virtual machine (VirtualBox) which runs on MS WINDOWS 7.

When I run my small CLI program, I get back

libusb: error [op_set_configuration] failed, error -1 errno 110
libusb: error [submit_bulk_transfer] submiturb failed error -1 errno=2
libusb: error [submit_bulk_transfer] submiturb failed error -1 errno=2

The very same CLI program runs flawlessly on CentOS 6.5 on  real
hardware. It runs on 32-bit and 64-bit machine.

The offending code snippet is:

ret = usb_set_configuration(usb_handle, 1);
usb_claim_interface(usb_handle, 0);
 /* Flush any remaining bulk transfers pendings */
ret = usb_bulk_read(usb_handle, 0x86, buf, 512, 10);
ret = usb_bulk_read(usb_handle, 0x86, buf, 512, 10);


SOFTWARE:
 libusb-1.0.19
 libusb-compat-0.1.5

No, I can __not__  convert the source code for my CLI program to use
ONLY the libusb and not libusb-compat.


Igor

Hello

I am using android ndk standalone toolchain for cross-compilation of libusb
on android.
I have been having a problem with libusb while cross compilation on
android. I traced it to a -c option in Libs.private in libusb-1.0.pc file.
This was set in configure.ac script specially for android. But it is
misinterpreted as "Compile and assemble don't link" option of gcc.
I think this is not what was intended by this flag. I have attached a patch
removing this option.
Please look into it.

Regards

Venkatesh Shukla

 Thanks for yor help. Yes, I have to call something like libusb_handle_events to make it work. Also, you're right, the stream seems to be not needed. Now it works well.

Yuri.

Fri, 20 Jun 2014 09:27:47 -0700 от Tim Roberts <ti...@pr...>:
>yur70 wrote:
>>But it is never called. The program just waits for a keypress
>>Indefinitely. 
>>What am I doing wrong? Is there any simple example on how to use the
>>asynchronous transfer?
>
>The key is that your callback is not called automatically.  There's no one around to call it.  Instead, you have to call libusb_wait_for_events in a loop.  That function polls to see which request have completed, and will call the callback.  There are examples of this in the libusb documentation.
>
>>In particular, I would be also interested in bulk_stream_transfer,..
>
>No, you aren't.  Really.  Bulk streams are a rather complicated modification to the spec that was added in USB 3.0, specifically at the request of the USB Mass Storage people.  At this point, they are basically the only user of that technology, and it's hard to think of any other good application.
>--
>Tim Roberts,  ti...@pr...
>Providenza & Boekelheide, Inc.
>------------------------------------------------------------------------------
>HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>Find What Matters Most in Your Big Data with HPCC Systems
>Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>http://p.sf.net/sfu/hpccsystems
>_______________________________________________
>libusb-devel mailing list
>lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libusb-devel

yur70 wrote:
>But it is never called. The program just waits for a keypress
>Indefinitely. 
>What am I doing wrong? Is there any simple example on how to use the
>asynchronous transfer?

The key is that your callback is not called automatically.  There's no one around to call it.  Instead, you have to call libusb_wait_for_events in a loop.  That function polls to see which request have completed, and will call the callback.  There are examples of this in the libusb documentation.

>In particular, I would be also interested in bulk_stream_transfer,..

No, you aren't.  Really.  Bulk streams are a rather complicated modification to the spec that was added in USB 3.0, specifically at the request of the USB Mass Storage people.  At this point, they are basically the only user of that technology, and it's hard to think of any other good application.
--
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Dear libusb developers,

I'm trying to use the synchronous i/o on my device, but didn't find any 
detailed information in the documentation on how to properly use it.

My USB device sends some data on endpoint 0x86 at a constant rate.

I can read it like this:

--------
   int res = libusb_bulk_transfer(h1, 0x86, buf, 1024*1024, 
&transferred, 1000);
   cout << "result 0x86: " << res << " " << transferred << endl;
--------

Output:
result 0x86: 0 1048576

As I understand, this is the synchronous transfer. My problem is that 
the rate is rather high, so that in a single call to 
libusb_bulk_transfer there is no data loss, but if I call it several 
times, the data are lost between the calls. I suppose that this problem 
can be somehow solved with a series of asynchronous transfers (or 
streams), but I cannot even start this because the information in the 
documentation is rather scarce.

To do the same asynchronously I use:

--------
   transfer = libusb_alloc_transfer(0);
   libusb_fill_bulk_transfer(transfer, h1, 0x86, buf, 1024*1024, cback, 
NULL, 1000);
   libusb_submit_transfer(transfer);
   int ch = getch(); //wait for a key press
   cyusb_close(); //close usb device
--------

My callback function looks like this:
--------
void cback(struct libusb_transfer *transfer) {
   cout << "cback !!!!!" << endl;
}
--------

But it is never called. The program just waits for a keypress 
indefinitely. Moreover, if I break it with Ctrl C (i.e. without closing 
the usb device), I get the "kernel panic" message and the computer is 
"dead". I'm using linux Mint 17, libusb-1.0.19.

What am I doing wrong? Is there any simple example on how to use the 
asynchronous transfer? In particular, I would be also interested in 
bulk_stream_transfer, for which I basically didn't find any information 
in the documentation.

Thank you,
Yuri.

On 06/20/2014 02:12 AM, Sam Crumpet wrote:
> I installed libusb to use AVRdude programmer with AVRISPMK2.
> 
> It worked well, but now I want to remove it so I can use AVRstudio Jungo
> drivers again.
> There appears to be no way to remove the class.  I have been through the
> registry etc.
> Everytime I plug in an AVRispmk2 (even new ones my computer has never
> seen), it comes up as libusb class and asks for libusb0.sys.
> 
> I have tried removing and reinstalling AVRstudio and the Jungo drivers.
> 
> This is worse then a virus, it appears that I have to format my hard
> drive to get rid of it!
> 
> I am running XP.  I tried usbdevview but that didnt help me at all.

It should be possible to remove the driver trough the Device Manager:

1. Open Device Manager

2. Under Universal Serial Bus devices (or possibly libusbk
devices/libusb-win32 devices if you didn't pick WinUSB as your driver),
right click on your device.

3. Select Uninstall and on the dialog box that appears, check the box
that says Delete the driver software for this device then click OK.

4. Once the uninstallation is complete, unplug and replug your device.
The previous driver should be now be reinstalled.

I didn't try this myself however, I got it from
https://github.com/pbatard/libwdi/wiki/FAQ#Help_Zadig_replaced_the_driver_for_the_wrong_device_How_do_I_restore_it

Regards,
Another Sam

Thanks for the detailed explanation. Let me try updating driver.


On Thu, Jun 19, 2014 at 10:36 PM, Pete Batard <pe...@ak...> wrote:

> Hi Dinesh,
>
> On 2014.06.19 11:53, dineshkumar muthusamy wrote:
> > Please find attached the log file form the PC that has ASMedia
> > controller. This log file is obtined by executing 'xusb -d'.
>
> Thanks.
>
> >  From the log file and the libusb source code I could understand that
> > ASMedia hub name is received/obtained from dirver as "asmthub3" and in
> > the libusb/os/windows_usb.c the string expected is "ASMTHUB3".
>
> We're ignoring the case when comparing the strings (obviously) so it
> doesn't matter. Your log actually indicates that everything is fine there:
>
>  > [ 0.071004] [00002a0c] libusb: debug [get_api_type] driver(s): asmthub3
>  > [ 0.071004] [00002a0c] libusb: debug [get_api_type] matched driver
> name against HUB API
>
> If you get a "matched driver name against HUB API", it means we found a
> match for the hub driver name in our list, and indeed, "ASMTHUB3" is
> there, as I mentioned previously.
>
> > If so what is the correct way to fix it ?
>
> Your customer issue doesn't appear to have anything to do with the hub
> name not being in our list. Instead, I believe this:
>
>  >  0.101005] [00002a0c] libusb: error [init_device] device
> '\\.\USB#VID_0409&PID_005A&ASMEDIAUSBD_HUB#6&355085E&0&4' is no longer
> connected!
>
> is probably where the error comes from.
>
> The error means that after we sent an
> IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX to the hub, to get some
> data about the devices connected to it, we got some data missing:
> https://github.com/libusb/libusb/blob/master/libusb/os/windows_usb.c#L1263
>
> Since it's really up to the hub driver to populate the connection
> information data with proper values, and every USB 3.0 xHCD manufacturer
> had to write their own custom driver for that, with variable amount of
> testing when it comes to IOCTLs (which we've seen with other
> manufacturers), my guess is that the ASMedia developers didn't implement
> IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX properly, and thus we can't
> get the data we need to enumerate the devices on that hub.
>
> If there are any driver updates for that ASMedia USB 3.0 controllers,
> now would be a good time to upgrade and see it it improves things.
>
> If not, you might want to engage with ASMedia support and ask them if
> they are aware of any issues when issuing an
> IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX to their USB 3.0 hub driver
> and especially when filling the conn_info.ConnectionStatus attribute...
>
> Regards,
>
> /Pete
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>



-- 
Best regards,
Dineshkumar M.

I installed libusb to use AVRdude programmer with AVRISPMK2.

It worked well, but now I want to remove it so I can use AVRstudio Jungo drivers again.
There appears to be no way to remove the class.  I have been through the registry etc.
Everytime I plug in an AVRispmk2 (even new ones my computer has never seen), it comes up as libusb class and asks for libusb0.sys.

I have tried removing and reinstalling AVRstudio and the Jungo drivers.

This is worse then a virus, it appears that I have to format my hard drive to get rid of it!

I am running XP.  I tried usbdevview but that didnt help me at all.

-Sam

 		 	   		  

Hi Dinesh,

On 2014.06.19 11:53, dineshkumar muthusamy wrote:
> Please find attached the log file form the PC that has ASMedia
> controller. This log file is obtined by executing 'xusb -d'.

Thanks.

>  From the log file and the libusb source code I could understand that
> ASMedia hub name is received/obtained from dirver as "asmthub3" and in
> the libusb/os/windows_usb.c the string expected is "ASMTHUB3".

We're ignoring the case when comparing the strings (obviously) so it 
doesn't matter. Your log actually indicates that everything is fine there:

 > [ 0.071004] [00002a0c] libusb: debug [get_api_type] driver(s): asmthub3
 > [ 0.071004] [00002a0c] libusb: debug [get_api_type] matched driver 
name against HUB API

If you get a "matched driver name against HUB API", it means we found a 
match for the hub driver name in our list, and indeed, "ASMTHUB3" is 
there, as I mentioned previously.

> If so what is the correct way to fix it ?

Your customer issue doesn't appear to have anything to do with the hub 
name not being in our list. Instead, I believe this:

 >  0.101005] [00002a0c] libusb: error [init_device] device 
'\\.\USB#VID_0409&PID_005A&ASMEDIAUSBD_HUB#6&355085E&0&4' is no longer 
connected!

is probably where the error comes from.

The error means that after we sent an 
IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX to the hub, to get some 
data about the devices connected to it, we got some data missing:
https://github.com/libusb/libusb/blob/master/libusb/os/windows_usb.c#L1263

Since it's really up to the hub driver to populate the connection 
information data with proper values, and every USB 3.0 xHCD manufacturer 
had to write their own custom driver for that, with variable amount of 
testing when it comes to IOCTLs (which we've seen with other 
manufacturers), my guess is that the ASMedia developers didn't implement 
IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX properly, and thus we can't 
get the data we need to enumerate the devices on that hub.

If there are any driver updates for that ASMedia USB 3.0 controllers, 
now would be a good time to upgrade and see it it improves things.

If not, you might want to engage with ASMedia support and ask them if 
they are aware of any issues when issuing an 
IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX to their USB 3.0 hub driver 
and especially when filling the conn_info.ConnectionStatus attribute...

Regards,

/Pete

On 06/19/2014 05:22 PM, Hans de Goede wrote:
> Hi,
> 
> Thanks for the detailed bug report!

Thanks. The more details the faster you get help ;)
So, thanks for the fast and helpful reply!

> 
> On 06/19/2014 04:29 PM, Samuel Bryner wrote:
>> Hi,
>>
>> I get a crash in os/linux_usbfs.c (line 2594) when I do the following:
>>
>> 1. connect to a FTDI based device
>>    (tested with an FT234XS (0403:6015) and FT2232H (0403:6010))
>> 2. register a hotplug-detach callback which calls libusb_close()
>> 3. wait with select() for file descriptors from libusb_get_pollfds()
>>
>> After I physically disconnect the device and the handler was called
>> (closes the device), libusb_handle_events() reliabely crashes with a
>> SEGFAULT.
>>
>> Some general information:
>>
>> Kernel: 3.14.6-200.fc20.x86_64 (on a Lenovo Thinkpad T400)
>> glibc: 2.18
>> libusb: 1.0.19-rc1
>> gcc: 4.8.2 20131212 (Red Hat 4.8.2-7)
>>
>> See attachments for a log and backtrace. Also attached is an example
>> program (derived from examples/hotplugtest.c). Start it, connect and
>> disconnect a FTDI and it should crash.
>>
>> If you're not familiar with FTDI's chips: They provide a serial port and
>> are running a commercial firmware. The descriptor strings are custom and
>> can be configured over USB.
>>
>> This seems somewhat related:
>> http://sourceforge.net/p/libusb/mailman/message/32256941/
> 
> Interesting it seems that the udev unplug event and the POLLERR on the usbfs fd
> end up being caught in the same poll() call in your case, causing this
> issue.
> 
> This bug was actually caught by Coverity and is fixed in this commit:
> https://github.com/libusb/libusb/commit/d7e763e277db4ecafa66f20684ab751e680b0557
> 
>> The crash disappears when I run the code as root. Permissions:
>>
>> crw-rw----. 1 root dialout 188,   0 19. Jun 16:08 /dev/ttyUSB0
>> crw-rw-r--. 1 root plugdev 189, 332 19. Jun 16:08 /dev/bus/usb/003/077
>>
>> I am member of plugdev and dialout, so this should work.
> 
> It is a bit weird that it works as root, but this is a race, so it is
> expected to be a bit hit and miss really.
> 
>> I also tested the example with the latest libusb version from git
>> (e11525c66c7dd2db466c8f5785ff0b37d6a99ec9) with the same result.
> 
> Looking at your backtrace it seems that you're not running the code you
> think you are running:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000031e520dc94 in op_handle_events (ctx=0x603030, fds=0x603770, nfds=4, num_ready=0) at os/linux_usbfs.c:2594
> 2594				usbi_remove_pollfd(HANDLE_CTX(handle), hpriv->fd);
> 
> After the commit I linked above that is no longer line 2594, so this bt
> appears to be from code before the fix.

Yes, I mainly tested it with libusb 1.0.19-rc1.

> 
> Perhaps you've multiple copies of libusb installed one in /usr/lib and one in /usr/local/lib ?
> 
> Try running ldd on your test binary to see which libusb it is actually
> using.
> 

When I tried it with the git version I explicitely linked the library
with 'gcc ... libusb/.libs/libusb-1.0.so', but appearantly this didn't
work as expected. Now that I think of it all this does is link the
library dynamically, it still loads the system's library on execution.

Oh well, one 'sudo make install' later and the issue is fixed.

Thank you very much!

So long,
Sam

Hi,

Thanks for the detailed bug report!

On 06/19/2014 04:29 PM, Samuel Bryner wrote:
> Hi,
> 
> I get a crash in os/linux_usbfs.c (line 2594) when I do the following:
> 
> 1. connect to a FTDI based device
>    (tested with an FT234XS (0403:6015) and FT2232H (0403:6010))
> 2. register a hotplug-detach callback which calls libusb_close()
> 3. wait with select() for file descriptors from libusb_get_pollfds()
> 
> After I physically disconnect the device and the handler was called
> (closes the device), libusb_handle_events() reliabely crashes with a
> SEGFAULT.
> 
> Some general information:
> 
> Kernel: 3.14.6-200.fc20.x86_64 (on a Lenovo Thinkpad T400)
> glibc: 2.18
> libusb: 1.0.19-rc1
> gcc: 4.8.2 20131212 (Red Hat 4.8.2-7)
> 
> See attachments for a log and backtrace. Also attached is an example
> program (derived from examples/hotplugtest.c). Start it, connect and
> disconnect a FTDI and it should crash.
> 
> If you're not familiar with FTDI's chips: They provide a serial port and
> are running a commercial firmware. The descriptor strings are custom and
> can be configured over USB.
> 
> This seems somewhat related:
> http://sourceforge.net/p/libusb/mailman/message/32256941/

Interesting it seems that the udev unplug event and the POLLERR on the usbfs fd
end up being caught in the same poll() call in your case, causing this
issue.

This bug was actually caught by Coverity and is fixed in this commit:
https://github.com/libusb/libusb/commit/d7e763e277db4ecafa66f20684ab751e680b0557

> The crash disappears when I run the code as root. Permissions:
> 
> crw-rw----. 1 root dialout 188,   0 19. Jun 16:08 /dev/ttyUSB0
> crw-rw-r--. 1 root plugdev 189, 332 19. Jun 16:08 /dev/bus/usb/003/077
> 
> I am member of plugdev and dialout, so this should work.

It is a bit weird that it works as root, but this is a race, so it is
expected to be a bit hit and miss really.

> I also tested the example with the latest libusb version from git
> (e11525c66c7dd2db466c8f5785ff0b37d6a99ec9) with the same result.

Looking at your backtrace it seems that you're not running the code you
think you are running:

Program received signal SIGSEGV, Segmentation fault.
0x00000031e520dc94 in op_handle_events (ctx=0x603030, fds=0x603770, nfds=4, num_ready=0) at os/linux_usbfs.c:2594
2594				usbi_remove_pollfd(HANDLE_CTX(handle), hpriv->fd);

After the commit I linked above that is no longer line 2594, so this bt
appears to be from code before the fix.

Perhaps you've multiple copies of libusb installed one in /usr/lib and one in /usr/local/lib ?

Try running ldd on your test binary to see which libusb it is actually
using.

Regards,

Hans

Hi,

I get a crash in os/linux_usbfs.c (line 2594) when I do the following:

1. connect to a FTDI based device
   (tested with an FT234XS (0403:6015) and FT2232H (0403:6010))
2. register a hotplug-detach callback which calls libusb_close()
3. wait with select() for file descriptors from libusb_get_pollfds()

After I physically disconnect the device and the handler was called
(closes the device), libusb_handle_events() reliabely crashes with a
SEGFAULT.

Some general information:

Kernel: 3.14.6-200.fc20.x86_64 (on a Lenovo Thinkpad T400)
glibc: 2.18
libusb: 1.0.19-rc1
gcc: 4.8.2 20131212 (Red Hat 4.8.2-7)

See attachments for a log and backtrace. Also attached is an example
program (derived from examples/hotplugtest.c). Start it, connect and
disconnect a FTDI and it should crash.

If you're not familiar with FTDI's chips: They provide a serial port and
are running a commercial firmware. The descriptor strings are custom and
can be configured over USB.

This seems somewhat related:
http://sourceforge.net/p/libusb/mailman/message/32256941/

The crash disappears when I run the code as root. Permissions:

crw-rw----. 1 root dialout 188,   0 19. Jun 16:08 /dev/ttyUSB0
crw-rw-r--. 1 root plugdev 189, 332 19. Jun 16:08 /dev/bus/usb/003/077

I am member of plugdev and dialout, so this should work.

I also tested the example with the latest libusb version from git
(e11525c66c7dd2db466c8f5785ff0b37d6a99ec9) with the same result.

Cheers,
Sam

Thank you so-much, your information really helpful for me... thanks
again.... when I get what I want I will post..


On Wed, Jun 18, 2014 at 6:20 PM, Hans de Goede <hde...@re...> wrote:

> Hi,
>
> Tejas Virpariya wrote:
> > I am firmware engineer and I have to develop one application in this
> > application I want name of external usb drive of it's path when it
> > connected, for that I ask this question in LinkedIn and someone ask me to
> > use libusb, but How that's I don't know, and I want to ask this library
> is
> > really useful in my app?
>
> No.
>
> > In simple way, I want to write C/C++ code in that when usb drive
> connected
> > my code will gave me its name...I will add that name behind /media/ and I
> > will access that drive as I want and as I can.
>
> /media/ sounds like the device your software is supposed to be running on
> is
> running Linux. If that is the case, then for a standard desktop linux
> install
> (using udev for /dev management) you should have a /dev/disk/by-path/
> directory
> which should give you a way to address disks by the exaxt physical path
> leading
> to them, which seems to be exactly what you want.
>
> Regards,
>
> Hans
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>



-- 
Thanks
Tejas Virpariya
http://about.me/er.tejas_virpariya