Bug 408131 - libusb wakes up 1000 times/sec while transfer outstanding
libusb wakes up 1000 times/sec while transfer outstanding
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: libusb (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Jindrich Novy
Fedora Extras Quality Assurance
http://sourceforge.net/mailarchive/fo...
: Reopened
Depends On:
Blocks: wakeup
  Show dependency treegraph
 
Reported: 2007-12-02 18:17 EST by Scott Lamb
Modified: 2013-07-02 19:25 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 14:02:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Scott Lamb 2007-12-02 18:17:28 EST
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-02 20:47:47 EST
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-02 20:48:55 EST
Created attachment 275191 [details]
eliminate 1 ms wakeups
Comment 3 Jindrich Novy 2007-12-03 09:03:28 EST
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 18:23:52 EST
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 03:44:55 EST
Applied. Thanks!

Daniel Drake's fpusb looks promising btw.
Comment 6 Jindrich Novy 2008-02-26 10:07:52 EST
Wakeups patch is now temporary reverted from Fedora libusb, see bug #434950.
Comment 7 Bug Zapper 2008-05-14 00:04:27 EDT
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 19:15:02 EDT
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 14:02:00 EDT
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.