Nabble - LibUSB

Re: Darwin, multiple contexts and global variables

2009-12-17T14:35:53Z

Classify this as an oops. Like multiple opens I never tested (or thought about) multiple contexts. Those variables should not be tied to any context and I will provide the fix later today.

-Nathan
 
On Thursday, December 17, 2009, at 03:21PM, "Orin Eman" <orin.eman@...> wrote:
>------------------------------------------------------------------------------
>This SF.Net email is sponsored by the Verizon Developer Community
>Take advantage of Verizon's best-in-class app development support
>A streamlined, 14 day to market process makes app distribution fast and easy
>Join now and get one step closer to millions of Verizon customers
>http://p.sf.net/sfu/verizon-dev2dev 
>_______________________________________________
>Libusb-devel mailing list
>Libusb-devel@...
>https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>

Needless to say, it doesn't work. Not that I was trying to do it deliberately, but my existing code called libusb_init() for a new context before libusb_exit() for a previous context had been called and/or had returned (a usage-counted object that was "Release'd" but not actually deleted until all the threads it had created exited).

The problem is that the Darwin backend uses three global variables:

libusb_darwin_acfl, libusb_darwin_mp and libusb_darwin_at.

A second or subsequent call to libusb_init() without an intervening libusb_exit() will overwrite these variables with varying results depending on timing - usually a LIBUSB_ERROR_INVALID_PARAM error from libusb_get_device_list() due to libusb_darwin_mp being NULL or a bus error due to libusb_darwin_acfl being NULL in the call to CFRunLoopStop() some time later.

It seems to me that these variables should be in the libusb_context structure... but that wouldn't work as the context isn't passed to darwin_exit() and there is currenly no support for backend private data in the context structure. Perhaps the context structure should allow backend private data and be passed to the backend exit function. Currently, the lack of passing the context structure precludes use of logging in the backend exit functions at least.

If these variables cannot be moved to context structure, then they need protecting. At the least, a re-entrancy flag would do the trick with darwin_init() returning LIBUSB_ERROR_BUSY if these variables are in use. Certainly, my problems are much reduced by such a re-entrancy flag, though I put it in libusb_init() for test purposes.

Orin.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Darwin, multiple contexts and global variables

2009-12-17T14:21:51Z

The problem is that the Darwin backend uses three global variables:

libusb_darwin_acfl, libusb_darwin_mp and libusb_darwin_at.

Orin.

From forum: LibUSB Dev

Re: how to retrieve an usb mass storage serial number ?

2009-12-17T14:01:27Z

Tim Roberts wrote:

> You do realize that making a statement like this in a Linux/open source
> environment relegates you to the 7th level of hell, right? DRM is the
> root of much of the evil in the computing world today. DRM was the
> underlying cause of virtually all of the issues that made Vista a disaster.

A desire to hamper unauthorized software duplication is understandable
in the current internet environment when it comes to high value
commercial software. If there are no reasonable mechanisms available
for this, commercial software simply won't be available on Linux,
and Linux will continue to be regarded as a bit of a toy for
many people. (The distro. model of software deployment doesn't
help this either.)

> Yes -- don't do it. This kind of thing only stops the people who
> wouldn't have copied the software anyway. The hackers will crack your
> scheme in a few minutes. It's better just to save yourself the trouble.

You missed the other category of people, those who aren't so technically
astute as to crack the software, but don't have the morals that would
prevent them from making a copy for themselves and all their
friends. While it's true that it's almost impossible to stop a technically
inclined person cracking such a scheme, it can be useful in slowing down
casual copying.

> Further, libusb is licensed under LGPL. When you release a project that
> uses libusb, you are obligated by law to follow certain procedures that
> open up your application. For example, you need to provide the ability
> for others to build a version of your application that uses a slightly
> different version of libusb. You can't just suck up this software for
> free and lock it up tight. You need to read the LGPL (which is included
> with the libusb source code) and understand exactly what you are
> agreeing to.

This isn't exactly relevant. As long as the LGPL license terms are
complied with (ie. linking it at run time and making the source available),
it can be used as part of a copy protection mechanism.

Graeme Gill.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: how to retrieve an usb mass storage serial number ?

2009-12-17T10:28:54Z

Benoit DECHERF wrote:

>
>
> Feel free to explain more about what you want to accomplish - maybe
> we can suggest a good solution. Without a good understanding of what
> to do it's difficult to help. Maybe you have no option but creating a
> small service running as root which can be used to ask for serial
> numbers. I don't know...
>
>
> Thanks, your explication help me a lot to understand my problem ;)
>
> So, I'd like to reproduce the DRM process to protect files against
> copying.

You do realize that making a statement like this in a Linux/open source
environment relegates you to the 7th level of hell, right? DRM is the
root of much of the evil in the computing world today. DRM was the
underlying cause of virtually all of the issues that made Vista a disaster.

