"failed to add service - already in use?" error

[Toad King]

After the latest firmware update, any time I try to run a program with GLES/OpenVG, I get an error like this:

Code: Select all

3422136784: * failed to add service - already in use?

where the number changes each time. Does anyone know what could be causing this?

[dom]

What memory split are you using?

[pwinwood]

It happens to me too using 128/128 and 192/64.

uname -a

Linux raspberrypi 3.1.9+ #202 PREMPT Wed Jul 25 22:11:06 BST 2012 armv6l GNU/Linux.

I will try reflashing the sdcard.

[pwinwood]

I reflashed the sdcard, installed and ran the rpi-update and the same error occurred again running hello_triangle.

[Aloshi]

Same thing here, also started happening after I updated the firmware yesterday.

[Oraclemaster]

I have the same problem with Quake 3 and some people get this error running XBMC.

Mauro

[fordexplorer]

I can confirm Mauro's statement regarding XBMC.

Ford

[dom]

@all
Have you tried updating today? I think I fixed this late last night.

[Oraclemaster]

Hi dom, after a

sudo apt-get update
sudo apt-get dist-upgrade
sudo rpi-update 192

Reboot

It works.

Thank you.

Mauro

[jlauha]

I started getting this error when I just switched to the new "2012-09-18-wheezy-raspbian" image. I get it e.g. when I compile and try to run the hello_triangle example.

[dom]

I started getting this error when I just switched to the new "2012-09-18-wheezy-raspbian" image. I get it e.g. when I compile and try to run the hello_triangle example.

What memory split are you using?

[jlauha]

I had it on 240/16 as the previous image worked with that. Also I had tried the rpi-update 192 command instructed in a message above, thinking I had tried it with that as well with no luck. I guess I somehow missed an error message since there is no rpi-update command.

Now that I checked & tried again, it works again with the 192 memory split. 224 doesn't work either, although it gives a different, app dependent error message (context creation fails).

[thogue]

Xbian 0.6.3

xbmc would error.

Tried 192, xbmc started but still would not finish loading. Set to 128 seems to be working now.

[jdonald]

I know this thread is more than five years old, but doesn't this problem exist today on Raspbian Jessie and Stretch? There's a Stack Overflow question about exactly this error, and someone pinpointed the vc4-kms-v3d overlay as a partial cause. To answer the earlier troubleshooting question, raising GPU memory to 256 MB on a Pi 3 doesn't help.

Removing dtoverlay=vc4-kms-v3d does make the error go away, but also disables the full OpenGL driver with KMS. This isn't really an acceptable solution.

Given that minecraft-pi still runs regardless of whether the overlay is enabled, it should be possible to make other VideoCore-accelerated programs work consistently as well.

/opt/vc/src/hello_pi/hello_triangle/ and similar examples would ideally be a starting point for integrating VideoCore acceleration into other engines. Does anyone know what source lines to change to make them work regardless?

I know there's the alternative of the Mesa driver with some open-source VC4 acceleration, but it's not as fast yet and packages like Quake 3 still use the VC libs.

[jdonald]

Closing the loop here.

• When this thread was discussed five years ago the problems were not due to the newer VC4 overlay--because it didn't exist at the time. Users were encountering a combination of bad memory splits and perhaps a now-resolved Raspbian regression. Whereas if someone comes across "failed to add service" today, it's more likely a case of running these older programs with the vc4-kms-v3d overlay enabled.
• Minecraft Pi Edition works today with Mesa EGL via a wrapper. Raspbian has a script at /usr/bin/minecraft-pi which detects the runtime configuration and if necessary makes use of a modified version of this library: https://github.com/xobs/mcrpi-wrapper
• Raspbian Quake3 could run with a slightly modified version of that wrapper that implements eglSaneChooseconfigBRCM(). However, given that this program is open-source and built on SDL it's probably more straightforward to remove the dispmanx parts of that codebase altogether. See this thread.
• The hello_pi examples are not using SDL so would involve more code to set up a window. On Pi Stack Exchange I've posted one approach to run them on Mesa with minimal changes. In theory one could further extend the wrapper to take care of window creation and run an unmodified hello_triangle.bin executable.

[Azimoth]

Adding to this list:

• Kodi (version 2:17.6-2~stretch) gave me this error today and returning to the "Original non-GL desktop driver" (in contrast to the "OpenGL desktop driver with full/fake KMS") made the error go away

[MikeCoder]

Hello there. This thread is very old, but I just tried to run https://github.com/MCPI-Devs/MCPIL. I got the "Failed to add service error." I'm currently using OpenGL Fake KMS driver with a 128mb memory split, but it still doesn't work. Any suggestions?

[jdonald]

Hi MikeCoder. My Pi devices are stashed away so I haven't had a chance to try MCPIL, but I suspect it's vulnerable to the same missing wrapper problems that users often had encountered when setting up the old Survival Mode patch.

The helper script at /usr/bin/minecraft-pi looks something like this:

Code: Select all

#!/bin/sh

cd /opt/minecraft-pi || exit

if grep -q okay /proc/device-tree/soc/vec@7e806000/status; then
	export LD_PRELOAD=libbcm_host.so.1.0
	export LD_LIBRARY_PATH=lib/mesa
