Insane CPU load on 24.04 and RPi5

[DoWenzl94]

Hi, I updated my server to 24.04 and migrated to a Raspberry Pi 5. I'm encountering a 100% CPU load issue caused by AirConnect:

4009 systemd+ 20 0 126204 1536 1280 S 333.8 0.0 1:28.14 airupnp-linux-a

I've attempted to reinstall it, but without success.

[pwt]

Could you just confirm you're using the containerised version of AirConnect described by this repo.?

(If, in fact, you're using the native application, ensure you're using the -Z option if running it daemonised.)

I'm not seeing any CPU issues on other versions of the rPi, and unfortunately I don't have a Pi 5 on which to test.

[DoWenzl94]

Hi, yes, I use this Docker version. I tried to reinstall and repull the image, but it doesn't work. I have a CPU idle of 100%, and I can't connect to it.

Here's the log:

[08:45:02.830] main:932 Starting aircast version: v1.4.0 (Nov 20 2023 @ 16:04:38)
[08:45:02.838] main:1378 Starting airupnp version: v1.4.0 (Nov 20 2023 @ 16:05:01)
[08:45:02.862] Start:1094 Binding to iface 192.168.1.31:0 [enxc84d44298bfc]
[08:45:02.863] Start:1133 Starting pico HTTP server on port 41261
[08:45:02.929] AddMRDevice:1003 [0xf3f77008]: creating MAC
[08:45:02.929] AddMRDevice:1020 [0xf3f77008]: adding renderer (Wohnzimmer Sonos) with mac BBBBA96814F3
[08:45:02.940] MasterHandler:647 [0xf3f77008]: subscribe success
[08:45:02.942] ProcessEvent:451 [0xf3f77008]: UPnP Volume local change 66:66 (master)
The futex facility returned an unexpected error code.The futex facility returned an unexpected error code.�R[08:45:27.435] main:932 Starting aircast version: v1.4.0 (Nov 20 2023 @ 16:04:38)
[08:45:27.443] main:1378 Starting airupnp version: v1.4.0 (Nov 20 2023 @ 16:05:01)
[08:45:27.463] Start:1094 Binding to iface 192.168.1.31:0 [enxc84d44298bfc]
[08:45:27.463] Start:1133 Starting pico HTTP server on port 44421
[08:45:27.798] AddMRDevice:1003 [0xf395f008]: creating MAC
[08:45:27.798] AddMRDevice:1020 [0xf395f008]: adding renderer (Wohnzimmer Sonos) with mac BBBBA96814F3
[08:45:27.808] MasterHandler:647 [0xf395f008]: subscribe success
[08:45:27.813] ProcessEvent:451 [0xf395f008]: UPnP Volume local change 66:66 (master)
The futex facility returned an unexpected error code.The futex facility returned an unexpected error code.�R[08:45:47.254] main:932 Starting aircast version: v1.4.0 (Nov 20 2023 @ 16:04:38)
[08:45:47.261] main:1378 Starting airupnp version: v1.4.0 (Nov 20 2023 @ 16:05:01)
[08:45:47.290] Start:1094 Binding to iface 192.168.1.31:0 [enxc84d44298bfc]
[08:45:47.296] Start:1133 Starting pico HTTP server on port 45593
[08:45:47.439] AddMRDevice:1003 [0xf3d36008]: creating MAC
[08:45:47.439] AddMRDevice:1020 [0xf3d36008]: adding renderer (Wohnzimmer Sonos) with mac BBBBA96814F3
[08:45:47.452] MasterHandler:647 [0xf3d36008]: subscribe success
[08:45:47.457] ProcessEvent:451 [0xf3d36008]: UPnP Volume local change 66:66 (master)

[pwt]

I've updated the container to use the latest version of AirConnect (v1.8.3). Please pull the image again and give it another try -- thanks.

If it still exhibits the issue, you'll need to test the native AirConnect binaries to see if the problem is still present. If so, this is an AirConnect bug, and we'll have to move it over to the AirConnect repo.

Note: I've never seen this error message, nor has it been reported:

The futex facility returned an unexpected error code.The futex facility returned an unexpected error code.

[DoWenzl94]

Thank you very much, unfortunately it doesn't make a difference. Okay, I will try the native AirConnect.

[pwt]

It looks like you only need support for Sonos, in which case you could try not starting aircast, since you only need airupnp:

docker run -d \
  --net=host \
  --name=airconnect \
  --restart=unless-stopped \
  -e SUPPRESS_FLUSH=TRUE \
  psychlist/docker-airconnect-arm

I doubt it'll make a difference, but it's cheap to try.

[DoWenzl94]

Thanks, but unfortunately also this doesn't make a difference.

[DoWenzl94]

Hi, now I tried running the airupnp-linux-aarch64-static outside of a Docker container and had no problems.

[pwt]

Thanks. That's a different binary compared to the one used inside the container, which is airupnp-linux-armv6-static. I use the v6 binary for compatibility with older devices.

If you have time, a quick check with the v6 binary would be appreciated. Ideally, try it both daemonised (-z) and non-daemonised.

[DoWenzl94]

Yes, that seems to be the problem, when I start the armv6 outside the container I have 100% utilization again, apparently the armv6 doesn't work with the new Pi5.

[DoWenzl94]

I saw also the airupnp-linux-aarch64-static has a load of 100% but only at one core, and at least it works, I will contact philippe44 for help.

Update: if I start airupnp-linux-aarch64-static whit -z option all is fine.

[pwt]

Great -- that's narrowed down the issue. Thanks for your help debugging.

I'll do some research as to why the Pi5 (at least with Ubuntu 24.04) won't happily run binaries for older ARM architectures.

It may also be time to figure out how to build architecture-specific container images.

I will contact philippe44 for help

To be fair to Philippe, given he does provide a binary that runs fine on the Pi5, I don't think this should be a high importance issue for him. I think this is really my issue to fix.