> I'm developping a software. The software can copy itself on an usb
> drive for offline use. But I wan't to protect it from being copied
> from the usb drive to another. So my idea was to encrypt a part of the
> software with a specific ID of the USB drive (And the ID will be
> serial number).
> So the process to retrieve the serial number have to be cross
> plateform (I'm developping the software in java).
>
> Is there a good solution of the problem ?

Yes -- don't do it. This kind of thing only stops the people who
wouldn't have copied the software anyway. The hackers will crack your
scheme in a few minutes. It's better just to save yourself the trouble.

Further, libusb is licensed under LGPL. When you release a project that
uses libusb, you are obligated by law to follow certain procedures that
open up your application. For example, you need to provide the ability
for others to build a version of your application that uses a slightly
different version of libusb. You can't just suck up this software for
free and lock it up tight. You need to read the LGPL (which is included
with the libusb source code) and understand exactly what you are
agreeing to.

--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: how to retrieve an usb mass storage serial number ?

2009-12-17T08:21:47Z

Feel free to explain more about what you want to accomplish - maybe
we can suggest a good solution. Without a good understanding of what
to do it's difficult to help. Maybe you have no option but creating a
small service running as root which can be used to ask for serial
numbers. I don't know...

Thanks, your explication help me a lot to understand my problem ;)

So, I'd like to reproduce the DRM process to protect files against copying.

I'm developping a software. The software can copy itself on an usb drive for offline use. But I wan't to protect it from being copied from the usb drive to another. So my idea was to encrypt a part of the software with a specific ID of the USB drive (And the ID will be serial number).
So the process to retrieve the serial number have to be cross plateform (I'm developping the software in java).

Is there a good solution of the problem ?

As a workaround, there are os specific solution:
In windows, I don't do any test yet, but I found some solution on internet to retrieve it.
In linux, there is the "Alan Stern" solution (but it's probably dependent of the distribution, don't it ? )
In macosx, I still don't have any idea :(

Benoit

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: how to retrieve an usb mass storage serial number ?

2009-12-17T06:59:56Z

On Thu, 17 Dec 2009, Benoit DECHERF wrote:

> 2009/12/17 Peter Stuge <peter@...>
>
> > Benoit DECHERF wrote:
> > > I'm trying to use libusb to get the serial number of an usb mass
> > > storage devise.
> >
> > This is simply not appropriate use of libusb if the kernel driver
> > will be used for this device.
> >
>
> mmm, that's not so clear for me... Each usb device has a serial number ?
> The method I tried works as a root user. So why should I use directly the
> kernel driver to get the same infromation with less permissions ?

Under Linux you don't have to do any fancy programming. You can get
the USB serial number string by reading

/sys/bus/usb/devices/.../serial

where you replace "..." with the device's name (e.g., "3-2").

Alan Stern

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: how to retrieve an usb mass storage serial number ?

2009-12-17T01:22:51Z

Benoit DECHERF wrote:
> > > I'm trying to use libusb to get the serial number of an usb mass
> > > storage devise.
> >
> > This is simply not appropriate use of libusb if the kernel driver
> > will be used for this device.
>
> mmm, that's not so clear for me...

libusb is used to write device drivers. If a device driver in the
kernel is already active for this device then there is no place for a
libusb device driver.

> Each usb device has a serial number ?

No, not always actually. Some products do, others don't. It's not a
requirement, only a very good idea.

> The method I tried works as a root user.

You are going behind the back of the kernel in a sense. root can do
that because he is expected to know about and accept the possible
consequences. Normal users not so much.

> So why should I use directly the kernel driver to get the same
> infromation with less permissions ?

There can only be one device driver for each USB interface and since
there is an active driver, that's generally what you should use
to communicate with the device. There will also be permissions for
this device already set up by your system; udev rules control which
users are allowed to do what with which block devices, and if you
depend on this for security in your application it isn't a good idea
to allow users direct access to the USB device, because they can then
change the state of the device behind the device driver's back.

> > Try to replicate what sdparm --page=sn /dev/sda does:
> >
> > open("/dev/sda", O_RDONLY|O_NONBLOCK) = 3
> > ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[6]=[12, 01, 80, 00, fc, 00],
> > mx_sb_len=32, iovec_count=0, dxfer_len=252, timeout=60000, flags=0,
> > data[252]=["\0\200\0\24 DDZ050708222006\0\0\0\0\0\0\0\0\0"...],
> > status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0,
> > resid=0, duration=0, info=0}) = 0
>
> sdparm doesn't seems to works on usb memory stick :
> $ sudo sdparm --all /dev/sdc1
> /dev/sdc1: SanDisk SanDisk Cruzer 8.02
> Read write error recovery mode page:
> >>> warning: mode page seems malformed
> The page number field should be 0x01, but is 0x00; try '--flexible'
> ...

It can possibly make a big difference that you are running sdparm
with the partition rather than the device here. Also, that page error
would make me ask only for the serial number rather than all possible
information.

Feel free to explain more about what you want to accomplish - maybe
we can suggest a good solution. Without a good understanding of what
to do it's difficult to help. Maybe you have no option but creating a
small service running as root which can be used to ask for serial
numbers. I don't know...

