High CPU load with libusb-1.0.24

[chtaube]

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.

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]

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

[imikkl]

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.

[Setadokalo]

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]

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

[brain-anti-freeze]

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

[coxde]

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

[evan203]

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]

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]

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]

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]

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: https://github.com/libusb/libusb/commit/d67eb5beaa44c17c09f089a522ff483f4978a978

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: https://github.com/libusb/libusb/commit/4b64ecc6409ff3533b00153c65e02099c6ca55a9

I hope that's better.

[nullobsi]

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

[aaronserver2]

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]

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]

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]

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]

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]

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]

Exact same issue here with xow and latest libusb master https://github.com/libusb/libusb/issues/913

[mcuee]

https://github.com/libusb/libusb/pull/856

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

[ghost]

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 :+1:

[NoXPhasma]

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

[ghost]

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]

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

[mcuee]

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]

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

[raksanyiv]

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

[safijari]

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

[NateTheGreat68]

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]

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]

high cpu usage still occurs with libusb1.0.24-2

[TehCorwiz]

@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: https://github.com/libusb/libusb/issues/777

[djibux]

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]

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]

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.