else
	export LD_LIBRARY_PATH=lib/brcm
fi

./minecraft-pi

and that particular /opt/minecraft-pi/lib/mesa/libbcm_host.so.1.0 binary is actually a build of https://github.com/XECDesign/mcrpi-wrapper which is the same way I cited it's possible to run hello_triangle.bin with the full OpenGL driver.

If you are hitting "failed to add service" it means either MCPIL is missing such a wrapper script or you're unintentionally bypassing it somehow. If you need to make the script yourself, see Gubba Monster's instructions on the Survival Mode patch for how he created it using /usr/bin/minecraft-pi as a template.

If there is such a script already running but it's somehow choosing the legacy driver (LD_LIBRARY_PATH=lib/brcm) path, that means grep -q okay /proc/device-tree/soc/vec@7e806000/status isn't returning what's expected for OpenGL + Fake KMS. You could modify your script to say if true; then on that line, but you may also need to investigate whether your driver is actually working properly with hardware acceleration by installing mesa-utils and running glxinfo.

[6by9]

If there is such a script already running but it's somehow choosing the legacy driver (LD_LIBRARY_PATH=lib/brcm) path, that means grep -q okay /proc/device-tree/soc/vec@7e806000/status isn't returning what's expected for OpenGL + Fake KMS. You could modify your script to say if true; then on that line, but you may also need to investigate whether your driver is actually working properly with hardware acceleration by installing mesa-utils and running glxinfo.

vec@7e806000 is the composite video output device. That's not enabled except with FULL KMS on Pi0-3.
/proc/device-tree/v3dbus/v3d@7ec04000/status is the node you're after on a Pi4, or /proc/device-tree/soc/v3d@7ec00000/status on a Pi 0-3. Those denote that the ARM is responsible for the 3D hardware.

Note the is_fkms function in raspi-config (which actually detects either KMS driver) https://github.com/RPi-Distro/raspi-con ... config#L77

[Alvarito050506]

Hello there!

Hello there. This thread is very old, but I just tried to run https://github.com/MCPI-Devs/MCPIL. I got the "Failed to add service error." I'm currently using OpenGL Fake KMS driver with a 128mb memory split, but it still doesn't work. Any suggestions?

About this, it was solved switching the GL Driver. Anyways if you're using some MCPIL versions, you'll probably find another error, related to a "missing" GLESv2. To be honest, I don't know what's failing, or how to fix it, since all the required libraries are installed on the system, and MCPIL does the wrapping internally. But I'm trying to fix it and make a new release.

[zhoneybee]

Hi there,

I've received the same error for my plex media player installation. I followed the instructions here: https://pimylifeup.com/raspberry-pi-plex-media-player/

I'm on an RPI4B, and I've already set dtoverlay=vc4-kms-v3d, raising GPU memory to 512GB, and using the legacy GL driver. Does anyone have any insight as to what I might be missing?

[mattc]

Had the same exact issue than @zhoneybee: I tried to launch my own dispmanx legacy GL app on the Pi4B without loading the vc4-fkms-v3d and I get this "failed to add service - already in use?". Then I took the same SD card and put it on my Rpi3B+ then everything works just fine... Is the Legacy GL is broken on the Pi4B on the latest Raspberry Pi OS release? I built my SD card using the 2020-12-12 release.

EDIT: I tried compiling and running all the hello_pi samples in /opt/vc/src, and it looks like they're all been sabotaged like this

Code: Select all

   if (get_processor_id() == PROCESSOR_BCM2838)
   {
      puts("This demo application is not available on the Pi4\n\n");
      exit(0);
   }

I tried commenting out this chunk of code in one of the sample, and guess what? it gave me the same error ""failed to add service - already in use?"

So something is definitely using dispmanx when a pi4 is being used, but I am not sure what it is. I guess this is a sign to start letting it go and upgrade our code to DRM/KMS.

[6by9]

There is no legacy / firmware GL driver on the Pi4. The V3D block has been upgraded (from VideoCore 4 to VideoCore 6) and the firmware has no driver for it.
Legacy mode gives you a DispmanX based framebuffer (instead of DRM/KMS) but no GL/GLES at all on Pi4, and that isn't going to change.

[jdonald]

I tried to launch my own dispmanx legacy GL app on the Pi4B

...

Code: Select all

   if (get_processor_id() == PROCESSOR_BCM2838)
   {
      puts("This demo application is not available on the Pi4\n\n");
      exit(0);
   }

If your application is not too complicated, could you run it on the Pi 4B with a shim to avoid dispmanx? See my answer here: https://raspberrypi.stackexchange.com/a/75688 for an example of modifying the hello_triangle example to run via mcrpi-wrapper.

The above get_processor_id() check sounds new, so of course for hello_triangle and other examples you'd have to comment it out.

[zhoneybee]

There is no legacy / firmware GL driver on the Pi4. The V3D block has been upgraded (from VideoCore 4 to VideoCore 6) and the firmware has no driver for it.
Legacy mode gives you a DispmanX based framebuffer (instead of DRM/KMS) but no GL/GLES at all on Pi4, and that isn't going to change.

Forgive my naivete, I'm just an end user trying to compile an application. Is this something I could install to get working? I'm not sure that I understand what changed between the 3B+ and the 4B that affects us here.