//Peter

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: how to retrieve an usb mass storage serial number ?

2009-12-16T23:43:22Z

2009/12/17 Peter Stuge <peter@...>

Benoit DECHERF wrote:
> I'm trying to use libusb to get the serial number of an usb mass
> storage devise.

This is simply not appropriate use of libusb if the kernel driver
will be used for this device.

mmm, that's not so clear for me... Each usb device has a serial number ?
The method I tried works as a root user. So why should I use directly the kernel driver to get the same infromation with less permissions ?

> How should I do this ?

Use the kernel interface that exposes this device: SCSI storage.

Try to replicate what sdparm --page=sn /dev/sda does:

open("/dev/sda", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[6]=[12, 01, 80, 00, fc, 00], mx_sb_len=32, iovec_count=0, dxfer_len=252, timeout=60000, flags=0, data[252]=["\0\200\0\24 DDZ050708222006\0\0\0\0\0\0\0\0\0"...], status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=0, info=0}) = 0

sdparm doesn't seems to works on usb memory stick :
$ sudo sdparm --all /dev/sdc1
/dev/sdc1: SanDisk SanDisk Cruzer 8.02
Read write error recovery mode page:
>>> warning: mode page seems malformed
The page number field should be 0x01, but is 0x00; try '--flexible'
...

Benoit

From forum: LibUSB Dev

Re: how to retrieve an usb mass storage serial number ?

2009-12-16T15:33:27Z

Benoit DECHERF wrote:

>
> I'm trying to use libusb to get the serial number of an usb mass
> storage devise.
>
> This work when the code is executed as root. But I get a permission
> denied when I execute it with a normal user.
>
> I use this exemple:
> http://mpathirage.com/getting-started-with-libusb-on-ubuntu/
> With normal user, I get:
> - Unable to fetch serial number string
>
> How should I do this ?

Well, either you run the program as root, or you use udev to change the
permissions on the device.

--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: how to retrieve an usb mass storage serial number ?

2009-12-16T15:30:19Z

Benoit DECHERF wrote:
> I'm trying to use libusb to get the serial number of an usb mass
> storage devise.

This is simply not appropriate use of libusb if the kernel driver
will be used for this device.

> How should I do this ?

Use the kernel interface that exposes this device: SCSI storage.

Try to replicate what sdparm --page=sn /dev/sda does:

open("/dev/sda", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[6]=[12, 01, 80, 00, fc, 00], mx_sb_len=32, iovec_count=0, dxfer_len=252, timeout=60000, flags=0, data[252]=["\0\200\0\24 DDZ050708222006\0\0\0\0\0\0\0\0\0"...], status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=0, info=0}) = 0

//Peter

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

how to retrieve an usb mass storage serial number ?

2009-12-16T15:14:17Z

Hi,

I'm trying to use libusb to get the serial number of an usb mass storage devise.

This work when the code is executed as root. But I get a permission denied when I execute it with a normal user.

I use this exemple: http://mpathirage.com/getting-started-with-libusb-on-ubuntu/
With normal user, I get:
- Unable to fetch serial number string

How should I do this ?

Thanks,
Benoit

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

threading and event handling

2009-12-15T06:51:21Z

Hello!

I do have problems with libusb in a threaded application.
libusb is wrapped in a C++ class, for each device to handle
there exists an instance of this usb wrapper class.
Each class has its own thread responsible for event handling.
This thread polls on fds retrieved by libusb_get_pollfds. The
thread is stopped when i submit a synchronous transfer, in my case
a control transfer. The thread is started again when i use an asynchronous
transfer.
A graphical overview is given in
http://www.student.tugraz.at/m.weiss/threads_overview.pdf
Could this strategy lead to a problem?

I also have some data corruption when i start and stop the data acqusition.
Therefor i have to submit a control transfer
with the start command. Within a loop i ask for the data using
an asynchronous interrupt transfer. An event indicates when the data
submission was a success. The event is triggered within the callback
function (libusb callback fn). Then another interrupttransfer is
submitted and so on.
In the first cycle ( start / stop data acquisition ) everything works fine
( i did some data acqusition for abaout an hour).
But if i do some tests within a loop, i.e.
[start] --> [daq for 3s or so] --> [stop] --> [start] ... the received
data are
possibly corrupt (at least in the 3rd cycle...).
A graphical overview is given in
http://www.student.tugraz.at/m.weiss/daq.pdf
Source of the thread which handles the events is given in
http://www.student.tugraz.at/m.weiss/handle_events.pdf
Does anyone have an idea?
Could this problem eventually be linked to the event handling?

I also like to say thank you for the support in the last months. i
wish all of you the very best for the next year.

manfred

--
manfred weiss

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Working (preferably free) USB sniffer for Windows 7 x64?

2009-12-15T04:18:58Z

Hi,

While trying to investigate the device-less external hub descriptor
issue on Windows, I've been trying a couple USB Sniffers, but I found
that none of the ones I found appear to work against Windows 7 x64.

