Errors launching chromium-imx8 on Torizon OS 7

Technical Support
, , , ,
1

I’ve just tried Torizon OS 7 7.1.0-devel-20241101+build.88 with torizon/weston-imx8:stable:rc and torizon/chromium-imx8:stable:rc.
When chromium starts it prints the following errors on the command line console

kiosk-1   | [8:33:1104/090517.736571:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [8:33:1104/090517.736943:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [8:33:1104/090517.737070:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [8:33:1104/090517.737152:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [8:33:1104/090517.737207:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [8:33:1104/090517.829571:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [8:33:1104/090517.830348:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [8:90:1104/090518.057966:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
kiosk-1   | [8:90:1104/090518.061169:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
kiosk-1   | [8:90:1104/090518.065772:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
kiosk-1   | [8:29:1104/090518.336566:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [8:29:1104/090518.336669:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [8:8:1104/090518.644842:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type:
kiosk-1   | [8:8:1104/090518.644927:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type:
kiosk-1   | [8:29:1104/090518.645174:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [8:8:1104/090518.665487:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type:
kiosk-1   | [8:30:1104/090518.670375:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [8:8:1104/090518.676642:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type:
kiosk-1   | [8:30:1104/090518.678403:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [8:8:1104/090518.680734:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type:
kiosk-1   | [8:30:1104/090518.681061:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk-1   | [56:116:1104/090518.678634:ERROR:v4l2_utils.cc(578)] Could not open /dev/video-dec0: No such file or directory (2)
kiosk-1   | [56:116:1104/090518.682459:ERROR:v4l2_utils.cc(578)] Could not open /dev/video-dec0: No such file or directory (2)
kiosk-1   | [8:8:1104/090518.685599:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type:
kiosk-1   | [8:30:1104/090519.439983:ERROR:cert_issuer_source_aia.cc(35)] Error parsing cert retrieved from AIA (as DER):
kiosk-1   | ERROR: Couldn't read tbsCertificate as SEQUENCE
kiosk-1   | ERROR: Failed parsing Certificate
kiosk-1   |
kiosk-1   | [57:86:1104/090519.532185:ERROR:ssl_client_socket_impl.cc(878)] handshake failed; returned -1, SSL error code 1, net_error -202

I can see that chromium is shown on the screen and seems working (more or less).
Are the above errors a known behavior?

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Yes, the errors you are encountering when launching Chromium on Torizon OS 7 are known behaviors. These errors are primarily related to D-Bus connectivity and SSL issues, as detailed in the context provided. The errors such as “Failed to connect to the bus” and “Failed to call method” indicate potential misconfigurations or missing D-Bus services, which are essential for inter-process communication. Additionally, the SSL handshake errors suggest problems with SSL certificate handling, which could affect secure connections.

To address these issues, it is advisable to:

  1. Investigate the D-Bus configuration to ensure that the necessary services are running and properly configured.
  2. Check for proper device access, especially for video devices if applicable.
  3. Ensure that SSL certificates are correctly handled and configured.

These steps should help improve the performance and reliability of Chromium on Torizon OS 7.

Please, also check if these links can help you solve your problem:

GPU performance in Chromium container on Torizon OS iMX8M-Plus.

5

Hi @vix !

Thanks for bringing this up.

I am not sure about the specific issue you are facing, but the chromium container in general is currently not yet stable/available for i.MX8, i.MX7 and i.MX6, as we can see from Release 4.0.0 · torizon/torizon-containers · GitHub. So it is safe to say that your are facing a known issue.

Best regards,

6

Hi @vix !

Do you have any updates regarding this topic?

Best regards,

7

Hi @henrique.tx

the same issue even on the new 4.1.1 containers.
To be honest, I’ve been waiting for a feedback from Toradex side (when the 4.x containers are stable).

8

Hello @vix,

The work on the 4.x containers is ongoing.

The Weston container is ready and can leverage the GPU for the Verdin iMX8MP.
I am also closely following the progress on the Chromium container, so when it is ready I will send an update here.

Best Regards,
Bruno

9

Hello @vix,

We now have a pre-release Chromium container for the i.MX8 modules and Torizon OS 7 with HW acceleration enabled.

If you want to give it a try, you can do so by running Weston and Chromium with the following commands.

Weston:

docker run --rm -d -v /sys:/sys -v /run:/run --net=host --cap-add CAP_SYS_TTY_CONFIG \
           -v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/ \
           --device-cgroup-rule="c 4:* rmw" --device-cgroup-rule="c 13:* rmw" \
           --device-cgroup-rule="c 199:0 rmw" --device-cgroup-rule="c 10:223 rmw" \
           --device-cgroup-rule="c 226:* rmw" --device-cgroup-rule="c 253:* rmw" \
           torizon/weston-imx8:stable-rc --developer --tty=/dev/tty7

Chromium:

docker run --rm -d -v /tmp:/tmp -v /var/run/dbus:/var/run/dbus \
           -v /dev:/dev -v /dev/galcore:/dev/galcore \
           --device-cgroup-rule='c 81:* rmw' --device-cgroup-rule='c 199:* rmw' \
           --device-cgroup-rule='c 226:* rmw' --device-cgroup-rule='c 234:* rmw' \
           --device-cgroup-rule='c 235:* rmw' --device-cgroup-rule='c 253:* rmw' \
           --security-opt seccomp=unconfined --shm-size 512mb --entrypoint /usr/bin/bash \
           torizon/chromium-imx8:stable-rc chromium --allow-insecure-localhost \
           --disable-notifications --use-gl=egl --in-process-gpu \
           --check-for-update-interval=315360000 --disable-seccomp-filter-sandbox \
           --no-sandbox --enable-features=UseOzonePlatform --ozone-platform=wayland \
           --start-maximized --kiosk https://webglreport.com/

Please note that these are pre-release containers, so some features may not be complete.
If you decide to test this container and find issues, please report them here so we can look into them.

Best Regards,
Bruno

11

Hello @vix,

The new Chromium container for Torizon OS 7 has been officially released.
It can be run with the following commands:

Weston:

docker run --rm -d -v /sys:/sys -v /run:/run --net=host --cap-add CAP_SYS_TTY_CONFIG \
           -v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/ \
           --device-cgroup-rule="c 4:* rmw" --device-cgroup-rule="c 13:* rmw" \
           --device-cgroup-rule="c 199:0 rmw" --device-cgroup-rule="c 10:223 rmw" \
           --device-cgroup-rule="c 226:* rmw" --device-cgroup-rule="c 253:* rmw" \
           torizon/weston-imx8:4 --developer --tty=/dev/tty7

Chromium:

docker run --rm -d -v /tmp:/tmp -v /var/run/dbus:/var/run/dbus \
           -v /dev:/dev -v /dev/galcore:/dev/galcore \
           --device-cgroup-rule='c 81:* rmw' --device-cgroup-rule='c 199:* rmw' \
           --device-cgroup-rule='c 226:* rmw' --device-cgroup-rule='c 234:* rmw' \
           --device-cgroup-rule='c 235:* rmw' --device-cgroup-rule='c 253:* rmw' \
           --security-opt seccomp=unconfined --shm-size 512mb \
           torizon/chromium-imx8:4 --virtual-keyboard https://webglreport.com/

Best Regards,
Bruno

1 Like
12

Hi @bruno.tx

thank you very much for this update.
I’ll test it.

If possible I ask you two things:

  • can you detail a little bit the meaning of the several parameters of docker run? As an example is --developer necessary in production?
  • can you post there the docker-compose.yml? I know I can use composerize.com service, but I prefer a double confirmation :grinning:
13

Hello @vix,

Thanks for sharing composerize.com, I was not aware that there was such a tool.
The output of it will be mostly correct for the docker compose, but it will miss the dependency between the container. The Chromium container depends on the Weston container and this needs to be added.
As requested, here is the docker-compose file:

docker-compose.yml 
services:
  weston:
    volumes:
      - /sys:/sys
      - /run:/run
      - /dev:/dev
      - /tmp:/tmp
      - /run/udev/:/run/udev/
    network_mode: host
    cap_add:
      - CAP_SYS_TTY_CONFIG
    device_cgroup_rules:
      - c 4:* rmw
      - c 13:* rmw
      - c 199:0 rmw
      - c 10:223 rmw
      - c 226:* rmw
      - c 253:* rmw
    image: torizon/weston-imx8:4
    command: --tty=/dev/tty7
  chromium:
    volumes:
      - /tmp:/tmp
      - /var/run/dbus:/var/run/dbus
      - /dev:/dev
      - /dev/galcore:/dev/galcore
    device_cgroup_rules:
      - c 81:* rmw
      - c 199:* rmw
      - c 226:* rmw
      - c 234:* rmw
      - c 235:* rmw
      - c 253:* rmw
    security_opt:
      - seccomp=unconfined
    shm_size: 512mb
    image: torizon/chromium-imx8:4
    command: --virtual-keyboard https://webglreport.com/
    depends_on:
      - weston

The parameters are mostly straight-forward.
The --developer argument is not needed for Weston.
The cgroup rules are intended to give access to specific devices, you can check which by running the following command:

ls -la /dev | grep <cgroup-number>,

For example, for the GPU:

ls -la /dev | grep 199,
crw-rw----  1 root    video   199,   0 Jan 31 10:00 galcore

If you have more questions, please feel free to reach out.

Best Regards,
Bruno

14

Hi @bruno.tx
I don’t know if I can say that the containers weston-imx8:4.4.0 and chromium-imx8:4.4.0 run without issues or not.
I try to explain:

The relevant messages in weston-imx8 log are

g2d_blitEx: Invalid src rect, left 0, top 0, right 0, bottom 0, width 0, height 0, stride 0!
[16:00:15.756] SRC: physicAddr = 0 left = 0 right = 0 top=0 bottom=0 stride= 0 tiling = 0, format=0
[16:00:15.756] DST: physicAddr = b1200000 left = 0 right = 1280 top=0 bottom=1024 stride= 1280 tiling = 1, format=4
...

The log for chromium-imx8 is full of error messages.

Is this an expected situation?
I think that Torizon OS 7 will give the final answer to the question “which is the real hardware limit/benchmark on the fishtank example”.
But we need to be sure that HW acceleration is applied without errors on fishtank example itself.

Thanks a lot for your investigation

15

Hello @vix,

Let me go through the points you raise one by one.

I believe that we are at a hardware limitation here.
The GPU on the iMX8MP is reasonably capable for the SoC it is in, but it is still very limited in area and power.

Let me give you an example from another application: Machine Learning.
The GPU on the iMX8MP can be used to run machine learning models, but it is much slower than the CPU on the iMX8MP for that purpose. You can view some numbers here.

This is expected, as with more fishes there are more meshes and as a consequence more calls done to the GPU.
These need to be made by the CPU and there is an overhead in doing so.

Looking at the logs, I don’t see any significant problems.
On the Weston logs you can see some invalid calls, but this should not lead to any problems.
On the Chromium logs, there are a few dbus errors which are unrelated to the hardware acceleration. There is also a failed attempt to create an EGL context, which means that the browser tried to create an EGL context with a specific configuration which was not valid. Afterwards, it will have created a valid context as a fallback.
Such behavior is normal and expected.

Best Regards,
Bruno