Nabble - LibUSB Dev

[PATCH] libusb 1.0 Windows backend (1/4) : new sources

2009-11-29T11:50:22Z

And this is the final patch in the series to get a Windows version of libusb 1.0x off the ground.

This one contains the new MinGW Windows backend files (to be added in libusb/os).

If you have applied the previous patches to the current tree and have added these files, you should be able to compile libusb as well as the lsusb example on Windows.
Note that you must have pthread-win32 installed (with the pthread.h header available in your include directory) as well as the various autoconf/automake tools needed to run the autogen.sh script

/Pete

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

04_new_sources.zip (17K) Download Attachment

[PATCH] libusb 1.0 Windows backend (3/4) : core files modifications

2009-11-29T11:45:40Z

This is the third patch in the series to get a Windows version of libusb 1.0x off the ground.

This patch contains the necessary changes to the current core files.
Most of it has to do with ditching the requirement for poll.h in order to use the windows_compat version (see next patch) and letting the core source know about the windows backend.

/Pete

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

03_windows_backend_existing.diff (2K) Download Attachment

[PATCH] libusb 1.0 Windows backend (2/4) : Windows support in autoconf/automake

2009-11-29T11:42:52Z

This is the second patch in the series to get a Windows version of libusb 1.0x off the ground.

This one adds the required changes to autoconf/automake to support MinGW. It should not modify any parameters for the other OSes.

/Pete

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

02_automake.diff (2K) Download Attachment

[PATCH] libusb 1.0 Windows backend (1/4) : preliminary MinGW fix

2009-11-29T11:40:45Z

As promised.

This is the first patch in the series to get a Windows version of libusb 1.0x off the ground.

This patch actually has little to do with Windows, but contains fixes needed to avoid the use of "interface" as variables elsewhere in the code. The reason is that MinGW's gcc sees it as a C keyword and produces syntax errors when it sees a variable called interface.

The patch is will not change anything with regards to the behaviour of libusb - all it does is rename a few variables.

/Pete

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

01_interfaces.diff (14K) Download Attachment

Re: libusb 1.0.4 unstable on CentOS/RHEL 5.3

2009-11-29T02:43:43Z

Hi,

After doing some additional investigation, I think that I found a minor problem in libusb 1.0.6 library that explains the experienced phenomenon. The problem essentially lies in the way initialize_device() function treats the case when it's unable to read current USB device configuration. Current code returns negative value in this case, which essentially omits ALL devices on the specific bus from the returned devices list. Instead of that, IMHO it should simply presume that current device's configuration is unknown and proceed with the bus scan.

The following patch solves the problem:

