[Libusbx-devel] bulk transfer error centos 6.5 (32-bit) on VirtualBox running on Windows 7 (64-bit)

[Igor Furlan]

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

[Tim Roberts]

Post by Igor Furlan
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.

Windows does a SetConfiguration when the driver loads. Some hardware doesn’t like getting multiple SetConfiguration requests. Try removing the call to usb_set_configuration.

[Igor Furlan]

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.

[Tim Roberts]

Post by Igor Furlan
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).

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

Post by Igor Furlan
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.

[Igor Furlan]

.

Post by Igor Furlan
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).

[Tim Roberts]

.

Post by Igor Furlan
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' ?

Did you check the API documentation? The last parameter to
usb_control_msg is the timeout in milliseconds.

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.

One of the advantages of libusb is that it crosses platforms. Why don't
you run your code on Windows?

[Igor Furlan]

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.

[Tim Roberts]

Post by Igor Furlan

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.

OK, but you are intentionally overlooking the very important point that
YOUR USERS ARE ALREADY RUNNING WINDOWS. You said this yourself. They
already have licenses. They already have virus checkers. They already
know how to launch programs and interact. They do not know Octave,
bash, Ruby, Perl, or Pascal. You are asking them to run an additional
rather intrusive tool (VirtualBox) so they can run an entirely
unfamiliar environment just so you can feel religiously pure in your
development.

Your upgrade argument is also silly. An upgrade of Windows doesn't
require ANY recompiling of your tools and utilities. The old binaries
just keep on working. Microsoft has spent a vast fortune to ensure that
the Fortune 100 companies don't have to do any work on their
line-of-business tools to slip in an operating system upgrade. Linux
developers, on the other hand, tend to favor purity over compatibility.

Post by Igor Furlan
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're just making stuff up that doesn't have any basis in fact. The
Windows remote access tools are just as good or better than the remote
access tools on Linux. I'm still running Windows tools that I wrote and
last compiled in 1995. Now that I'm running a 64-bit Windows, my
25-year-old 16-bit tools no longer run, but I've known that was coming
for 10 years.

It's interesting that you tried to use backwards compatibility as an
argument. As a driver writer, I know that Windows has the best
backwards compatibility behavior of ANY of the major operating systems.
The video capture driver BINARIES that I wrote for Windows 98SE way back
in the 20th Century still run in Windows 8. With a Linux kernel driver,
you often don't even get SOURCE compatibility between version x.y.z and
x.y.z+1.

[Igor Furlan]

wow this was a hammer .... thanks for explaining it in clear
profound words I will keep it in mind before write another sentence
to the libusb-devel list.

Thanks and have a nice day

Igor

Post by Tim Roberts

Post by Igor Furlan

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.

OK, but you are intentionally overlooking the very important point that
YOUR USERS ARE ALREADY RUNNING WINDOWS. You said this yourself. They
already have licenses. They already have virus checkers. They already
know how to launch programs and interact. They do not know Octave,
bash, Ruby, Perl, or Pascal. You are asking them to run an additional
rather intrusive tool (VirtualBox) so they can run an entirely
unfamiliar environment just so you can feel religiously pure in your
development.
Your upgrade argument is also silly. An upgrade of Windows doesn't
require ANY recompiling of your tools and utilities. The old binaries
just keep on working. Microsoft has spent a vast fortune to ensure that
the Fortune 100 companies don't have to do any work on their
line-of-business tools to slip in an operating system upgrade. Linux
developers, on the other hand, tend to favor purity over compatibility.

Post by Igor Furlan
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're just making stuff up that doesn't have any basis in fact. The
Windows remote access tools are just as good or better than the remote
access tools on Linux. I'm still running Windows tools that I wrote and
last compiled in 1995. Now that I'm running a 64-bit Windows, my
25-year-old 16-bit tools no longer run, but I've known that was coming
for 10 years.
It's interesting that you tried to use backwards compatibility as an
argument. As a driver writer, I know that Windows has the best
backwards compatibility behavior of ANY of the major operating systems.
The video capture driver BINARIES that I wrote for Windows 98SE way back
in the 20th Century still run in Windows 8. With a Linux kernel driver,
you often don't even get SOURCE compatibility between version x.y.z and
x.y.z+1.
--
Providenza & Boekelheide, Inc.
------------------------------------------------------------------------------
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
_______________________________________________
libusbx-devel mailing list
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

[Kustaa Nyholm]

Well Igor,

Tim put it a bit more bluntly than I perhaps would, I actually
refrained from making a comment ... but your post came across
as Linux evangelism so I'm not surprised that it provoked a
comment... you kind of asked for it.

You may not agree with what Tim wrote but you might still
take away from this that if your users are already using
Windows then using a virtual machine with linux, especially
when you are having problem clearly related to it seems
quite the wrong way to go about it.

And for the record I agree with most what Tim wrote about
Windows though I dislike Windows.

br Kusti

Post by Igor Furlan
wow this was a hammer .... thanks for explaining it in clear
profound words I will keep it in mind before write another sentence
to the libusb-devel list.
Thanks and have a nice day
Igor

Post by Tim Roberts

Post by Igor Furlan

Post by Tim Roberts
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.

OK, but you are intentionally overlooking the very important point that
YOUR USERS ARE ALREADY RUNNING WINDOWS. You said this yourself. They
already have licenses. They already have virus checkers. They already
know how to launch programs and interact. They do not know Octave,
bash, Ruby, Perl, or Pascal. You are asking them to run an additional
rather intrusive tool (VirtualBox) so they can run an entirely
unfamiliar environment just so you can feel religiously pure in your
development.
Your upgrade argument is also silly. An upgrade of Windows doesn't
require ANY recompiling of your tools and utilities. The old binaries
just keep on working. Microsoft has spent a vast fortune to ensure that
the Fortune 100 companies don't have to do any work on their
line-of-business tools to slip in an operating system upgrade. Linux
developers, on the other hand, tend to favor purity over compatibility.

Post by Igor Furlan
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're just making stuff up that doesn't have any basis in fact. The
Windows remote access tools are just as good or better than the remote
access tools on Linux. I'm still running Windows tools that I wrote and
last compiled in 1995. Now that I'm running a 64-bit Windows, my
25-year-old 16-bit tools no longer run, but I've known that was coming
for 10 years.
It's interesting that you tried to use backwards compatibility as an
argument. As a driver writer, I know that Windows has the best
backwards compatibility behavior of ANY of the major operating systems.
The video capture driver BINARIES that I wrote for Windows 98SE way back
in the 20th Century still run in Windows 8. With a Linux kernel driver,
you often don't even get SOURCE compatibility between version x.y.z and
x.y.z+1.
--
Providenza & Boekelheide, Inc.
-------------------------------------------------------------------------
-----
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
_______________________________________________
libusbx-devel mailing list
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

--
"You can't run an economy where the financial sector is making 40
percent of the profits."
former Fed Chairman Paul Volcker 2009
--------------------------------------------------------------------------
----
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
_______________________________________________
libusbx-devel mailing list
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

--
Kustaa Nyholm
Research Manager, Software
Research and Technology Division
PLANMECA OY
Asentajankatu 6
00880 HELSINKI
FINLAND

Please note our new telephone and fax numbers!
Tel: [phone] (direct)
Fax: [phone]
GSM: [phone]
e-mail: ***@planmeca.com






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.