SnoopyPro (http://sourceforge.net/projects/usbsnoop/) doesn't seem to
have been updated since 2002, and only offers 32 bit drivers.

SniffUSB (http://www.pcausa.com/Utilities/UsbSnoop/), which also seems
to be based on the usbsnoop source, does provide x64 drivers (with valid
signatures even) and supposedly works with Vista x64, but the driver
produces a nasty BSOD when used on my Windows 7 x64 platform, with what
looks like a NULL pointer dereference - ouch!
I tried recompiling both the application and the driver from scratch,
but got the same issue, so it doesn't look like any of those will help.

Anybody here know of a USB Sniffer that works with Windows 7 x64 yet?

Regards,

/Pete

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: libusb-compat x libusb0: new incompatibility (long request, short transfer, Brother scanner)

2009-12-14T12:37:47Z

On Mon, 14 Dec 2009, Stanislav Brabec wrote:

> Well, I don't have this scanner at my hands, but it seems, that the
> problem is caused by the continuation URB, which is not properly
> cancelled, and by concatenation of read data with surplus data from the
> continuation URB.
>
> > > It was tested with the latest libusb-1.0.6. Older version even did not
> > > start to scan.
> >
> > And it doesn't work with libusb-1.0.6 and the new kernel?
> > In that case, I don't understand the problem.
>
> With libusb-0.1.12, it scans in both low and high resolution.
>
> With libusb-1.0.3, it does not work at all.
>
> With libusb-1.0.6 and linux-2.6.31.5, it scans in low resolution. In
> high resolution it scans several lines and hangs.
>
> With libusb-1.0.6 and linux-2.6.32rc6, it scans in low resolution. In
> high resolution it scans several lines and hangs and complies to syslog:
> "usbfs: usb_submit_urb returned -121"

That complaint is merely a debugging message. It proves that a
continuation URB (there may have been more than one) failed during
submission.

> According to the documentation, it is caused by URB_SHORT_NOT_OK.
>
> > Under this new configuration, given an example of 3 16kb bulk URBs
> > submitted in parallel, if the first one ends early then the other 2 will
> > be immediately cancelled with no possibility for data to arrive in them,
> > as if they had never been submitted. This gives both the performance
> > advantage plus the logical transfer separation that was implemented by
> > libusb-0.1.
>
> In case of reported bug, the other URBs are not cancelled as they
> should, but data are sent back. I don't know, which side is responsible
> for this behavior (kernel? host controller? scanner?).
>
> Here is my theory what is happening:
>
> 32000 bytes is requested. The request is split to 2 URBs by libusb and
> sent to the kernel.
>
> The scanner returns an amount of data, which is partially unpredictable,
> but always less than requested 32000 bytes, and even less than 16384.
>
> The scanner does not wait for completing the buffer, but it sends data
> it actually has. It occurs in a single short transfer.
>
> Until that moment, it is perfectly correct.
>
> But in case of libusb1, scanner now starts to send data and fill the
> continuation URB. In my opinion it is incorrect and the request should
> have been cancelled after the short transfer occurrence.

Try collecting a usbmon trace. That will show you exactly what is
happening, so you won't have to theorize.

Alan Stern

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: libusb-compat x libusb0: new incompatibility (long request, short transfer, Brother scanner)

2009-12-14T11:08:34Z

El 14/12/09 18:47, Stanislav Brabec escribió:
> Off-topic: Do you have any idea, why user space transfers have these
> limits hardcored?

This has been discussed various times before - basically it's because
the kernel has to make an equivalent sized allocation of physically
contiguous memory and even asking for 16kb is pushing it.

Daniel

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: libusb-compat x libusb0: new incompatibility (long request, short transfer, Brother scanner)

2009-12-14T11:04:53Z

Stanislav Brabec wrote:
> Off-topic: Do you have any idea, why user space transfers have these
> limits hardcored?
>

Well, there has to be SOME limit. USB is entirely DMA-driven, so all of
the pages in all queued transfers have to be page-locked into RAM. It's
not productive to lock up an infinite amount of virtual memory for
queued transactions.

Windows happens to have a larger limit (it varies by operating system,
but is currently small integer megabytes). Linux happens to have a
smaller limit. As long as there is a limit, you have to deal with it
somehow.

--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: libusb-compat x libusb0: new incompatibility (long request, short transfer, Brother scanner)

2009-12-14T11:01:35Z

On Mon, Dec 14, 2009 at 07:47:43PM +0100, Stanislav Brabec wrote:
> Off-topic: Do you have any idea, why user space transfers have these
> limits hardcored?

We had to pick something, do you have a better idea?

thanks,

greg k-h

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: libusb-compat x libusb0: new incompatibility (long request, short transfer, Brother scanner)

2009-12-14T10:47:43Z

Greg KH wrote:

> That's because there is no 'usbdevfs' as mentioned above :)

Thanks for correction, I misspelled USB_DEVICEFS:

config USB_DEVICEFS
bool "USB device filesystem (DEPRECATED)"

Off-topic: Do you have any idea, why user space transfers have these
limits hardcored?

--
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@...
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: libusb-compat x libusb0: new incompatibility (long request, short transfer, Brother scanner)

2009-12-14T10:45:29Z

El 14/12/09 18:28, Stanislav Brabec escribió:
> Yes, now I understand the performance problem. But it is the way libusb0
> works, and software may depend on this behavior.

Yes, its a bug. We should fix libusb-1.0 to not parallelize URBs on old
kernels where we cannot guarantee this behaviour.

> But in case of libusb1, scanner now starts to send data and fill the
> continuation URB. In my opinion it is incorrect and the request should
> have been cancelled after the short transfer occurrence.

That's a bug. All the code is in place so that situation is not possible
(the 2nd URB in the transfer in your example would have been atomically
cancelled when the 1st URB completed early), but perhaps it is not
working correctly.

Daniel

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: libusb-compat x libusb0: new incompatibility (long request, short transfer, Brother scanner)

2009-12-14T10:38:22Z

On Mon, Dec 14, 2009 at 07:28:50PM +0100, Stanislav Brabec wrote:

> Daniel Drake wrote:
>
> > usbfs is still used by libusb and is not deprecated.
>
> Sorry for confusion:
>
> Thing called usbfs inside kernel is still used and handles device nodes
> in /dev and /sys.
>
> usbdevfs that handled /proc/bus/usb (called usbfs in fstab) is the
> deprecated thing. In recent libusb, /dev/bus/usb takes precedence.

Yes.

And note, the name "usbdevfs" has been gone from the Linux kernel for
about 5 years now, and isn't even in the 2.4 kernel series either. It's
just "usbfs" please.

> The code in drivers/usb/core/devio.c seems to handle both usbfs and
> usbdevfs. I still see at least these two limits there:

That's because there is no 'usbdevfs' as mentioned above :)

Hope this helps reduce confusion in the future.

thanks,

greg k-h

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: libusb-compat x libusb0: new incompatibility (long request, short transfer, Brother scanner)

2009-12-14T10:28:50Z

Daniel Drake wrote:

> usbfs is still used by libusb and is not deprecated.

Sorry for confusion:

Thing called usbfs inside kernel is still used and handles device nodes
in /dev and /sys.

usbdevfs that handled /proc/bus/usb (called usbfs in fstab) is the
deprecated thing. In recent libusb, /dev/bus/usb takes precedence.

The code in drivers/usb/core/devio.c seems to handle both usbfs and
usbdevfs. I still see at least these two limits there:

#define MAX_USBFS_BUFFER_SIZE 16384

case USBDEVFS_URB_TYPE_ISO:
...
if (totlen > 32768)

> >> It will hurt performance
> >> significantly, but I guess that would be acceptable.
> >
> > Are you sure? Looking at the libusb-1.0.6, it never submits bulk URBs
> > larger than 16kB (MAX_BULK_BUFFER_LENGTH) as well.
>
> Yes. libusb-1.0 submits URBs in parallel, whereas libusb-0.1 did them in
> serial. The parallelization goes all the way down to the hardware level,
> where all the individual packet buffers are queued, resulting in a
> significant performance increase.

Yes, now I understand the performance problem. But it is the way libusb0
works, and software may depend on this behavior.

> The problem that this resulted in is that libusb couldn't avoid the
> parallel-queued URBs from being filled up after an earlier one completed
> early (there's no way it could cancel them in time, no matter how hard
> it tried), and from briefly reading your bug report, this seems to be
> what is happening?

Well, I don't have this scanner at my hands, but it seems, that the
problem is caused by the continuation URB, which is not properly
cancelled, and by concatenation of read data with surplus data from the
continuation URB.

> > It was tested with the latest libusb-1.0.6. Older version even did not
> > start to scan.
>
> And it doesn't work with libusb-1.0.6 and the new kernel?
> In that case, I don't understand the problem.

With libusb-0.1.12, it scans in both low and high resolution.

With libusb-1.0.3, it does not work at all.

With libusb-1.0.6 and linux-2.6.31.5, it scans in low resolution. In
high resolution it scans several lines and hangs.

With libusb-1.0.6 and linux-2.6.32rc6, it scans in low resolution. In
high resolution it scans several lines and hangs and complies to syslog:
"usbfs: usb_submit_urb returned -121"

According to the documentation, it is caused by URB_SHORT_NOT_OK.

> Under this new configuration, given an example of 3 16kb bulk URBs
> submitted in parallel, if the first one ends early then the other 2 will
> be immediately cancelled with no possibility for data to arrive in them,
> as if they had never been submitted. This gives both the performance
> advantage plus the logical transfer separation that was implemented by
> libusb-0.1.

In case of reported bug, the other URBs are not cancelled as they
should, but data are sent back. I don't know, which side is responsible
for this behavior (kernel? host controller? scanner?).

Here is my theory what is happening:

32000 bytes is requested. The request is split to 2 URBs by libusb and
sent to the kernel.

The scanner returns an amount of data, which is partially unpredictable,
but always less than requested 32000 bytes, and even less than 16384.

The scanner does not wait for completing the buffer, but it sends data
it actually has. It occurs in a single short transfer.

Until that moment, it is perfectly correct.

But in case of libusb1, scanner now starts to send data and fill the
continuation URB. In my opinion it is incorrect and the request should
have been cancelled after the short transfer occurrence.

> Actually, looking briefly at the bug report, I can't see any indication
> that a new enough kernel has been tested.

linux-2.6.32rc6 was the latest one.

--
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@...
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: libusb-compat x libusb0: new incompatibility (long request, short transfer, Brother scanner)

2009-12-14T08:25:30Z

El 14/12/09 15:52, Stanislav Brabec escribió:
> Splitting transfers into sub-transfers with SHORT_NOT_OK may be even
> dangerous in some situations:
> - USB specification recommends to ignore transfers not associated with
> any pending IRP.
> - When short transfer occurs and SHORT_NOT_OK is set, host controller
> closes the current IRP.
> - Software issues new URB, it issues new IRP on the bus.
> - There may be a race between them and data may be lost.

I am pretty sure this is not true (there is no race) because the kernel
is able to perform fine control of the queued packets with interrupts
disabled as soon as a short packet arrives.

Daniel

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: libusb-compat x libusb0: new incompatibility (long request, short transfer, Brother scanner)

2009-12-14T08:14:36Z

El 14/12/09 15:52, Stanislav Brabec escribió:
> I am not an USB expert, but as far as I read the specification, the
> MAX_*_BUFFER_LENGTH has nothing to do with the USB bus. The whole URB
> handling is a Linux specific thing.

Correct.

> Transfer size limits seems to be valid only for the deprecated usbfs,
> which is no more used by libusb. See linux/drivers/usb/core/devio.c.

usbfs is still used by libusb and is not deprecated.

>> It will hurt performance
>> significantly, but I guess that would be acceptable.
>
> Are you sure? Looking at the libusb-1.0.6, it never submits bulk URBs
> larger than 16kB (MAX_BULK_BUFFER_LENGTH) as well.

Yes. libusb-1.0 submits URBs in parallel, whereas libusb-0.1 did them in
serial. The parallelization goes all the way down to the hardware level,
where all the individual packet buffers are queued, resulting in a
significant performance increase.

The problem that this resulted in is that libusb couldn't avoid the
parallel-queued URBs from being filled up after an earlier one completed
early (there's no way it could cancel them in time, no matter how hard
it tried), and from briefly reading your bug report, this seems to be
what is happening?

> It was tested with the latest libusb-1.0.6. Older version even did not
> start to scan.

And it doesn't work with libusb-1.0.6 and the new kernel?
In that case, I don't understand the problem.

Under this new configuration, given an example of 3 16kb bulk URBs
submitted in parallel, if the first one ends early then the other 2 will
be immediately cancelled with no possibility for data to arrive in them,
as if they had never been submitted. This gives both the performance
advantage plus the logical transfer separation that was implemented by
libusb-0.1.

Actually, looking briefly at the bug report, I can't see any indication
that a new enough kernel has been tested.

Daniel

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: libusb-compat x libusb0: new incompatibility (long request, short transfer, Brother scanner)

2009-12-14T07:52:28Z

Daniel Drake wrote:
> El 11/12/09 16:20, Stanislav Brabec escribió:

> > If short transfer happens and length>= 16384 was requested:
> >
> > libusb0 returns the incomplete block read by the first URB, not trying
> > to ask for more data.
> >
> > libusb-compat asks for second URB and concatenates buffers into one
> > bigger block.

> I guess the approach you're looking at taking is forcing libusb-compat
> to never submit a transfer bigger than 16kb.

Yes. I have been thinking about two possible solutions:

1) Split transfers to 4096/16384/32768 bytes pieces inside
libusb-compat. It needs to review libusb-0.1 code for other
platforms and check for their limits.

2) Implement new libusb-1.0 calls to control buffer splitting and short
transfer behavior.

I am not an USB expert, but as far as I read the specification, the
MAX_*_BUFFER_LENGTH has nothing to do with the USB bus. The whole URB
handling is a Linux specific thing.

Transfer size limits seems to be valid only for the deprecated usbfs,
which is no more used by libusb. See linux/drivers/usb/core/devio.c.

I was not able to find any other limit for buffer_length anywhere in the
current kernel source nor documentation.

> It will hurt performance
> significantly, but I guess that would be acceptable.

Are you sure? Looking at the libusb-1.0.6, it never submits bulk URBs
larger than 16kB (MAX_BULK_BUFFER_LENGTH) as well.

> However, you should also consider that we've fixed this properly in more
> recent Linux kernels and the latest libusb release. So your patch should
> have some condition to stick to the current scheme on a system where the
> kernel is new enough, or something like that.

It was tested with the latest libusb-1.0.6. Older version even did not
start to scan.

Yes, new kernel changes libusb behavior. libusb sets
USBFS_URB_SHORT_NOT_OK (in fact it is URB_SHORT_NOT_OK) for all
split-transfer blocks except the last one.

It may break applications that implement reading from a device with a
short buffer, where the application wants to get concatenated short
blocks. (This is not the case of brscan, it wants each chunk.)

Splitting transfers into sub-transfers with SHORT_NOT_OK may be even
dangerous in some situations:
- USB specification recommends to ignore transfers not associated with
any pending IRP.
- When short transfer occurs and SHORT_NOT_OK is set, host controller
closes the current IRP.
- Software issues new URB, it issues new IRP on the bus.
- There may be a race between them and data may be lost.