--- libusb-1.0.6/libusb/os/linux_usbfs.c.orig 2009-11-22 19:17:46.000000000 +0200
+++ libusb-1.0.6/libusb/os/linux_usbfs.c 2009-11-29 11:48:45.000000000 +0200
@@ -716,8 +716,8 @@ static int initialize_device(struct libu
} else {
active_config = usbfs_get_active_config(dev, fd);
if (active_config < 0) {
- close(fd);
- return active_config;
+ usbi_dbg("failed to read active configuration");
+ device_configured = 0;
} else if (active_config == 0) {
/* some buggy devices have a configuration 0, but we're
* reaching into the corner of a corner case here, so let's
@@ -851,9 +851,7 @@ static int usbfs_scan_busdir(struct libu
continue;
}

- r = enumerate_device(ctx, &discdevs, busnum, (uint8_t) devaddr, NULL);
- if (r < 0)
- goto out;
+ enumerate_device(ctx, &discdevs, busnum, (uint8_t) devaddr, NULL);
}

*_discdevs = discdevs;

I tested it on my system (when my USB device enters the "troublesome" state) - and it seems to work fine. Note, however, that I wasn't able to test the consequences of the 2nd fixed line - 'cause the 1st fixed line was enough to solve my problem. Still, if I'm not mistaken, the 2nd fix is needed to ensure that a single "broken" device doesn't break libusb from listing other devices on the same bus...

Regards,
Alex

This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: Windows support for libusb-1.0

2009-11-29T02:19:54Z

Hi,

Daniel Drake wrote:
> pthreads: only used internally, so we don't have to actually use
> pthreads on windows. We just have to use an alternative that
> provides the basic locking primitives.

While pthreads-win32 works perfectly fine (although not much updated)
I think it is much nicer to use win32 primitives in a win32 backend.

This might mean some need for internal locking abstraction.

> MSVC: this seems adventurous. Shouldn't we start with just being
> able to get it compiled and working with gcc on windows?

We should definately try to make the library easily usable also for
developers using MSVC, but I agree that since we're used to gcc it's
easier to look to MinGW for starters. It's usually easier to go this
way (gcc->MSVC) than the other way around, for a given source.

> Or is that impossible?
> I have very little knowledge of windows development practicalities.

It's very possible. Using crossdev it's almost a noop to get a
Windows compiler installed on a Linux system, with headers and all.
The tuple is i_86-mingw32, where you get to choose _ yourself, 3 is
the minimum that makes sense, to be maximally portable. I've made a
small source example that builds in MinGW if you want to look;
http://stuge.se/dlg.zip but remember to add the tuple prefix for
cross compilation. (The zip is for native MinGW installs in Windows.)

Pete Batard wrote:
> Well, you're not the only that has been lamenting about lack of
> Windows support for libusb 1.0x, and I have recently started
> working on a Windows backend for libusb myself.

Great. I was going to look into doing so too.

> I am now at a stage where I have a fully working lsusb sample on
> Windows (hub/device enumeration + readout of device descriptors),
> using the libusb 1.0x backend model, and after some much needed
> code cleanup, I'm hoping I can start posting automake patches and
> new backend sources against the current tree tomorrow...

Ok. Depending on how much code it is and how big (if any) changes
will be required it might make sense to add another repo, or branch,
for the code while it is being merged.

> The development chain I am using, which I think is the one that
> makes the most sense for a Windows port, is MinGW, since it solves
> much of the issues pointed by Josh Perry.

I think it is nicer too. And maybe most importantly it allows us to
fairly easily produce win32 binaries, which is usually very much
appreciated at least by MSVC users, where I guess buliding libraries
is a bit more complicated than building apps. I think it is a great
benefit to get Windows developers to also use the libusb-1.0 API.

> Once you add pthread-win32 to the equation

Again, I disagree with relying on pthread-win32 and would prefer to
use native Windows locking. So this particular platform might mean
that internal locking needs some work.

> and the poll/pipe compatibility layer for git on Windows (look for
> compat/mingw.c in the git source tree),

Sweet! Is the license compatible?

> The only major issue I see right now is that not every USB
> operation is open to user mode on Windows,

What exactly is possible? MSDN links would be great too. If you want,
feel free to make a Trac account and add a wiki page about it. Let me
know if you need any help with that.

> I think it might be a good idea to do as much as we can on the user
> side before we start looking at anything that requires kernel
> access.

Yes - I think that sounds good.

> Anyway, I'll be posting more shortly.

Looking forward to it!

//Peter

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: Windows support for libusb-1.0

2009-11-28T23:12:26Z

>I am now at a stage where I have a fully working lsusb sample on Windows (hub/device enumeration + readout of device descriptors), using the libusb 10x backend model, and after some much >needed code cleanup, I'm hoping I can start posting automake patches and new backend sources against the current tree tomorrow..

Fantastic Pete,

I'm sure a lot of people appreciate this effort, thanks a million!

br Kusti

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: Windows support for libusb-1.0

2009-11-28T19:59:27Z

Hi Francesco,

Well, you're not the only that has been lamenting about lack of Windows support for libusb 1.0x, and I have recently started working on a Windows backend for libusb myself.

I am now at a stage where I have a fully working lsusb sample on Windows (hub/device enumeration + readout of device descriptors), using the libusb 1.0x backend model, and after some much needed code cleanup, I'm hoping I can start posting automake patches and new backend sources against the current tree tomorrow...

The development chain I am using, which I think is the one that makes the most sense for a Windows port, is MinGW, since it solves much of the issues pointed by Josh Perry.
Once you add pthread-win32 to the equation and the poll/pipe compatibility layer for git on Windows (look for compat/mingw.c in the git source tree), a Windows port of libusb no longer looks that that problematic.

The only major issue I see right now is that not every USB operation is open to user mode on Windows, and any kernel operation will require the writing of a driver.
Because of the requirement for signed drivers on 64 bit platforms, which makes for painful driver installation for regular users, I think it might be a good idea to do as much as we can on the user side before we start looking at anything that requires kernel access.
Hopefully, even with non-implemented kernel ops, a usermode only libusb can have enough functions to be useful to some libusb based projects, and could be a quick win. Then we can concentrate on a new win32 driver.

Of course, this is still very early stage, so if anybody has other ideas, please feel free to chime in.

Anyway, I'll be posting more shortly.

Regards,

/Pete

2009/11/28 Francesco Montorsi <francesco.montorsi@...>

Daniel Drake <dsd <at> gentoo.org> writes:
> Before I closed the SF tracker, Josh Perry created a ticket saying that
> he'd started working on windows support.

Hi all,
first of all sorry for reviving this (relatively) old post.

I'm a developer of various open source projects and I'd like to help with the
development of the Windows port of libusb-1.x. I think it would be a great
addition to libusb even if the windows backend wouldn't/couldn't cover all
libusb features.
I already have some experience in Windows driver development (see
http://emfprinter.sourceforge.net/) and I think that using WinUSB API it
shouldn't be _so_ difficult to create the Win backend...

> I just went in to dig out his
> findings that he posted. Now saved at http://www.libusb.org/ticket/1

do you have any news about Josh Perry's work?
Or at least his email address so that we can ask him to post his un-finished
patch to the tracker?

I know that also Stephan Meyer has written a layer above the WinUSB API, but I
think it's an abstraction layer for libusb-0.1 (see http://alturl.com/jwpa
and
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/)...

Maybe joining the efforts we could finally reach a unique (I don't understand
why libusb-win32 and libusb are kept separed - wouldn't be better to merge the
two SF projects?), modern, really cross-platform USB api :)

Thanks!
Francesco Montorsi

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: Windows support for libusb-1.0

2009-11-28T13:21:03Z

Daniel Drake <dsd <at> gentoo.org> writes:
> Before I closed the SF tracker, Josh Perry created a ticket saying that
> he'd started working on windows support.

Hi all,
first of all sorry for reviving this (relatively) old post.

I'm a developer of various open source projects and I'd like to help with the
development of the Windows port of libusb-1.x. I think it would be a great
addition to libusb even if the windows backend wouldn't/couldn't cover all
libusb features.
I already have some experience in Windows driver development (see
http://emfprinter.sourceforge.net/) and I think that using WinUSB API it
shouldn't be _so_ difficult to create the Win backend...

> I just went in to dig out his
> findings that he posted. Now saved at http://www.libusb.org/ticket/1

do you have any news about Josh Perry's work?
Or at least his email address so that we can ask him to post his un-finished
patch to the tracker?

I know that also Stephan Meyer has written a layer above the WinUSB API, but I
think it's an abstraction layer for libusb-0.1 (see http://alturl.com/jwpa
and
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/)...

Maybe joining the efforts we could finally reach a unique (I don't understand
why libusb-win32 and libusb are kept separed - wouldn't be better to merge the
two SF projects?), modern, really cross-platform USB api :)

Thanks!
Francesco Montorsi

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

libusb warning cancel_bulk_transfer

2009-11-27T01:34:39Z

Hello!

I get following warning:
libusb:warning [cancel_bulk_transfer] unrecognised discard errno 9
But i don't use a bluk transfer anyway.

Thanks a lot, best regards

--
manfred weiss

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: libusb 1.1 hotplugging

2009-11-26T12:39:47Z

Ludovic Rousseau wrote:
> I have the problem with CCID (smart cards) readers. If the driver does
> just wait in usb_interrupt_read() waiting for a smart card to be
> inserted or removed from the reader then the driver will not notice a
> reader removal.
> That was with libusb 0.1. I don't know if the problem is still present
> in libusb 1.0

It's not.

Daniel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: libusb 1.1 hotplugging

2009-11-26T12:26:55Z

2009/11/23 Andreas Jellinghaus <aj@...>:
> Hi,

Hello Andreas,

> I saw your announcement / plan for libusb 1.1 and hotplugging.
>
> it would be real nice from my point of view:
> 1.) if one app could monitor usb, and run some code when something
> new is found.
> 2.) it would be nice if there was a portable way one app can spawn/tell
> a second app, what the new thing is.
>
> notes:
> * new usb devices is interesting for me. old ones gone is not so interesting -
> if I found something interesting and open()ed it, the fd should be in
> an error state once the device is gone, which is detectable by poll/select
> without wasting cpu resources on monitoring "is this device still there" by
> loops or similar.

I am not sure if the application will get an error when a USB device
is removed and the application does not talk to the device.
The application may discover the device has gone on the _next_
communication. That may be in a very long time. And the list of
available devices know by the application is then wrong/not up to
date.

I have the problem with CCID (smart cards) readers. If the driver does
just wait in usb_interrupt_read() waiting for a smart card to be
inserted or removed from the reader then the driver will not notice a
reader removal.
That was with libusb 0.1. I don't know if the problem is still present
in libusb 1.0

That is mostly mandatory for libusb 1.1 to also notify device removal.

> * I love small, isolated, minimal applications. thus I find it real nice of
> one app can do the monitoring for new devices, one can do the evaluation
> of a new device and one can handle the new device, if it is something the
> app can work with. it would be nice if passing information from app to app
> is somehow not totaly inefficient. e.g. it would be nice if the 2nd and 3rd
> app can relatively straight connect/access the new device, without probing
> and evaluating every other usb device connected to the system first.
> (i.e. wasting some miliseconds and cpu cycles is ok, but not tooo many)
> * the app to app interface should be stable, i.e. it is ok if the 2nd or
> 3rd app is "too late" and the device is gone in the meantime and it gets
> an error. but it shouldn't be something like "the 2nd device with
> vendor/product xyz" which is something that can change in the meantime
> as devices are added or removed or replugged in a fast sequence.
>
> the linux kernel internals with bus NNNN device MMMM make up a real nice
> id system, but I think it is not portable to other operating systems,
> so no idea what would be best. (IIRC the device number MMMM isn't recycled
> by the kernel, at least not immediatly, so it serves as a nice valid id
> for a while).
>
> but the plans to open a device by busnum and devnum sound great.

I also request for a way to uniquely identify a device and do
something like libusb_open_by_id(id, &handle)

Bye

--
Dr. Ludovic Rousseau

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: usb_control_msg() returns ETIMEOUT

2009-11-26T11:03:57Z

roundleaf wrote:
> Hi all!
>
> After posting I found a similar problem at
> http://old.nabble.com/Second-device-access-always-fails-%28libusb-0.1.12%29-to26346137.html.
> However it didn't seem to be resolved, so I might as well post this. The
> post I referred talks about the configuration of the device. I don't set any
> configuration at all in my program. What effect does the setting or
> non-setting of configs have?

Some versions of Linux do a soft-reset when you release an interface (or
close a device, I can't remember which). It's possible that your missile
launcher (!?) has a firmware bug and this is causing the device to crash.

Daniel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

New release of libusb 0.12 ?

2009-11-24T03:24:37Z

Hello libusb developpers

I have reported a bug and its fix in libusb 0.12
( http://www.libusb.org/ticket/19 ) but I saw that 0.12 is no more
maintened. So I wonder if there is a chance to have a new release of it
because libusb 0.12.X is still widely used.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

usb_control_msg() returns ETIMEOUT

2009-11-23T12:31:58Z

Hi all!

After posting I found a similar problem at http://old.nabble.com/Second-device-access-always-fails-%28libusb-0.1.12%29-to26346137.html. However it didn't seem to be resolved, so I might as well post this. The post I referred talks about the configuration of the device. I don't set any configuration at all in my program. What effect does the setting or non-setting of configs have?

A couple of years back I wrote a simple shared library for controlling a usb missile launcher. At the time I was running Fedora 8 and I can't remember that I had the problem I'm about to describe. If I plug in my missile launcher and run my program it works just fine. However, the second time I run the program I get ETIMEOUT [-110] from usb_control_msg(). If I disconnect/connect the device it works again. But just one time. I've tried doing all the cleanup I could think of, but it doesn't seem to help. A difference between the first time and the second time is that I (successfully) detach the kernel driver for my device. This is not necessary the second time. Anyway, in both cases the program successfully claims the interface.

I'm running some CentOS (can't really remember which version :) If you think the code can help you help me, I can post it for you.

Thanks!

Re: libusb-1.0.6 released

2009-11-23T07:51:36Z

On Mon, 23 Nov 2009, Daniel Drake wrote:

> Alan Stern wrote:
> > There is a compromise. Opening a device file based on the bus number
> > and device number isn't Linux-specific, so it can (and should) be added
> > to the public API.
>
> I thought that you said bus number is Linux-specific.

Not exactly. I said it wasn't defined in the USB spec but that every
operating system must have some way to identify a bus, presumably by
using a bus number. Doesn't the libusb API already expose bus numbers?

> However, am I right in thinking that device addresses are specific to
> the whole system, rather than to a specific bus? If so, the device
> address would satisfy as a USB-level unique identifier for each device,
> and we could add an API based on that alone.

No, addresses are local to a particular bus. For example, in Linux the
root hub for each bus is always assigned device number 1.

Alan Stern

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: libusb-1.0.6 released

2009-11-23T07:08:36Z

Alan Stern wrote:
> There is a compromise. Opening a device file based on the bus number
> and device number isn't Linux-specific, so it can (and should) be added
> to the public API.

I thought that you said bus number is Linux-specific.

However, am I right in thinking that device addresses are specific to
the whole system, rather than to a specific bus? If so, the device
address would satisfy as a USB-level unique identifier for each device,
and we could add an API based on that alone.

Daniel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: libusb-1.0.6 released

2009-11-23T06:55:57Z

On Mon, 23 Nov 2009, Daniel Drake wrote:

> Marcel Holtmann wrote:
> > actually the more important part would be to have a libusb_open_*
> > function that you can give a sysfs path. So that when called from udev
> > rules file you can directly open that device. This is important to not
> > wake up all USB devices on enumeration. Especially since you already
> > know the device you wanna talk to.
>
> The fact that USB devices are woken up on enumeration is a bug that can
> be fixed independently.
>
> Exposing a fairly low-level Linux detail in the public API is not
> something I'm keen on.

There is a compromise. Opening a device file based on the bus number
and device number isn't Linux-specific, so it can (and should) be added
to the public API.

Getting the bus and device number from the sysfs path is easy, because
those values are available in attribute files in the sysfs directory.
If necessary, this could be added as a Linux-specific API. But if
you're triggering off a hotplug event then it's likely that the bus and
device numbers are already present in the hotplug information and so no
translation is needed.

Alan Stern

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

libusb 1.1 hotplugging

2009-11-23T05:47:56Z

Hi,

I saw your announcement / plan for libusb 1.1 and hotplugging.

it would be real nice from my point of view:
1.) if one app could monitor usb, and run some code when something
new is found.
2.) it would be nice if there was a portable way one app can spawn/tell
a second app, what the new thing is.

notes:
* for monitoring usb it would be nice to use kernel facilities etc. to
save power on laptops. but a fallback on polling / scanning usb every
X seconds is fine with me (and might be needed on some operating systems?)
* new usb devices is interesting for me. old ones gone is not so interesting -
if I found something interesting and open()ed it, the fd should be in
an error state once the device is gone, which is detectable by poll/select
without wasting cpu resources on monitoring "is this device still there" by
loops or similar.
* I love small, isolated, minimal applications. thus I find it real nice of
one app can do the monitoring for new devices, one can do the evaluation
of a new device and one can handle the new device, if it is something the
app can work with. it would be nice if passing information from app to app
is somehow not totaly inefficient. e.g. it would be nice if the 2nd and 3rd
app can relatively straight connect/access the new device, without probing
and evaluating every other usb device connected to the system first.
(i.e. wasting some miliseconds and cpu cycles is ok, but not tooo many)
* the app to app interface should be stable, i.e. it is ok if the 2nd or
3rd app is "too late" and the device is gone in the meantime and it gets
an error. but it shouldn't be something like "the 2nd device with
vendor/product xyz" which is something that can change in the meantime
as devices are added or removed or replugged in a fast sequence.

the linux kernel internals with bus NNNN device MMMM make up a real nice
id system, but I think it is not portable to other operating systems,
so no idea what would be best. (IIRC the device number MMMM isn't recycled
by the kernel, at least not immediatly, so it serves as a nice valid id
for a while).

but the plans to open a device by busnum and devnum sound great.

Thanks and regards,

Andreas Jellinghaus
p.s. please cc: me, sorry, not subscribed to the list. not sure if the
list copy needs manual approval...

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: libusb-1.0.6 released

2009-11-23T02:43:25Z

Marcel Holtmann wrote:
> actually the more important part would be to have a libusb_open_*
> function that you can give a sysfs path. So that when called from udev
> rules file you can directly open that device. This is important to not
> wake up all USB devices on enumeration. Especially since you already
> know the device you wanna talk to.

The fact that USB devices are woken up on enumeration is a bug that can
be fixed independently.

Exposing a fairly low-level Linux detail in the public API is not
something I'm keen on.

Daniel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: libusb-1.0.6 released

2009-11-23T01:56:22Z

2009/11/23 Marcel Holtmann <marcel@...>:

> Hi Daniel,
>
>> I now plan to work on libusb-1.1 for release before the end of the year.
>> Changes:
>> - hotplug through libudev
>> - use dedicated timing thread for generating file-based timer events on
>> systems where libusb-level time tracking is needed and timerfd is not
>> available (i.e. no change of behaviour for Darwin and recent Linux
>> platforms, and recent Linux platforms will still achieve "zero
>> threads")
>> - make libusb_handle_events() timeout unlimited
>
> actually the more important part would be to have a libusb_open_*
> function that you can give a sysfs path. So that when called from udev
> rules file you can directly open that device. This is important to not
> wake up all USB devices on enumeration. Especially since you already
> know the device you wanna talk to.

I also would like to have such a feature.

In my case I have one process that detects hotplug events and then
call the correct driver (in user space) for the newly connected USB
device. The driver has to rescan the USB bus to identify the device to
use. Using a sysfs path (or something else) to directly give the
device identification to a libusb_open_* function would be great (and
would avoid re-identification problems).

So +1 for this request.

Bye

--
Dr. Ludovic Rousseau

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: libusb-1.0.6 released

2009-11-23T01:12:28Z

Hi Daniel,

> I now plan to work on libusb-1.1 for release before the end of the year.
> Changes:
> - hotplug through libudev
> - use dedicated timing thread for generating file-based timer events on
> systems where libusb-level time tracking is needed and timerfd is not
> available (i.e. no change of behaviour for Darwin and recent Linux
> platforms, and recent Linux platforms will still achieve "zero
> threads")
> - make libusb_handle_events() timeout unlimited

actually the more important part would be to have a libusb_open_*
function that you can give a sysfs path. So that when called from udev
rules file you can directly open that device. This is important to not
wake up all USB devices on enumeration. Especially since you already
know the device you wanna talk to.

Regards

Marcel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

libusb-1.0.6 released

2009-11-22T09:47:15Z

https://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.6/libusb-1.0.6.tar.bz2/download

Daniel Drake (3):
Refine timerfd header check (#18)
Increase libusb_handle_events() timeout to 60 seconds
v1.0.6 release

Ludovic Rousseau (2):
Darwin: fix warning in darwin_error_str()
lsusb example: make print_devs() static

Nathan Hjelm (1):
Darwin: allow devices to be opened multiple times

I now plan to work on libusb-1.1 for release before the end of the year.
Changes:
- hotplug through libudev
- use dedicated timing thread for generating file-based timer events on
systems where libusb-level time tracking is needed and timerfd is not
available (i.e. no change of behaviour for Darwin and recent Linux
platforms, and recent Linux platforms will still achieve "zero
threads")
- make libusb_handle_events() timeout unlimited

No incompatible API or ABI changes, but obviously a few functions will
be added for hotplugging, the libusb_handle_events() change is a slight
change in documented behaviour, and some functions will become redundant
through the timing changes (e.g. libusb_get_next_timeout() will always
return 0)

Hotplug backends for other platforms (Linux+HAL, linux-2.4, Darwin?)
will hopefully follow soon after.

Daniel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: MacOSX: Accessing multiple interfaces of the same device at once

2009-11-21T09:07:40Z

Nathan Hjelm wrote:
> Fixed in the attached patch.

Thanks, applied

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

libusb-1.0

2009-11-19T02:46:32Z

Congratulations!

We make some fairly complex picosecond timing data acquisition systems for which we built linux libraries/apps based on libusb 0.1.
(see http://www.picoquant.com/products/hydraharp400/hydraharp400.htm for the latest)
They are out in the filed for some time and I was somewhat worried what would happen when the Linux distributions start replacing libusb 0.1 with 1.0.
This is the case with Suse 11.2 now. As it turns out, everything works flawlwssly "out of the box" through the compatibility layer. Bulk throughput is significatly
faster (35MB/s) and now almost as fast as under Windows (37MB/s) on the same machine.

We will of course make an effort to port the libs/apps to use libusb 1.0 directly and hopefully also make use of the asynchronous calls.

Thanks for all the bits,
Mick

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: MacOSX: Accessing multiple interfaces of the same device at once

2009-11-18T11:28:07Z

The patch is completely functional except for one empty line which got deleted.

Also, I forgot to mention that this patch also includes a fix for a set alt interface bug.

-Nathan

On Wednesday, November 18, 2009, at 12:50AM, "Peter Stuge" <peter@...> wrote:

>Nathan Hjelm wrote:
>> Fixed in the attached patch.
>
>Just a general comment. Please avoid whitespace changes in the same
>patch where there are functional changes.
>
>Please always send whitespace changes in a separate patch.
>
>
>Thanks!
>
>//Peter
>
>------------------------------------------------------------------------------
>Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>trial. Simplify your report design, integration and deployment - and focus on
>what you do best, core application coding. Discover what's new with
>Crystal Reports now. http://p.sf.net/sfu/bobj-july
>_______________________________________________
>Libusb-devel mailing list
>Libusb-devel@...
>https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>

Re: MacOSX: Accessing multiple interfaces of the same device at once

2009-11-17T23:50:05Z

Nathan Hjelm wrote:
> Fixed in the attached patch.

Just a general comment. Please avoid whitespace changes in the same
patch where there are functional changes.

Please always send whitespace changes in a separate patch.

Thanks!

//Peter

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: MacOSX: Accessing multiple interfaces of the same device at once

2009-11-17T12:33:29Z

Fixed in the attached patch.

-Nathan

On Tuesday, November 17, 2009, at 04:28AM, "Emmanuel Blot" <eblot.ml@...> wrote:

>> Multiple opens wasn't as complicated to implement as I originally thought. Attached is a version that uses open counting to decide when the device and its asynchronous event ports are released. Let me know if this version works for you.
>
>Hi Nathan,
>
>I'm getting back to you to let you know that your changes work seamlessly.
>I've been able to use multiple interfaces of the USB device
>(FTDI4232H) with various use cases and multiple interface
>combinations, all worked perfectly.
>
>Thanks a lot for your help, I hope these changes will make it for libusb 1.0.6
>
>Should I post this message to the mailing list, so that other Mac OS X
>users know there's a patch available for this issue?
>
>BR,
>Manu
>
>

multiple_open.patch (7K) Download Attachment

Re: libusb 1.0.4 unstable on CentOS/RHEL 5.3

2009-11-17T03:43:12Z

>
>Are you using the compatibility layer? It doesn't seem to be the case.
> You need that for a 0.x app with a 1.0 library...
>
>I've found that a multi process app has issues even with compat.
>Threads are ok..

No, I'm not - I changed my application code instead to use synchronous APIs.
And in any case the problem is reproduced with an example "lsusb" application (included in libusb 1.0.4 sources).

This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: libusb 1.0.4 unstable on CentOS/RHEL 5.3

2009-11-17T00:45:20Z

Alex Agranov wrote:

> Hi,
>
> I have a small application that currently uses libusb 0.1.12 and runs on CentOS/RHEL 5.3 box (32 bit, with the latest kernel from updates repository - 2.6.18-164.6.1.el5). I'm trying to port it to libusb 1.0.4, however it looks like libusb 1.0.4 doesn't work in a stable manner on this platform.
>
> I was able to reproduce the problem with a simple "lsusb" program included in examples. And it's essentially as follows: sometimes "lsusb" compiled with libusb 1.0.4 works just fine. But at other times, it fails inside the libusb_get_device_list() call with the following error:
>
> libusb:error [usbfs_get_active_config] get_configuration failed ret=-1 errno=71
>
> At the same time the following kernel error is logged in dmesg:
>
> usb 3-2: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 8 len 1 ret -71
>
> When the error happens, it continues forever until I reboot my box. The issue may or may not happen again immediately after the reboot - I wasn't able to see any clear pattern in this one...
>
> When "lsusb with libusb 1.0.4" produces the above error, "lsusb" provided with CentOS/RHEL (and compiled with libusb 0.1.12) works just fine. See below the strace for "lsusb with libusb 1.0.4" when it produces the error:
>
> tg-lab8::~# strace /Project/bin/exe/lsusb
> execve("/Project/bin/exe/lsusb", ["/Project/bin/exe/lsusb"], [/* 18 vars */]) = 0
> brk(0) = 0x9306000
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f31000
> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
> open("/usr/lib/sparcv9/tls/i686/sse2/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/lib/sparcv9/tls/i686/sse2", 0xbffa3598) = -1 ENOENT (No such file or directory)
> open("/usr/lib/sparcv9/tls/i686/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/lib/sparcv9/tls/i686", 0xbffa3598) = -1 ENOENT (No such file or directory)
> open("/usr/lib/sparcv9/tls/sse2/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/lib/sparcv9/tls/sse2", 0xbffa3598) = -1 ENOENT (No such file or directory)
> open("/usr/lib/sparcv9/tls/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/lib/sparcv9/tls", 0xbffa3598) = -1 ENOENT (No such file or directory)
> open("/usr/lib/sparcv9/i686/sse2/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/lib/sparcv9/i686/sse2", 0xbffa3598) = -1 ENOENT (No such file or directory)
> open("/usr/lib/sparcv9/i686/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/lib/sparcv9/i686", 0xbffa3598) = -1 ENOENT (No such file or directory)
> open("/usr/lib/sparcv9/sse2/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/lib/sparcv9/sse2", 0xbffa3598) = -1 ENOENT (No such file or directory)
> open("/usr/lib/sparcv9/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/lib/sparcv9", 0xbffa3598) = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=15257, ...}) = 0
> mmap2(NULL, 15257, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f2d000
> close(3) = 0
> open("/usr/lib/libusb-1.0.so.0", O_RDONLY) = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\32\0\0004\0\0\0"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=48628, ...}) = 0
> mmap2(NULL, 51476, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x41c000
> mmap2(0x428000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb) = 0x428000
> close(3) = 0
> open("/usr/lib/libstdc++.so.6", O_RDONLY) = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\326\3\0004\0\0\0"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=925520, ...}) = 0
> mmap2(NULL, 952024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x110000
> mmap2(0x1ee000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xdd) = 0x1ee000
> mmap2(0x1f3000, 22232, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x1f3000
> close(3) = 0
> open("/lib/libm.so.6", O_RDONLY) = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0204\0\0004\0\0\0"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=206380, ...}) = 0
> mmap2(NULL, 155760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4b6000
> mmap2(0x4db000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24) = 0x4db000
> close(3) = 0
> open("/lib/libgcc_s.so.1", O_RDONLY) = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\26\0\0004\0\0\0"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=44992, ...}) = 0
> mmap2(NULL, 48036, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x5dd000
> mmap2(0x5e8000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa) = 0x5e8000
> close(3) = 0
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320_\1\0004\0\0\0"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1603392, ...}) = 0
> mmap2(NULL, 1324452, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb08000
> mmap2(0xc46000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13e) = 0xc46000
> mmap2(0xc49000, 9636, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xc49000
> close(3) = 0
> open("/lib/librt.so.1", O_RDONLY) = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\30\0\0004\0\0\0"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=42048, ...}) = 0
> mmap2(NULL, 33324, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x893000
> mmap2(0x89a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0x89a000
> close(3) = 0
> open("/lib/libpthread.so.0", O_RDONLY) = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000H\0\0004\0\0\0"..., 512) = 512
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f2c000
> fstat64(3, {st_mode=S_IFREG|0755, st_size=123596, ...}) = 0
> mmap2(NULL, 90592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x74b000
> mmap2(0x75e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0x75e000
> mmap2(0x760000, 4576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x760000
> close(3) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f2b000
> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f2b6d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
> mprotect(0x75e000, 4096, PROT_READ) = 0
> mprotect(0x89a000, 4096, PROT_READ) = 0
> mprotect(0xc46000, 8192, PROT_READ) = 0
> mprotect(0x4db000, 4096, PROT_READ) = 0
> mprotect(0x1ee000, 12288, PROT_READ) = 0
> mprotect(0x510000, 4096, PROT_READ) = 0
> munmap(0xb7f2d000, 15257) = 0
> set_tid_address(0xb7f2b718) = 2859
> set_robust_list(0xb7f2b720, 0xc) = 0
> futex(0xbffa3e34, FUTEX_WAKE_PRIVATE, 1) = 0
> rt_sigaction(SIGRTMIN, {0x74f3d0, [], SA_SIGINFO}, NULL, 8) = 0
> rt_sigaction(SIGRT_1, {0x74f2e0, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
> rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
> getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0
> uname({sys="Linux", node="tg-lab8", ...}) = 0
> futex(0x1f44fc, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> brk(0) = 0x9306000
> brk(0x9327000) = 0x9327000
> open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents(3, /* 6 entries */, 4096) = 96
> close(3) = 0
> clock_gettime(0x4 /* CLOCK_??? */, 0xbffa3c48) = -1 EINVAL (Invalid argument)
> clock_getres(0xfffffffa /* CLOCK_??? */, NULL) = 0
> clock_gettime(CLOCK_MONOTONIC, {5859, 53636345}) = 0
> uname({sys="Linux", node="tg-lab8", ...}) = 0
> stat64("/sys/bus/usb/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> pipe([3, 4]) = 0
> open("/sys/bus/usb/devices", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5
> fstat64(5, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
> getdents(5, /* 12 entries */, 4096) = 212
> stat64("/sys/bus/usb/devices/3-2/descriptors", 0xbffa2ca0) = -1 ENOENT (No such file or directory)
> open("/sys/bus/usb/devices/3-2/busnum", O_RDONLY) = -1 ENOENT (No such file or directory)
> close(5) = 0
> open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5
> fstat64(5, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
> fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
> getdents(5, /* 6 entries */, 4096) = 96
> open("/dev/bus/usb/004", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 6
> fstat64(6, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
> fcntl64(6, F_SETFD, FD_CLOEXEC) = 0
> getdents(6, /* 3 entries */, 4096) = 48
> open("/dev/bus/usb/004/001", O_RDWR) = 7
> ioctl(7, USBDEVFS_CONTROL, 0xbffa1ce0) = 1
> read(7, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18
> open("/dev/bus/usb/004/001", O_RDONLY) = 8
> lseek(8, 18, SEEK_SET) = 18
> read(8, "\t\2\31\0\1\1", 6) = 6
> close(8) = 0
> lseek(7, 18, SEEK_SET) = 18
> read(7, "\t\2\31\0\1\1\0\340", 8) = 8
> lseek(7, 18, SEEK_SET) = 18
> read(7, "\t\2\31\0\1\1\0\340\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 25) = 25
> close(7) = 0
> getdents(6, /* 0 entries */, 4096) = 0
> close(6) = 0
> open("/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 6
> fstat64(6, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> fcntl64(6, F_SETFD, FD_CLOEXEC) = 0
> getdents(6, /* 4 entries */, 4096) = 64
> open("/dev/bus/usb/003/001", O_RDWR) = 7
> ioctl(7, USBDEVFS_CONTROL, 0xbffa1ce0) = 1
> read(7, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18
> open("/dev/bus/usb/003/001", O_RDONLY) = 8
> lseek(8, 18, SEEK_SET) = 18
> read(8, "\t\2\31\0\1\1", 6) = 6
> close(8) = 0
> lseek(7, 18, SEEK_SET) = 18
> read(7, "\t\2\31\0\1\1\0\340", 8) = 8
> lseek(7, 18, SEEK_SET) = 18
> read(7, "\t\2\31\0\1\1\0\340\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 25) = 25
> close(7) = 0
> open("/dev/bus/usb/003/002", O_RDWR) = 7
> ioctl(7, USBDEVFS_CONTROL, 0xbffa1ce0) = -1 EPROTO (Protocol error)
> close(7) = 0
> close(6) = 0
> close(5) = 0
> exit_group(-1) = ?
>
> And here is the strace for "lsusb with libusb 0.1.12" run immediately afterwards, that completes successfully:
>
> tg-lab8::~# strace lsusb
> execve("/sbin/lsusb", ["lsusb"], [/* 18 vars */]) = 0
> brk(0) = 0x9edb000
> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=15257, ...}) = 0
> mmap2(NULL, 15257, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f82000
> close(3) = 0
> open("/usr/lib/libusb-0.1.so.4", O_RDONLY) = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\21\0\0004\0\0\0"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=31500, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f81000
> mmap2(NULL, 30232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x750000
> mmap2(0x756000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0x756000
> close(3) = 0
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320_\1\0004\0\0\0"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1603392, ...}) = 0
> mmap2(NULL, 1324452, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x25d000
> mmap2(0x39b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13e) = 0x39b000
> mmap2(0x39e000, 9636, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x39e000
> close(3) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f80000
> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f806c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
> mprotect(0x39b000, 8192, PROT_READ) = 0
> mprotect(0xbb0000, 4096, PROT_READ) = 0
> munmap(0xb7f82000, 15257) = 0
> brk(0) = 0x9edb000
> brk(0x9efc000) = 0x9efc000
> open("./usb.ids", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/hwdata/usb.ids", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=357262, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f85000
> read(3, "#\n# List of USB ID's\n#\n#\tMai"..., 4096) = 4096
> read(3, "01 Scanjet 82x0C\n\t0b0c Wireles"..., 4096) = 4096
> read(3, "2500\n\t3717 EWS UPD\n\t3802 photo"..., 4096) = 4096
> read(3, " series\n\tb202 photosmart 7600 s"..., 4096) = 4096
> read(3, ", Receipt/Slip\n\t0312 7197 Print"..., 4096) = 4096
> read(3, "Camera\n\t05c3 Digital Camera\n\t05"..., 4096) = 4096
> read(3, "nal Composite Device\n\t3010 Soun"..., 4096) = 4096
> read(3, "ent\n\t043c 6155 Phone Parent\n\t04"..., 4096) = 4096
> read(3, "t Copy\n\t0042 Scan Print Copy\n\t0"..., 4096) = 4096
> read(3, "tor\n\t0051 Integrated Hub\n0453 "..., 4096) = 4096
> read(3, "l MultiMedia Keyboard\n\t0065 Wir"..., 4096) = 4096
> read(3, "C 2003\n\t0457 Windows Powered Po"..., 4096) = 4096
> read(3, " Mouse\n\t4d2a PoPo Elixir Mouse "..., 4096) = 4096
> read(3, "se\n\tc01a M-BQ85 Optical Wheel M"..., 4096) = 4096
> read(3, "2 BTC 7932 mouse+keyboard\n046f "..., 4096) = 4096
> read(3, "e\n\t1061 PocketMouse Grip\n\t1062 "..., 4096) = 4096
> read(3, "000 DTX\n\t7010 UB99\n049a Ganda"..., 4096) = 4096
> read(3, "\t1055 BJC-85\n\t1056 BJC-2110 Co"..., 4096) = 4096
> read(3, " IXY Digital\n\t3047 Digital IXUS"..., 4096) = 4096
> read(3, " Coolpix 5000 (ptp)\n\t0114 Cool"..., 4096) = 4096
> read(3, "a\n\t0402 PhotoPC 850z\n\t0403 Pho"..., 4096) = 4096
> read(3, " Ltd\n\t1029 fi-4010c Scanner\n\t10"..., 4096) = 4096
> read(3, "Lansing HID Audio Controls\n\tff49"..., 4096) = 4096
> read(3, "erface\n\t0008 3000U AccuTouch\302\256 "..., 4096) = 4096
> brk(0x9f1d000) = 0x9f1d000
> read(3, "RITE CCD Webcam(PC370R)\n\ta128 P"..., 4096) = 4096
> read(3, "CP-540CN\n\t01ab MFC-240C\n\t01ae "..., 4096) = 4096
> read(3, " F1DF102U/F1DG102U Flip Hub\n\t32"..., 4096) = 4096
> read(3, " Color Pocket PC V37\n\t152b Colo"..., 4096) = 4096
> read(3, "6 MEMORY P-AUDIO\n\t01c7 Printin"..., 4096) = 4096
> read(3, "nterface Corp.\n0561 Oasis Desig"..., 4096) = 4096
> read(3, "auge WinTV-USB Model 40204 rev B"..., 4096) = 4096
> read(3, "0584 RATOC System, Inc.\n\t0008 "..., 4096) = 4096
> read(3, "rive USB2\n\t0203 StudioDrive USB"..., 4096) = 4096
> read(3, "ernational, Inc.\n\t0002 AccelePo"..., 4096) = 4096
> read(3, "0c1 USB600 Scanner\n\t30ce ScanM"..., 4096) = 4096
> read(3, "e Device\n\t0715 USB 2.0 microSD "..., 4096) = 4096
> read(3, "odiak KM-9010\n\t9003 VoIP Confer"..., 4096) = 4096
> read(3, "2 MP3 Player\n\t8124 MP3 Player\n"..., 4096) = 4096
> read(3, "00c Dimage F100 Camera\n\t400d S"..., 4096) = 4096
> read(3, "d\n06ae Professional Multimedia "..., 4096) = 4096
> read(3, "re\n\t0066 TRUST Digital PCTV and"..., 4096) = 4096
> read(3, "e06 EZ-Connect 802.11g Adapter\n"..., 4096) = 4096
> read(3, "C\n074d Micronas GmbH\n\t3553 Com"..., 4096) = 4096
> read(3, "0 Cruzer Mini\n\t7101 Pen Flash\n"..., 4096) = 4096
> read(3, " Wireless Adapter WU830G\n07b3 P"..., 4096) = 4096
> read(3, "Reader\n\t0005 Reader (UISA2SE)\n\t"..., 4096) = 4096
> read(3, "rk of the Unicorn\n\t0000 FastLan"..., 4096) = 4096
> brk(0x9f3e000) = 0x9f3e000
> read(3, "ros AR5004X / AR5005UX]\n\t4301 W"..., 4096) = 4096
> read(3, "eakers\n\t2900 PCM2900 Audio Code"..., 4096) = 4096
> read(3, "c.\n\t1600 AES1600\n\t1610 AES1600"..., 4096) = 4096
> read(3, "800 Quad Joypad\n\t8866 WiseGroup"..., 4096) = 4096
> read(3, "ion Laboratories\n094f Yano\n\t010"..., 4096) = 4096
> read(3, "Systems Inc.\n\t0064 ADU100 Data "..., 4096) = 4096
> read(3, "oth Dongle\n\t2033 BCM2033 Blueto"..., 4096) = 4096
> read(3, "ro generic vc0321 Camera\n\t0323 "..., 4096) = 4096
> read(3, "er\n\t1612 AIR.Mate 2@net 802.11b"..., 4096) = 4096
> read(3, " Sync\n\t0a1e PocketPC Sync\n\t0a1f"..., 4096) = 4096
> read(3, "compliant)\n\t000c Transceiver (A"..., 4096) = 4096
> read(3, "r\n\t1028 Mass Storage Reader\n\t10"..., 4096) = 4096
> read(3, "0 Spectrum Digital XDS510 JTAG "..., 4096) = 4096
> read(3, "g Wireless LAN Adapter(3887A)\n\t0"..., 4096) = 4096
> read(3, "Line Tek Electronic Co., Ltd\n0d7"..., 4096) = 4096
> read(3, "RT2570\n\t6874 RT2573\n\t6877 RT25"..., 4096) = 4096
> read(3, " iAudio U3\n0e22 Symbian Ltd.\n0"..., 4096) = 4096
> read(3, "td\n\t0001 eGalax TouchScreen\n\t00"..., 4096) = 4096
> read(3, "\n\tdb78 FusionHDTV DVB-T Dual Di"..., 4096) = 4096
> read(3, "Serial Port (WDM)\n\t1303 Packet "..., 4096) = 4096
> read(3, "01 USB-Module for Spider8, CP32"..., 4096) = 4096
> read(3, "885 Device\n\t6870 MC8780 Device\n"..., 4096) = 4096
> read(3, "B 2.0 Adapter\n\t5f01 WPN111 (no "..., 4096) = 4096
> read(3, " usbtty generic serial\n\t5121 Op"..., 4096) = 4096
> read(3, "ra Technologies Corp.\n15f4 Hanf"..., 4096) = 4096
> brk(0x9f5f000) = 0x9f5f000
> read(3, "ax Digital Inc.\n168c Atheros Co"..., 4096) = 4096
> read(3, "B-U2000 - DVB-T USB cold\n\td001 "..., 4096) = 4096
> read(3, "6000/8/DIO\n\t604f ME-6000/16/DIO"..., 4096) = 4096
> read(3, "c.\n1d6b Linux Foundation\n\t0001 "..., 4096) = 4096
> read(3, "Net)\n\t6006 MOTOROKR E6\n\t6008 D"..., 4096) = 4096
> read(3, " acquisition card) firmware upda"..., 4096) = 4096
> read(3, "x printer adapter cable\n4572 Sh"..., 4096) = 4096
> read(3, "nterface level)\nC 01 Audio\n\t01 "..., 4096) = 4096
> read(3, "Receiver\nAT 0711 Radio Transmit"..., 4096) = 4096
> read(3, "it\n\t003 Flexor\n\t004 Glove\n\t005"..., 4096) = 4096
> read(3, "89 International 3 (PC98)\n\t08a "..., 4096) = 4096
> read(3, "\n\t082 Mode Step\n\t083 Recall La"..., 4096) = 4096
> read(3, "ly\n\t23b AC Tile Vertically\n\t23c"..., 4096) = 4096
> read(3, "rol\n\t002 EDID Information\n\t003 "..., 4096) = 4096
> read(3, "Relative State Of Charge\n\t065 A"..., 4096) = 4096
> read(3, "sh\nHCC 08 French\nHCC 09 German"..., 4096) = 910
> read(3, "", 4096) = 0
> close(3) = 0
> munmap(0xb7f85000, 4096) = 0
> open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents(3, /* 6 entries */, 4096) = 96
> close(3) = 0
> open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents(3, /* 6 entries */, 4096) = 96
> getdents(3, /* 0 entries */, 4096) = 0
> close(3) = 0
> open("/dev/bus/usb/004", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents(3, /* 3 entries */, 4096) = 48
> open("/dev/bus/usb/004/001", O_RDWR) = 4
> ioctl(4, USBDEVFS_CONNECTINFO, 0xbfdcdaa4) = 0
> read(4, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18
> read(4, "\t\2\31\0\1\1\0\340", 8) = 8
> read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17
> close(4) = 0
> getdents(3, /* 0 entries */, 4096) = 0
> close(3) = 0
> open("/dev/bus/usb/004/001", O_RDWR) = 3
> ioctl(3, USBDEVFS_IOCTL, 0xbfdcfa3c) = 3
> close(3) = 0
> open("/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents(3, /* 4 entries */, 4096) = 64
> open("/dev/bus/usb/003/001", O_RDWR) = 4
> ioctl(4, USBDEVFS_CONNECTINFO, 0xbfdcdaa4) = 0
> read(4, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18
> read(4, "\t\2\31\0\1\1\0\340", 8) = 8
> read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17
> close(4) = 0
> open("/dev/bus/usb/003/002", O_RDWR) = 4
> ioctl(4, USBDEVFS_CONNECTINFO, 0xbfdcdaa4) = 0
> read(4, "\22\1\20\1\0\0\0@\277\n\355\3\4\0\1\2\3\1", 18) = 18
> read(4, "\t\2Z\0\1\1\0\300", 8) = 8
> read(4, "2\t\4\0\0\4\377\0\0\0\7\5\2\2@\0\0\7\5\4\2@\0\0\7\5\202\2@\0\0\7"..., 82) = 82
> close(4) = 0
> getdents(3, /* 0 entries */, 4096) = 0
> close(3) = 0
> open("/dev/bus/usb/003/001", O_RDWR) = 3
> ioctl(3, USBDEVFS_IOCTL, 0xbfdcfa3c) = 3
> close(3) = 0
> open("/dev/bus/usb/003/002", O_RDWR) = 3
> ioctl(3, USBDEVFS_IOCTL, 0xbfdcfa3c) = -1 ENOTTY (Inappropriate ioctl for device)
> close(3) = 0
> open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents(3, /* 3 entries */, 4096) = 48
> open("/dev/bus/usb/001/001", O_RDWR) = 4
> ioctl(4, USBDEVFS_CONNECTINFO, 0xbfdcdaa4) = 0
> read(4, "\22\1\0\2\t\0\1@\0\0\0\0\6\2\3\2\1\1", 18) = 18
> read(4, "\t\2\31\0\1\1\0\340", 8) = 8
> read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\f", 17) = 17
> close(4) = 0
> getdents(3, /* 0 entries */, 4096) = 0
> close(3) = 0
> open("/dev/bus/usb/001/001", O_RDWR) = 3
> ioctl(3, USBDEVFS_IOCTL, 0xbfdcfa3c) = 9
> close(3) = 0
> open("/dev/bus/usb/002", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> brk(0x9f80000) = 0x9f80000
> getdents(3, /* 3 entries */, 4096) = 48
> open("/dev/bus/usb/002/001", O_RDWR) = 4
> ioctl(4, USBDEVFS_CONNECTINFO, 0xbfdcdaa4) = 0
> read(4, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18
> read(4, "\t\2\31\0\1\1\0\340", 8) = 8
> read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17
> close(4) = 0
> getdents(3, /* 0 entries */, 4096) = 0
> close(3) = 0
> open("/dev/bus/usb/002/001", O_RDWR) = 3
> ioctl(3, USBDEVFS_IOCTL, 0xbfdcfa3c) = 3
> close(3) = 0
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f85000
> write(1, "Bus 004 Device 001: ID 0000:0000"..., 35Bus 004 Device 001: ID 0000:0000
> ) = 35
> write(1, "Bus 003 Device 001: ID 0000:0000"..., 35Bus 003 Device 001: ID 0000:0000
> ) = 35
> write(1, "Bus 003 Device 002: ID 0abf:03ed"..., 35Bus 003 Device 002: ID 0abf:03ed
> ) = 35
> write(1, "Bus 001 Device 001: ID 0000:0000"..., 35Bus 001 Device 001: ID 0000:0000
> ) = 35
> write(1, "Bus 002 Device 001: ID 0000:0000"..., 35Bus 002 Device 001: ID 0000:0000
> ) = 35
> exit_group(0) = ?
>
> Any idea/suggestion on what's going on?
> Is there known compatibility issue between libusb 1.0.4 and CentOS/RHEL 5?
>
> Regards,
> Alex
>
> This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
>
> If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Libusb-devel mailing list
> Libusb-devel@...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.707 / Virus Database: 270.14.68/2507 - Release Date: 11/16/09 12:53:00
>

Are you using the compatibility layer? It doesn't seem to be the case.
You need that for a 0.x app with a 1.0 library...

I've found that a multi process app has issues even with compat.
Threads are ok..

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

libusb 1.0.4 unstable on CentOS/RHEL 5.3

2009-11-16T23:45:21Z

Hi,

I have a small application that currently uses libusb 0.1.12 and runs on CentOS/RHEL 5.3 box (32 bit, with the latest kernel from updates repository - 2.6.18-164.6.1.el5). I'm trying to port it to libusb 1.0.4, however it looks like libusb 1.0.4 doesn't work in a stable manner on this platform.

I was able to reproduce the problem with a simple "lsusb" program included in examples. And it's essentially as follows: sometimes "lsusb" compiled with libusb 1.0.4 works just fine. But at other times, it fails inside the libusb_get_device_list() call with the following error:

libusb:error [usbfs_get_active_config] get_configuration failed ret=-1 errno=71

At the same time the following kernel error is logged in dmesg:

usb 3-2: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 8 len 1 ret -71

When the error happens, it continues forever until I reboot my box. The issue may or may not happen again immediately after the reboot - I wasn't able to see any clear pattern in this one...

When "lsusb with libusb 1.0.4" produces the above error, "lsusb" provided with CentOS/RHEL (and compiled with libusb 0.1.12) works just fine. See below the strace for "lsusb with libusb 1.0.4" when it produces the error:

tg-lab8::~# strace /Project/bin/exe/lsusb
execve("/Project/bin/exe/lsusb", ["/Project/bin/exe/lsusb"], [/* 18 vars */]) = 0
brk(0) = 0x9306000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f31000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/sparcv9/tls/i686/sse2/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/sparcv9/tls/i686/sse2", 0xbffa3598) = -1 ENOENT (No such file or directory)
open("/usr/lib/sparcv9/tls/i686/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/sparcv9/tls/i686", 0xbffa3598) = -1 ENOENT (No such file or directory)
open("/usr/lib/sparcv9/tls/sse2/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/sparcv9/tls/sse2", 0xbffa3598) = -1 ENOENT (No such file or directory)
open("/usr/lib/sparcv9/tls/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/sparcv9/tls", 0xbffa3598) = -1 ENOENT (No such file or directory)
open("/usr/lib/sparcv9/i686/sse2/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/sparcv9/i686/sse2", 0xbffa3598) = -1 ENOENT (No such file or directory)
open("/usr/lib/sparcv9/i686/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/sparcv9/i686", 0xbffa3598) = -1 ENOENT (No such file or directory)
open("/usr/lib/sparcv9/sse2/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/sparcv9/sse2", 0xbffa3598) = -1 ENOENT (No such file or directory)
open("/usr/lib/sparcv9/libusb-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/sparcv9", 0xbffa3598) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=15257, ...}) = 0
mmap2(NULL, 15257, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f2d000
close(3) = 0
open("/usr/lib/libusb-1.0.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\32\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=48628, ...}) = 0
mmap2(NULL, 51476, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x41c000
mmap2(0x428000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb) = 0x428000
close(3) = 0
open("/usr/lib/libstdc++.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\326\3\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=925520, ...}) = 0
mmap2(NULL, 952024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x110000
mmap2(0x1ee000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xdd) = 0x1ee000
mmap2(0x1f3000, 22232, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x1f3000
close(3) = 0
open("/lib/libm.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0204\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=206380, ...}) = 0
mmap2(NULL, 155760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4b6000
mmap2(0x4db000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24) = 0x4db000
close(3) = 0
open("/lib/libgcc_s.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\26\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=44992, ...}) = 0
mmap2(NULL, 48036, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x5dd000
mmap2(0x5e8000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa) = 0x5e8000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320_\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1603392, ...}) = 0
mmap2(NULL, 1324452, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb08000
mmap2(0xc46000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13e) = 0xc46000
mmap2(0xc49000, 9636, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xc49000
close(3) = 0
open("/lib/librt.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\30\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=42048, ...}) = 0
mmap2(NULL, 33324, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x893000
mmap2(0x89a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0x89a000
close(3) = 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000H\0\0004\0\0\0"..., 512) = 512
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f2c000
fstat64(3, {st_mode=S_IFREG|0755, st_size=123596, ...}) = 0
mmap2(NULL, 90592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x74b000
mmap2(0x75e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0x75e000
mmap2(0x760000, 4576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x760000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f2b000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f2b6d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x75e000, 4096, PROT_READ) = 0
mprotect(0x89a000, 4096, PROT_READ) = 0
mprotect(0xc46000, 8192, PROT_READ) = 0
mprotect(0x4db000, 4096, PROT_READ) = 0
mprotect(0x1ee000, 12288, PROT_READ) = 0
mprotect(0x510000, 4096, PROT_READ) = 0
munmap(0xb7f2d000, 15257) = 0
set_tid_address(0xb7f2b718) = 2859
set_robust_list(0xb7f2b720, 0xc) = 0
futex(0xbffa3e34, FUTEX_WAKE_PRIVATE, 1) = 0
rt_sigaction(SIGRTMIN, {0x74f3d0, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x74f2e0, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys="Linux", node="tg-lab8", ...}) = 0
futex(0x1f44fc, FUTEX_WAKE_PRIVATE, 2147483647) = 0
brk(0) = 0x9306000
brk(0x9327000) = 0x9327000
open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents(3, /* 6 entries */, 4096) = 96
close(3) = 0
clock_gettime(0x4 /* CLOCK_??? */, 0xbffa3c48) = -1 EINVAL (Invalid argument)
clock_getres(0xfffffffa /* CLOCK_??? */, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {5859, 53636345}) = 0
uname({sys="Linux", node="tg-lab8", ...}) = 0
stat64("/sys/bus/usb/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
pipe([3, 4]) = 0
open("/sys/bus/usb/devices", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5
fstat64(5, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
getdents(5, /* 12 entries */, 4096) = 212
stat64("/sys/bus/usb/devices/3-2/descriptors", 0xbffa2ca0) = -1 ENOENT (No such file or directory)
open("/sys/bus/usb/devices/3-2/busnum", O_RDONLY) = -1 ENOENT (No such file or directory)
close(5) = 0
open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5
fstat64(5, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
getdents(5, /* 6 entries */, 4096) = 96
open("/dev/bus/usb/004", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 6
fstat64(6, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
fcntl64(6, F_SETFD, FD_CLOEXEC) = 0
getdents(6, /* 3 entries */, 4096) = 48
open("/dev/bus/usb/004/001", O_RDWR) = 7
ioctl(7, USBDEVFS_CONTROL, 0xbffa1ce0) = 1
read(7, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18
open("/dev/bus/usb/004/001", O_RDONLY) = 8
lseek(8, 18, SEEK_SET) = 18
read(8, "\t\2\31\0\1\1", 6) = 6
close(8) = 0
lseek(7, 18, SEEK_SET) = 18
read(7, "\t\2\31\0\1\1\0\340", 8) = 8
lseek(7, 18, SEEK_SET) = 18
read(7, "\t\2\31\0\1\1\0\340\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 25) = 25
close(7) = 0
getdents(6, /* 0 entries */, 4096) = 0
close(6) = 0
open("/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 6
fstat64(6, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
fcntl64(6, F_SETFD, FD_CLOEXEC) = 0
getdents(6, /* 4 entries */, 4096) = 64
open("/dev/bus/usb/003/001", O_RDWR) = 7
ioctl(7, USBDEVFS_CONTROL, 0xbffa1ce0) = 1
read(7, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18
open("/dev/bus/usb/003/001", O_RDONLY) = 8
lseek(8, 18, SEEK_SET) = 18
read(8, "\t\2\31\0\1\1", 6) = 6
close(8) = 0
lseek(7, 18, SEEK_SET) = 18
read(7, "\t\2\31\0\1\1\0\340", 8) = 8
lseek(7, 18, SEEK_SET) = 18
read(7, "\t\2\31\0\1\1\0\340\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 25) = 25
close(7) = 0
open("/dev/bus/usb/003/002", O_RDWR) = 7
ioctl(7, USBDEVFS_CONTROL, 0xbffa1ce0) = -1 EPROTO (Protocol error)
close(7) = 0
close(6) = 0
close(5) = 0
exit_group(-1) = ?

And here is the strace for "lsusb with libusb 0.1.12" run immediately afterwards, that completes successfully:

tg-lab8::~# strace lsusb
execve("/sbin/lsusb", ["lsusb"], [/* 18 vars */]) = 0
brk(0) = 0x9edb000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=15257, ...}) = 0
mmap2(NULL, 15257, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f82000
close(3) = 0
open("/usr/lib/libusb-0.1.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\21\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=31500, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f81000
mmap2(NULL, 30232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x750000
mmap2(0x756000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0x756000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320_\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1603392, ...}) = 0
mmap2(NULL, 1324452, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x25d000
mmap2(0x39b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13e) = 0x39b000
mmap2(0x39e000, 9636, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x39e000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f80000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f806c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x39b000, 8192, PROT_READ) = 0
mprotect(0xbb0000, 4096, PROT_READ) = 0
munmap(0xb7f82000, 15257) = 0
brk(0) = 0x9edb000
brk(0x9efc000) = 0x9efc000
open("./usb.ids", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/hwdata/usb.ids", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=357262, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f85000
read(3, "#\n# List of USB ID's\n#\n#\tMai"..., 4096) = 4096
read(3, "01 Scanjet 82x0C\n\t0b0c Wireles"..., 4096) = 4096
read(3, "2500\n\t3717 EWS UPD\n\t3802 photo"..., 4096) = 4096
read(3, " series\n\tb202 photosmart 7600 s"..., 4096) = 4096
read(3, ", Receipt/Slip\n\t0312 7197 Print"..., 4096) = 4096
read(3, "Camera\n\t05c3 Digital Camera\n\t05"..., 4096) = 4096
read(3, "nal Composite Device\n\t3010 Soun"..., 4096) = 4096
read(3, "ent\n\t043c 6155 Phone Parent\n\t04"..., 4096) = 4096
read(3, "t Copy\n\t0042 Scan Print Copy\n\t0"..., 4096) = 4096
read(3, "tor\n\t0051 Integrated Hub\n0453 "..., 4096) = 4096
read(3, "l MultiMedia Keyboard\n\t0065 Wir"..., 4096) = 4096
read(3, "C 2003\n\t0457 Windows Powered Po"..., 4096) = 4096
read(3, " Mouse\n\t4d2a PoPo Elixir Mouse "..., 4096) = 4096
read(3, "se\n\tc01a M-BQ85 Optical Wheel M"..., 4096) = 4096
read(3, "2 BTC 7932 mouse+keyboard\n046f "..., 4096) = 4096
read(3, "e\n\t1061 PocketMouse Grip\n\t1062 "..., 4096) = 4096
read(3, "000 DTX\n\t7010 UB99\n049a Ganda"..., 4096) = 4096
read(3, "\t1055 BJC-85\n\t1056 BJC-2110 Co"..., 4096) = 4096
read(3, " IXY Digital\n\t3047 Digital IXUS"..., 4096) = 4096
read(3, " Coolpix 5000 (ptp)\n\t0114 Cool"..., 4096) = 4096
read(3, "a\n\t0402 PhotoPC 850z\n\t0403 Pho"..., 4096) = 4096
read(3, " Ltd\n\t1029 fi-4010c Scanner\n\t10"..., 4096) = 4096
read(3, "Lansing HID Audio Controls\n\tff49"..., 4096) = 4096
read(3, "erface\n\t0008 3000U AccuTouch\302\256 "..., 4096) = 4096
brk(0x9f1d000) = 0x9f1d000
read(3, "RITE CCD Webcam(PC370R)\n\ta128 P"..., 4096) = 4096
read(3, "CP-540CN\n\t01ab MFC-240C\n\t01ae "..., 4096) = 4096
read(3, " F1DF102U/F1DG102U Flip Hub\n\t32"..., 4096) = 4096
read(3, " Color Pocket PC V37\n\t152b Colo"..., 4096) = 4096
read(3, "6 MEMORY P-AUDIO\n\t01c7 Printin"..., 4096) = 4096
read(3, "nterface Corp.\n0561 Oasis Desig"..., 4096) = 4096
read(3, "auge WinTV-USB Model 40204 rev B"..., 4096) = 4096
read(3, "0584 RATOC System, Inc.\n\t0008 "..., 4096) = 4096
read(3, "rive USB2\n\t0203 StudioDrive USB"..., 4096) = 4096
read(3, "ernational, Inc.\n\t0002 AccelePo"..., 4096) = 4096
read(3, "0c1 USB600 Scanner\n\t30ce ScanM"..., 4096) = 4096
read(3, "e Device\n\t0715 USB 2.0 microSD "..., 4096) = 4096
read(3, "odiak KM-9010\n\t9003 VoIP Confer"..., 4096) = 4096
read(3, "2 MP3 Player\n\t8124 MP3 Player\n"..., 4096) = 4096
read(3, "00c Dimage F100 Camera\n\t400d S"..., 4096) = 4096
read(3, "d\n06ae Professional Multimedia "..., 4096) = 4096
read(3, "re\n\t0066 TRUST Digital PCTV and"..., 4096) = 4096
read(3, "e06 EZ-Connect 802.11g Adapter\n"..., 4096) = 4096
read(3, "C\n074d Micronas GmbH\n\t3553 Com"..., 4096) = 4096
read(3, "0 Cruzer Mini\n\t7101 Pen Flash\n"..., 4096) = 4096
read(3, " Wireless Adapter WU830G\n07b3 P"..., 4096) = 4096
read(3, "Reader\n\t0005 Reader (UISA2SE)\n\t"..., 4096) = 4096
read(3, "rk of the Unicorn\n\t0000 FastLan"..., 4096) = 4096
brk(0x9f3e000) = 0x9f3e000
read(3, "ros AR5004X / AR5005UX]\n\t4301 W"..., 4096) = 4096
read(3, "eakers\n\t2900 PCM2900 Audio Code"..., 4096) = 4096
read(3, "c.\n\t1600 AES1600\n\t1610 AES1600"..., 4096) = 4096
read(3, "800 Quad Joypad\n\t8866 WiseGroup"..., 4096) = 4096
read(3, "ion Laboratories\n094f Yano\n\t010"..., 4096) = 4096
read(3, "Systems Inc.\n\t0064 ADU100 Data "..., 4096) = 4096
read(3, "oth Dongle\n\t2033 BCM2033 Blueto"..., 4096) = 4096
read(3, "ro generic vc0321 Camera\n\t0323 "..., 4096) = 4096
read(3, "er\n\t1612 AIR.Mate 2@net 802.11b"..., 4096) = 4096
read(3, " Sync\n\t0a1e PocketPC Sync\n\t0a1f"..., 4096) = 4096
read(3, "compliant)\n\t000c Transceiver (A"..., 4096) = 4096
read(3, "r\n\t1028 Mass Storage Reader\n\t10"..., 4096) = 4096
read(3, "0 Spectrum Digital XDS510 JTAG "..., 4096) = 4096
read(3, "g Wireless LAN Adapter(3887A)\n\t0"..., 4096) = 4096
read(3, "Line Tek Electronic Co., Ltd\n0d7"..., 4096) = 4096
read(3, "RT2570\n\t6874 RT2573\n\t6877 RT25"..., 4096) = 4096
read(3, " iAudio U3\n0e22 Symbian Ltd.\n0"..., 4096) = 4096
read(3, "td\n\t0001 eGalax TouchScreen\n\t00"..., 4096) = 4096
read(3, "\n\tdb78 FusionHDTV DVB-T Dual Di"..., 4096) = 4096
read(3, "Serial Port (WDM)\n\t1303 Packet "..., 4096) = 4096
read(3, "01 USB-Module for Spider8, CP32"..., 4096) = 4096
read(3, "885 Device\n\t6870 MC8780 Device\n"..., 4096) = 4096
read(3, "B 2.0 Adapter\n\t5f01 WPN111 (no "..., 4096) = 4096
read(3, " usbtty generic serial\n\t5121 Op"..., 4096) = 4096
read(3, "ra Technologies Corp.\n15f4 Hanf"..., 4096) = 4096
brk(0x9f5f000) = 0x9f5f000
read(3, "ax Digital Inc.\n168c Atheros Co"..., 4096) = 4096
read(3, "B-U2000 - DVB-T USB cold\n\td001 "..., 4096) = 4096
read(3, "6000/8/DIO\n\t604f ME-6000/16/DIO"..., 4096) = 4096
read(3, "c.\n1d6b Linux Foundation\n\t0001 "..., 4096) = 4096
read(3, "Net)\n\t6006 MOTOROKR E6\n\t6008 D"..., 4096) = 4096
read(3, " acquisition card) firmware upda"..., 4096) = 4096
read(3, "x printer adapter cable\n4572 Sh"..., 4096) = 4096
read(3, "nterface level)\nC 01 Audio\n\t01 "..., 4096) = 4096
read(3, "Receiver\nAT 0711 Radio Transmit"..., 4096) = 4096
read(3, "it\n\t003 Flexor\n\t004 Glove\n\t005"..., 4096) = 4096
read(3, "89 International 3 (PC98)\n\t08a "..., 4096) = 4096
read(3, "\n\t082 Mode Step\n\t083 Recall La"..., 4096) = 4096
read(3, "ly\n\t23b AC Tile Vertically\n\t23c"..., 4096) = 4096
read(3, "rol\n\t002 EDID Information\n\t003 "..., 4096) = 4096
read(3, "Relative State Of Charge\n\t065 A"..., 4096) = 4096
read(3, "sh\nHCC 08 French\nHCC 09 German"..., 4096) = 910
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7f85000, 4096) = 0
open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents(3, /* 6 entries */, 4096) = 96
close(3) = 0
open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents(3, /* 6 entries */, 4096) = 96
getdents(3, /* 0 entries */, 4096) = 0
close(3) = 0
open("/dev/bus/usb/004", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents(3, /* 3 entries */, 4096) = 48
open("/dev/bus/usb/004/001", O_RDWR) = 4
ioctl(4, USBDEVFS_CONNECTINFO, 0xbfdcdaa4) = 0
read(4, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18
read(4, "\t\2\31\0\1\1\0\340", 8) = 8
read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17
close(4) = 0
getdents(3, /* 0 entries */, 4096) = 0
close(3) = 0
open("/dev/bus/usb/004/001", O_RDWR) = 3
ioctl(3, USBDEVFS_IOCTL, 0xbfdcfa3c) = 3
close(3) = 0
open("/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents(3, /* 4 entries */, 4096) = 64
open("/dev/bus/usb/003/001", O_RDWR) = 4
ioctl(4, USBDEVFS_CONNECTINFO, 0xbfdcdaa4) = 0
read(4, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18
read(4, "\t\2\31\0\1\1\0\340", 8) = 8
read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17
close(4) = 0
open("/dev/bus/usb/003/002", O_RDWR) = 4
ioctl(4, USBDEVFS_CONNECTINFO, 0xbfdcdaa4) = 0
read(4, "\22\1\20\1\0\0\0@\277\n\355\3\4\0\1\2\3\1", 18) = 18
read(4, "\t\2Z\0\1\1\0\300", 8) = 8
read(4, "2\t\4\0\0\4\377\0\0\0\7\5\2\2@\0\0\7\5\4\2@\0\0\7\5\202\2@\0\0\7"..., 82) = 82
close(4) = 0
getdents(3, /* 0 entries */, 4096) = 0
close(3) = 0
open("/dev/bus/usb/003/001", O_RDWR) = 3
ioctl(3, USBDEVFS_IOCTL, 0xbfdcfa3c) = 3
close(3) = 0
open("/dev/bus/usb/003/002", O_RDWR) = 3
ioctl(3, USBDEVFS_IOCTL, 0xbfdcfa3c) = -1 ENOTTY (Inappropriate ioctl for device)
close(3) = 0
open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents(3, /* 3 entries */, 4096) = 48
open("/dev/bus/usb/001/001", O_RDWR) = 4
ioctl(4, USBDEVFS_CONNECTINFO, 0xbfdcdaa4) = 0
read(4, "\22\1\0\2\t\0\1@\0\0\0\0\6\2\3\2\1\1", 18) = 18
read(4, "\t\2\31\0\1\1\0\340", 8) = 8
read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\f", 17) = 17
close(4) = 0
getdents(3, /* 0 entries */, 4096) = 0
close(3) = 0
open("/dev/bus/usb/001/001", O_RDWR) = 3
ioctl(3, USBDEVFS_IOCTL, 0xbfdcfa3c) = 9
close(3) = 0
open("/dev/bus/usb/002", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
brk(0x9f80000) = 0x9f80000
getdents(3, /* 3 entries */, 4096) = 48
open("/dev/bus/usb/002/001", O_RDWR) = 4
ioctl(4, USBDEVFS_CONNECTINFO, 0xbfdcdaa4) = 0
read(4, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18
read(4, "\t\2\31\0\1\1\0\340", 8) = 8
read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17
close(4) = 0
getdents(3, /* 0 entries */, 4096) = 0
close(3) = 0
open("/dev/bus/usb/002/001", O_RDWR) = 3
ioctl(3, USBDEVFS_IOCTL, 0xbfdcfa3c) = 3
close(3) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f85000
write(1, "Bus 004 Device 001: ID 0000:0000"..., 35Bus 004 Device 001: ID 0000:0000
) = 35
write(1, "Bus 003 Device 001: ID 0000:0000"..., 35Bus 003 Device 001: ID 0000:0000
) = 35
write(1, "Bus 003 Device 002: ID 0abf:03ed"..., 35Bus 003 Device 002: ID 0abf:03ed
) = 35
write(1, "Bus 001 Device 001: ID 0000:0000"..., 35Bus 001 Device 001: ID 0000:0000
) = 35
write(1, "Bus 002 Device 001: ID 0000:0000"..., 35Bus 002 Device 001: ID 0000:0000
) = 35
exit_group(0) = ?

Any idea/suggestion on what's going on?
Is there known compatibility issue between libusb 1.0.4 and CentOS/RHEL 5?

Regards,
Alex

This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: Hotplug

2009-11-16T07:47:23Z

I am running Debian etch and lenny. I don't see libudev in either /lib
or /usr/lib. (I see libudev0 in the Synaptic package manager, but I have
not downloaded it and there is no additional version info on it).

When you get going on this, please keep me informed. I would be happy to
provide some testing and feedback.

Thanks again.

-- Phil

-----Original Message-----
From: Daniel Drake [mailto:dan@...]
Sent: Sunday, November 15, 2009 6:57 AM
To: Philip Joslin - C10554
Cc: libusb-devel@...
Subject: Re: [Libusb-devel] Hotplug

Philip.Joslin@... wrote:
> I have seen discussion that hotplug support was going to be included
> in libusb 2.0. Is there a timetable for hotplug?

I think we'll include it in the near future.

I've just started to work on a libudev-based implementation. This means
it will require a fairly modern Linux platform.

I'll design it so that adding a dbus-based hotplug backend will be
possible in future. Then it could listen for events from HAL on older
platforms, covering a larger userbase.

Which platform setup will you be running on? Does it have libudev? (just
a quick ls in /lib or /usr/lib should a be good enough answer)

I guess we also have some embedded users interested in this
functionality too, who probably don't have udev (or perhaps simply don't
yet have a modern version with libudev), or are Linux 2.4 users, in
which case adding a "plan C" backend may also be appropriate too: one
that creates a thread that watches for changes in the usbfs directories.

Then we should have everything covered...

> I would much rather just give libusb a callback for a specific device
> and have that callback notified when the unit is unplugged. And have a

> "general" callback that would be called when a new device is plugged
in.
> Is this the way the hotplug is planned?

More or less - lets see what I come up with :)

Daniel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: usb_get_string() error

2009-11-16T06:48:05Z

Peter Stuge wrote:

> Russell Shaw wrote:
>> I got it working now. Directory permissions must have been wrong.
>> I did: sudo chmod -R +X /dev/bus
>
> This is total overkill.
>
> Please find out which particular device file the program fails on.
>
> One way is to reboot, and run your program with strace, then look for
> the system call which fails with EPERM. Your udev rules are not
> correct, or are not being applied to your device.

Hi,
I did that temporarily as a test. Later i cleaned up the whole of /dev
by setting sane permissions, then rebooted and checked anyway. I have
a simple udev rule now.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: usb_get_string() error

2009-11-16T06:21:18Z

Russell Shaw wrote:
> I got it working now. Directory permissions must have been wrong.
> I did: sudo chmod -R +X /dev/bus

This is total overkill.

Please find out which particular device file the program fails on.

One way is to reboot, and run your program with strace, then look for
the system call which fails with EPERM. Your udev rules are not
correct, or are not being applied to your device.

//Peter

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: usb_get_string() error

2009-11-16T06:18:03Z

Russell Shaw wrote:

> Hi,
> What causes usb_get_string() to return -1 ?
>
> I've found this in an existing program that should work,
> with the right usb device plugged in.
>
> I've tried changing permissions with udev rules without
> success.
>
> The program works as root. Is there a permission in /dev
> that should fix it?

I got it working now. Directory permissions must have been wrong.
I did: sudo chmod -R +X /dev/bus

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel