Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High CPU load with libusb-1.0.24 #141

Open
chtaube opened this issue Dec 17, 2020 · 36 comments
Open

High CPU load with libusb-1.0.24 #141

chtaube opened this issue Dec 17, 2020 · 36 comments
Labels
compatibility Compatibility with a certain system/device

Comments

@chtaube
Copy link

chtaube commented Dec 17, 2020

I have xow installed on two machines running Debian bullseye (testing) and it used to worked nicely without causing any trouble.

Now since a few days, I was wondering why two CPU cores were always pretty busy and found out that xow was at ~160% CPU load. I see this behaviour on both machines running Debian bullseye independently, so it is probably caused by a recent package update. Both machines are running kernel 5.9.0-4-amd64 #1 SMP Debian 5.9.11-1 (2020-11-27) x86_64 GNU/Linux.

xow-cpuload

The cpu load drops to virtually nothing as soon as I unplug the wireless dongle, but rises again to 160% after reinserting the dongle.

Any ideas on this?

@djibux
Copy link

djibux commented Dec 19, 2020

I have the same issue with kernel 5.9.0-4-amd64 on Debian testing.
For some reason there are also multiple processes.

xow high cpu

@imikkl
Copy link

imikkl commented Dec 19, 2020

I have the same issue here on gentoo and found that the problem is only present with libusb-1.0.24. going back to libusb-1.0.23 does not have this problem.

@chtaube chtaube changed the title Unusual high CPU load on Debian bullseye (testing) High CPU load with libusb-1.0.24 Dec 20, 2020
@Setadokalo
Copy link

Same issue on debian bullseye, also with libusb-1.0.24; I'm trying to roll back to a different libusb version to test if that solves the cpu load for me too, but it's proving to be a bit tricky.

@kapsh
Copy link

kapsh commented Jan 6, 2021

Confirmed with libusb 1.0.24. Nothing suspicious in debug logs (no difference between running with 1.0.23).

@brain-anti-freeze
Copy link

I'm seeing the same on Arch. High CPU with libusb-1.0.24, downgrading to libusb-1.0.23 resolves it.

@coxde
Copy link

coxde commented Jan 14, 2021

Same with libusb 1.0.24 on Arch. And downgrade to 1.0.23 resovle it.

@evan203
Copy link

evan203 commented Jan 14, 2021

Also had this issue with arch after updating my system today. Here's the command to downgrade libusb:

sudo pacman -U /var/cache/pacman/pkg/libusb-1.0.23-3-x86_64.pkg.tar.zst

also edit /etc/pacman.conf to have IgnorePkg = libusb

@XirXes
Copy link

XirXes commented Jan 14, 2021

Confirming the issue on Arch with 5.10.7-xanmod1-1. Downgrading libusb also fixed it for me, but I didn't have the old version in my cache. Installing directly from archive.archlinux.org worked perfectly for me however, just restart the xow service or replug the adapter after you're downgraded.

Here's the command if your cache doesn't have the old version.

sudo pacman -U https://archive.archlinux.org/packages/l/libusb/libusb-1.0.23-3-x86_64.pkg.tar.zst

@John-Gee
Copy link

You should just use downgrade to downgrade packages, it's much easier when you do not have it in cache.

As for the rest, I am not convinced the dev needs people confirming this again and again, the first couple times were probably enough.

@medusalix
Copy link
Owner

So we've got two options:

  1. Attach a profiler to xow and identify the code path that's wasting all the CPU cycles.
  2. Go through the ~200 commits to libusb since v1.0.23 and identify the one that's causing this issue.

Just to give you an idea if someone wants to go ahead and track this down.

@John-Gee
Copy link

Apologies for the previous stupid reply, since I don't use my dongle, I didn't notice the software did not use CPU because it died with that line...

I believe this is it: libusb/libusb@d67eb5b

Alas this is a big change, not so easy where the issue is from. If you want this commit to not crash you need to remove the assert as in: libusb/libusb@4b64ecc

I hope that's better.

@nullobsi
Copy link
Contributor

i have this same issue, and it appears to be libusb_bulk_transfer taking up most of the time

@aaronserver2
Copy link

Seeing this on opensuse TW as well, haven't yet found a way to downgrade libusb to 1.0.23 like others here have suggested

@medusalix
Copy link
Owner

medusalix commented Jan 23, 2021

Ok, so after literally hours of debugging I think I've found the culprit:

xow reads USB packets from the dongle using libusb_bulk_transfer. This function submits a USB transfer and calls usbi_wait_for_events to wait for the transfer to complete. When a certain timeout is reached (1 second in xow's case), usbi_wait_for_events will return. This worked fine in libusb v1.0.23.
This behavior changed in libusb v1.0.24. usbi_wait_for_events doesn't respect the timeout anymore and instead returns immediately even if no event is available. This causes a high CPU usage.

EDIT: See libusb/libusb#858. I should've checked the issue tracker...

@ghost
Copy link

ghost commented Jan 28, 2021

I was having a strange high cpu load and high cpu temperatures.... i took almost a week to find out that it was xow (actually libusb) that was causing the issue. I'm subscribing to the issue.

@poligarpi
Copy link

Confirming the issue on Arch with 5.10.7-xanmod1-1. Downgrading libusb also fixed it for me, but I didn't have the old version in my cache. Installing directly from archive.archlinux.org worked perfectly for me however, just restart the xow service or replug the adapter after you're downgraded.

Here's the command if your cache doesn't have the old version.

sudo pacman -U https://archive.archlinux.org/packages/l/libusb/libusb-1.0.23-3-x86_64.pkg.tar.zst

Thank you very much for the command, I can confirm the same issue on Manjaro with libusb-1.0.24

@zyll71
Copy link

zyll71 commented Feb 20, 2021

I have the same on OpenSuSE Tubmbleweed with libusb 1.0.24-2.1. Unfortunatly I can't seem to find a 1.0.23 version. I have gone over to enabling/disabling xow on a need-to-play basis as a temp workaround.

Update 2021-03-29: Managed to find a 1.0.23 version and downgrade. Runs smoothly now.

@pseudex
Copy link

pseudex commented May 1, 2021

Workaround for Fedora 34

With fedora 34 libusbx is also updated to 1.0.24. Since this is the lowest release in f34 there is no easy downgrade just via dnf

first you need to download the RPM files

I got mine here and downloaded these RPMs for my system (x64)
https://koji.fedoraproject.org/koji/buildinfo?buildID=1682463
ibusbx-1.0.23-3.fc34.x86_64.rpm (info) (download)
libusbx-devel-1.0.23-3.fc34.x86_64.rpm (info) (download)

run the downgrade of the installed versions
sudo dnf downgrade libusbx-1.0.23-3.fc34.x86_64.rpm libusbx-devel-1.0.23-3.fc34.x86_64.rpm --allowerasing

to lock the version, so it will not be upgraded by dnf upgrade, I versionlocked them with the dnf-versionlock plugin
This will exclude only version .24. Since it sounds like the bug will be fixed in version .25, dnf will first upgrade once this version is available

sudo dnf install python3-dnf-plugin-versionlock
sudo dnf versionlock exclude libusbx-0:1.0.24*
sudo dnf versionlock exclude libusbx-devel-0:1.0.24*

@ghost
Copy link

ghost commented May 20, 2021

Exact same issue here with xow and latest libusb master libusb/libusb#913

@mcuee
Copy link

mcuee commented May 21, 2021

libusb/libusb#856

libusb #856 should fix this issue as it fixes libusb/libusb#858. The pull request has been reviewed, just pending the merge for 1.0.25 release.

@ghost
Copy link

ghost commented May 21, 2021

libusb/libusb#856

libusb #856 should fix this issue as it fixes libusb/libusb#858. The pull request has been reviewed, just pending the merge for 1.0.25 release.

I can confirm, the pending PR fixes the issue for me 👍

@NoXPhasma
Copy link
Contributor

libusb gets only one release a year and they have no rush. This will take many more months until it gets released.

@ghost
Copy link

ghost commented May 21, 2021

libusb gets only one release a year and they have no rush. This will take many more months until it gets released.

I'm not quiet sure, on their roadmap it is planned for end of June, this means in a bit more than one month:
https://github.com/libusb/libusb/milestone/9

@NoXPhasma
Copy link
Contributor

Oh, I didn't knew about that. Was only looking for the past releases and those were mostly annual.

@mcuee
Copy link

mcuee commented May 21, 2021

We do not have enough developers in libusb so the release is taking a bit of time. The date indicated in the milestone is more like an estimate so no guarantee. Hopefully we will get libusb 1.0.25 released soon.

@trustin
Copy link

trustin commented Jul 3, 2021

I replaced libusb with libusb-git in AUR (Arch) and confirmed it fixes the problem.

@raksanyiv
Copy link

Hi,

I did not really want to downgrade libusbx system wide, so used LD_LIBRARY_PATH/LD_PRELOAD

  • download libusbx 1.0.23 as pseudex told you to an empty suitable dir
  • extract the files in suitable dir like 'rpm2cpio libusb_some_version_downloaded.rpm | cpio -idmv'
  • start xow with
    • LD_LIBRARY_PATH=/path/to/libusbx/usr/lib64/ /usr/local/bin/xow
    • LD_PRELOAD=/path/to/libusbx/usr/lib64/libusb_some_version_file.so /usr/local/bin/xow

edward-p added a commit to archlinuxcn/repo that referenced this issue Jul 6, 2021
@safijari
Copy link

Had the same issue. Installing libusb from source fixed it.

@NateTheGreat68
Copy link

NateTheGreat68 commented Sep 10, 2021

This might help someone else on Debian (Bullseye for me, but should apply to others). I built and installed the latest libusb straight from github, but xow wouldn't use it - it kept using the buggy version (installed in /usr/lib/x86_64-linux-gnu) instead of the one I'd just built and installed (/usr/local/lib), despite pkg-config picking up the new one.

Rather than doing something messy like copying/moving the files from /usr/local/lib to /usr/lib/x86_64-linux-gnu or changing some symlinks, I built xow with:
$ make BUILD=RELEASE LDFLAGS='-Wl,-rpath,/usr/local/lib'
and that worked perfectly. It can be verified with $ ldd ./xow.

@zerkerX
Copy link

zerkerX commented Sep 20, 2021

If anyone wants a slightly more elegant (though longer) Debian solution, here's what I did to cleanly package the lastest git as a Debian package, and installed it as an upgrade.

First, clone the git repo as usual:

$ git clone https://github.com/libusb/libusb.git

Then install the build scripts, build dependencies for libusb and fetch the source package:

$ sudo apt build-dep libusb-1.0
$ sudo apt install devscripts
$ apt source libusb-1.0

Next, copy the debian folder from the apt source folder (libusb-1.0-1.0.24) into the upstream git folder (libusb). Change into libusb, then add a new entry to the change log:

$ cd libusb
$ dch -n

By default it will add a .1 to the latest version (at the time of writing is 2:1.0.24-3... so 2:1.0.24-3.1. I opted to change -3 to -7, so it will skip the next couple security updates to 0.24, but should be replaced automatically by the real 1.0.25 when that comes out. The top of my file ended up as:

libusb-1.0 (2:1.0.24-7) UNRELEASED; urgency=medium

  * Non-maintainer upload.
  *
  
 -- Ryan Armstrong <etc.> etc.

Save and close the file.

At this point, you can build the package:

$ debuild -b -uc -us

If you only have one architecture, you are done here and can go ahead and install the generated .deb files in the parent folder (exact list may vary depending on what you already have installed):

$ cd ..
$ sudo apt install ./libusb-1.0-0_1.0.24-7_amd64.deb ./libusb-1.0-0-dev_1.0.24-7_amd64.deb ./libusb-1.0-doc_1.0.24-7_all.deb

However, if you have the i386 version of the package installed too (which is common if you use wine), you need to build both and install them at the same time. That requires a bit more effort, because you'll need the i386 dependencies too.

What worked for me was to use dpkg-checkbuilddeps as follows (changing back into libusb if you aren't already)

$ cd libusb
$ dpkg-checkbuilddeps -a i386 debian/control

It will print out missing i386 dependencies, which you can then install:

$ sudo apt install libudev-dev:i386

It's not perfect though. I was also missing objcopy, so I also installed it as follows:

$ sudo apt install binutils-i686-linux-gnu

Then you can build the i386 package:

$ debuild -b -uc -us -ai386

If all goes well, you should have all the packages you need. If you find yourself missing a tool or package, install it (possibly using apt-file find if you aren't sure what package) and try again.

Then, you can install both the amd64 and i386 packages at the same time:

$ cd ..
$ sudo apt install ./libusb-1.0-0_1.0.24-7_amd64.deb ./libusb-1.0-0_1.0.24-7_i386.deb ./libusb-1.0-0-dev_1.0.24-7_amd64.deb ./libusb-1.0-doc_1.0.24-7_all.deb

@teem234
Copy link

teem234 commented Dec 28, 2021

high cpu usage still occurs with libusb1.0.24-2

@TehCorwiz
Copy link

TehCorwiz commented Dec 31, 2021

@unholyN1 The fix for the high cpu issue is planned to be included in libusb 1.0.25 which is still undergoing their pre-release review process: libusb/libusb#777

@djibux
Copy link

djibux commented Jan 29, 2022

1.0.25~rc1-1 is available in Debian experimental and it does solve the issue.

sudo apt install -t experimental libusb-1.0-0

@mcuee
Copy link

mcuee commented Feb 1, 2022

FYI libusb-1.0.25 has just been released today. Hopefully various Linux distro will be able to catch up soon.
https://github.com/libusb/libusb/releases/tag/v1.0.25

@McCarthee
Copy link

FYI libusb-1.0.25 has just been released today. Hopefully various Linux distro will be able to catch up soon. https://github.com/libusb/libusb/releases/tag/v1.0.25

Just got 1.0.25 on Arch and it seems to have fixed the issue.

ttrei added a commit to ttrei/dotfiles that referenced this issue Dec 8, 2022
ttrei added a commit to ttrei/dotfiles that referenced this issue Dec 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility Compatibility with a certain system/device
Projects
None yet
Development

No branches or pull requests