--
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@...
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: Unable to claim an experimental HID device

2009-12-13T07:30:29Z

"Xiaofan Chen" <xiaofanc@...> said:

> You need to detach the Linux driver and then claim the interface.
> Please look at these functions.
> http://libusb.sourceforge.net/doc/ref.nonportable.html

Xiaofan, you are beautiful! Thank you, I am now able to send data to the
device, though of course it does not yet do what I expect it to do.
More hacking to come, and thank you for the other references.

I'll be back...

John Parsons
--

--
http://www.fastmail.fm - A no graphics, no pop-ups email service

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: Unable to claim an experimental HID device

2009-12-13T01:50:05Z

On Sun, Dec 13, 2009 at 2:19 PM, John Parsons <jfparsons@...> wrote:

> Microchip is windows-centric, I am not. I borrowed an XP machine to test
> the unmodified device firmware, and it works. To test modifications, I
> would have to get long term access to an XP box to exercise the device.

Microchip actually provides some Linux samples with libusb
(using QT3 as the GUI toolkit).

> I'd rather use Linux, and libusb looks like a great way to test the
> rather simple functions of the device. But I'm unsuccessful in
> establishing communication.
>
> usb_handle = usb_open(usb_dev); /* usb_handle is not NULL */
> usb_claim_interface(usb_handle, 0);
>

