Bug 408131 - libusb wakes up 1000 times/sec while transfer outstanding
Summary: libusb wakes up 1000 times/sec while transfer outstanding
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: libusb
Version: 9
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: Fedora Extras Quality Assurance
URL: http://sourceforge.net/mailarchive/fo...
Whiteboard:
Depends On:
Blocks: wakeup
TreeView+ depends on / blocked
 
Reported: 2007-12-02 23:17 UTC by Scott Lamb
Modified: 2013-07-02 23:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-14 18:02:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
eliminate 1 ms wakeups (1.75 KB, patch)
2007-12-03 01:48 UTC, Scott Lamb
no flags Details | Diff

Description Scott Lamb 2007-12-02 23:17:28 UTC
Description of problem:

I saw igdaemon (not a Fedora package) waking up about 250 times per second and
investigated. It turns out that it was in usb_interrupt_read() while these
wakeups were taking place, and there were many wakeups per usb_interrupt_read()
call.

Digging further, usb_interrupt_read() calls usb_urb_transfer(), which has this code:

    while (!urb.usercontext && ((ret = ioctl(dev->fd, IOCTL_USB_REAPURBNDELAY,
&context)) == -1) && waiting) {
      tv.tv_sec = 0;
      tv.tv_usec = 1000; // 1 msec
      select(dev->fd + 1, NULL, &writefds, NULL, &tv); //sub second wait

      if (timeout) {
        /* compare with actual time, as the select timeout is not that precise */
        gettimeofday(&tv_now, NULL);

        if ((tv_now.tv_sec > tv_ref.tv_sec) ||
            ((tv_now.tv_sec == tv_ref.tv_sec) && (tv_now.tv_usec >=
tv_ref.tv_usec)))
          waiting = 0;
      }
    }

so it's trying IOCTL_USB_REAPURBNDELAY after every 1 ms or when dev->fd becomes
available for write. Not sure why the 1 ms timeout is necessary...

Note IOCTL_USB_REAPURBNDELAY is a libusb-internal #define. It's equivalent to
what linux/usbdevice_fs.h calls USBDEVFS_REAPURBNDELAY.

Version-Release number of selected component (if applicable):

present in latest rawhide (libusb-0.1.12-11)

How reproducible:

Long USB transfers. The IguanaWorks IR transceiver is ideal for reproducing this
problem because when the receiver is active it basically always leaves one
active for notification purposes. There are probably other such devices.

Steps to Reproduce (with IguanaWorks IR receiver):
1. install iguanaIR package
2. start igdaemon
3. start igclient --receiver-on --sleep 100
4. powertop -h

Actual results:

about 250 wakeups per second

Expected results:

about 6 wakeups per second, each indicating ~150 ms of idleness.

Additional info:

Comment 1 Scott Lamb 2007-12-03 01:47:47 UTC
I tried eliminating the 1 ms wakeups with libusb-no-wakeups.patch (to current
upstream CVS), and I didn't get struck down by lightning or anything. So far
everything seems to be working fine - in particular, it is getting awakened
immediately, not only every 1 second, which is the timeout igdaemon is passing.

So the question is: why do they do it this way now? Looks like the wakeups were
introduced in linux.c revision 1.43:

----------------------------
revision 1.43
date: 2003/05/17 00:55:07;  author: jerdfelt;  state: Exp;  lines: +28 -6
Switch from a blocking reap to a non blocking reap and poll. This avoids
using any signals.
Patch from Stephane Grundschober.
----------------------------

No discussion in the libusb-devel archives of that time.

http://sourceforge.net/mailarchive/forum.php?forum_name=libusb-devel&max_rows=25&style=nested&viewmonth=200305

Lacking any reason to believe otherwise, I'm going to say it was a mistake.

Comment 2 Scott Lamb 2007-12-03 01:48:55 UTC
Created attachment 275191 [details]
eliminate 1 ms wakeups

Comment 3 Jindrich Novy 2007-12-03 14:03:28 UTC
Could you please send the patch and comments to upstream first? Your proposal
makes sence IMO, but it's better to be discussed upstream. I'll happily apply it
as soon as upstream is happy with the patch.

Comment 4 Scott Lamb 2007-12-03 23:23:52 UTC
Sure thing. I started a thread on the libusb-devel list. The archives' threading
is broken, but you can see the posts from the month view:

http://sourceforge.net/mailarchive/forum.php?forum_name=libusb-devel&max_rows=25&style=ultimate&viewmonth=200712

It sounds like libusb is largely unmaintained, though, so I don't think an
official maintainer is likely to comment either way.

Comment 5 Jindrich Novy 2007-12-04 08:44:55 UTC
Applied. Thanks!

Daniel Drake's fpusb looks promising btw.

Comment 6 Jindrich Novy 2008-02-26 15:07:52 UTC
Wakeups patch is now temporary reverted from Fedora libusb, see bug #434950.

Comment 7 Bug Zapper 2008-05-14 04:04:27 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Bug Zapper 2009-06-09 23:15:02 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Bug Zapper 2009-07-14 18:02:00 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.