You need to detach the Linux driver and then claim the interface.
Please look at these functions.
http://libusb.sourceforge.net/doc/ref.nonportable.html

Microchip also publishes the source codes of pk2cmd (cross
platform for Windows, Linux and Mac OS X), you may get
some references from there as well.

Here are some references for USB PIC related open source
projects.
http://www.microchip.com/forums/tm.aspx?m=235427

--
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: Timeout vs data

2009-12-13T01:30:22Z

El 13/12/09 06:41, Dimax escribió:
> Hi,
> I remember there was some discussion and attempts to do something with
> a possible race between timeout in bulk_read and data arrival. I mean
> situation then timeout expires and just the same time data arrives
> from device. Can you tell me the current status and especially
> situation in libusb 0.1.

Nobody is really working or paying attention to 0.1 but I think there
was a mention that data can be lost on a timeout.

You could use usbmon to confirm a difference in the eyes of the kernel
from what your application gets from libusb.

It is fixed in the latest libusb-1.0 release with recent linux kernels.

Daniel

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Timeout vs data

2009-12-12T22:41:54Z

Hi,
I remember there was some discussion and attempts to do something with
a possible race between timeout in bulk_read and data arrival. I mean
situation then timeout expires and just the same time data arrives
from device. Can you tell me the current status and especially
situation in libusb 0.1.
We seams to have lost bulks in polling with 20ms timeout with
bulk_read. Can such race be a problem?

Thanks.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Unable to claim an experimental HID device

2009-12-12T22:19:09Z

Greetings,
I am a hardware-centric person developing a relatively simple HID
device. I'm using Microchip's low pin count USB development kit, and
their pre-compiled 'Simple HID Device Demo' application as a starting
point.

Microchip is windows-centric, I am not. I borrowed an XP machine to test
the unmodified device firmware, and it works. To test modifications, I
would have to get long term access to an XP box to exercise the device.

I'd rather use Linux, and libusb looks like a great way to test the
rather simple functions of the device. But I'm unsuccessful in
establishing communication.

System is Ubuntu 8.04, kernel 2.6.24-26-generic, libusb 0.12 installed
via apt-get install libusb-dev

Here's a summary of what I'm doing and where the problem occurs (I can
post the full code if that will help):
struct usb_device *usb_dev;
struct usb_dev_handle *usb_handle;
struct usb_device *dev;

usb_init();
usb_find_busses();
usb_find_devices();

/* find device by idVendor and idProduct, this works */

usb_handle = usb_open(usb_dev); /* usb_handle is not NULL */
usb_claim_interface(usb_handle, 0);

At this point usb_claim_interface returns -16.
I'm sure 0 is the correct interface number (device descriptor listed
below). If I substitute an interface number of 1 or 2,
usb_claim_interface returns -2.
What does -16 indicate, and what should I do to fix the problem?

The device descriptor, as listed in response to sudo lsusb -v
Bus 001 Device 002: ID 04d8:003f Microchip Technology, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x04d8 Microchip Technology, Inc.
idProduct 0x003f
bcdDevice 0.02
iManufacturer 1 Microchip Technology Inc.
iProduct 2 Simple HID Device Demo
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 41
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 29
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Device Status: 0x0001
Self Powered

Thank you for any suggestions,
peasey
--

--
http://www.fastmail.fm - A fast, anti-spam email service.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: libusb-compat x libusb0: new incompatibility (long request, short transfer, Brother scanner)

2009-12-12T12:38:08Z

El 11/12/09 16:20, Stanislav Brabec escribió:

> Hallo.
>
> I just found and finished analysis of the scanning failure of Brother
> scanners using brscan SANE drivers.
>
> It seems that libusb0 and libusb-compat behaves differently on short
> transfer happening for bulk transfers of requested size>= 16384.
>
> The scanning backend heavily depends on its exact behavior of libusb0
> and fails to scan properly with libusb-compat.
>
> If short transfer happens and length>= 16384 was requested:
>
> libusb0 returns the incomplete block read by the first URB, not trying
> to ask for more data.
>
> libusb-compat asks for second URB and concatenates buffers into one
> bigger block.

Thanks for investigating this.

I guess the approach you're looking at taking is forcing libusb-compat
to never submit a transfer bigger than 16kb. It will hurt performance
significantly, but I guess that would be acceptable.

However, you should also consider that we've fixed this properly in more
recent Linux kernels and the latest libusb release. So your patch should
have some condition to stick to the current scheme on a system where the
kernel is new enough, or something like that.

cheers
Daniel

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: how is < 2 ms RTT possible over USB?

2009-12-11T15:16:01Z

Hans Petter Selasky <hselasky@...> writes:
> That depends on the USB hardware driver, like EHCI/OHCI/UHCI.
>
> Typically the EHCI can interrupt every 125us. RTT should then be less than
> 1ms.

Openmoko does only USB1. The driver is ohci-s3c2410.c I think.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: [PATCH: winusb] hires timer fix

2009-12-11T10:40:47Z

Tim Roberts wrote:
>> Michael Plante wrote:
>> > I should warn, though, that when I ran Win2k on a hyperthreaded P4
(single core), it reported 2 processors (not sure about that API,
>> > but, rather, that's what it said when booting up with /SOS during the
low-res graphical bootup screen). I don't believe XP has this issue.
>>
>>
>> What issue? A single core hyperthreaded CPU has 2 processors. Two
>> threads can run simultaneously (well, "virtually" simultaneously). The
>> performance is a bit different from a dual core non-hyperthreaded CPU,
>> but the usage is identical.
>>
>> [...] What else would you have it do?

Sorry, I realized after I sent it that "issue" was too strong a word. It
might be something to be investigated, as far as whether you might get away
with treating it with the single-core case (i.e., whether you can get away
with not messing with thread affinity). I just don't know, and I should've
made that clearer.

>> Every Windows and Linux system I've ever encountered reports it as 2
>> processors.

I misremembered, and read too much into what I did remember. XP is at least
aware of HTT, while 2000 treats it no differently than 2 distinct
processors. Again, I overemphasized any certainty that it's important.

Michael

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: [PATCH: winusb] hires timer fix

2009-12-11T10:30:23Z

Michael Plante wrote:
> Do we have any idea of the magnitude of possible discrepancy from one processor to another? Is it enough to matter? Are we talking minutes or nanoseconds?
>

I have seen up to half a second. And, surprisingly, the delta can vary
over time, presumably because of fine-grained power management.

--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: how is < 2 ms RTT possible over USB?

2009-12-11T10:29:31Z

Timo Juhani Lindfors wrote:

> Hi,
>
> I connected "A-link gigabit usb 2.0 ethernet adapter"
>
> Bus 001 Device 005: ID 0b95:1780 ASIX Electronics Corp. AX88178}
>
> to my openmoko and measured RTT time with icmp ping:
>
> 64 bytes from 10.7.6.1: icmp_seq=298 ttl=64 time=2.38 ms
> 64 bytes from 10.7.6.1: icmp_seq=299 ttl=64 time=2.08 ms
> ...
> How can the RTT be less than 2 ms? Aren't USB frames transmitted only
> every 1 ms?
>

Full-speed (USB 1.x) frames are 1 ms. High-speed (USB 2) microframes
are 125us. A gigabit Ethernet controller is certainly going to be
high-speed. (In fact, gigabit Ethernet exceeds the achievable bandwidth
of a high-speed pipe by a factor of about 3 to 1.)

--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev

Re: [PATCH: winusb] hires timer fix

2009-12-11T10:27:55Z

Michael Plante wrote:
> I should warn, though, that when I ran Win2k on a hyperthreaded P4 (single core), it reported 2 processors (not sure about that API, but, rather, that's what it said when booting up with /SOS during the low-res graphical bootup screen). I don't believe XP has this issue.
>

What issue? A single core hyperthreaded CPU has 2 processors. Two
threads can run simultaneously (well, "virtually" simultaneously). The
performance is a bit different from a dual core non-hyperthreaded CPU,
but the usage is identical.

Every Windows and Linux system I've ever encountered reports it as 2
processors. What else would you have it do?

--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

From forum: LibUSB Dev