Chromium very slow to open in Lx 4.1-alpha znver1 system (Solved)

Tags: #<Tag:0x00007fe45ae9a368>

Post-edit: What I’m seeing is a big performance difference for chromium-browser-stable between x86_64 system and znver1 system:

x86_64: chromium-browser-stable opens almost instantly first time
znver1: chromium-browser-stable takes approx. 26 seconds to open first time

The Konsole output probably tells why:

$ chromium-browser-stable
[1777:1777:1208/174645.295555:ERROR:sandbox_linux.cc(369)] InitializeSandbox() called with multiple threads in process gpu-process.
[1754:1815:1208/174710.273294:ERROR:object_proxy.cc(619)] Failed to call method: org.freedesktop.Notifications.GetCapabilities: object_path= /org/freedesktop/Notifications: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[1777:1777:1208/174710.349489:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
[1754:1767:1208/174728.319432:ERROR:browser_process_sub_thread.cc(203)] Waited 13 ms for network service

chromium-browser-stable opens almost instantly in x86_64 hardware system. So this delay in opening seems to be specific to znver1 systems. May be helpful to include Konsole output from x86_64 system to compare to output above from znver1:

$ chromium-browser-stable
[5480:5480:1208/173459.317165:ERROR:sandbox_linux.cc(369)] InitializeSandbox() called with multiple threads in process gpu-process.
[5480:5480:1208/173459.333547:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
[5454:5465:1208/173503.758521:ERROR:browser_process_sub_thread.cc(203)] Waited 13 ms for network service

So I’m wondering if this is what is causing delay in znver1:

[13921:13983:1208/153147.742197:ERROR:object_proxy.cc(619)] Failed to call method: org.freedesktop.Notifications.GetCapabilities: object_path= /org/freedesktop/Notifications: org.freedeskto
p.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout exp
ired, or the network connection was broken.

And in view of that and the errors in this post I wonder if there is something missing or off regarding dbus for znver1 systems?

Post-edit: Would be awesomely helpful if we could get confirmation or not of this behavior to see if this is a real problem or specific to my computer for some reason.

@bero and @Colin report Chromium working normally on their znver1 systems so this seems to be specific to my computer or Ryzen5 cpu only. (But it it’s cpu then why does the problem not occur on x86_64 system on same computer? Weird. Some cpu flag?)

Further @Colin pointed me to this Arch Linux link.
This seems to correct the problem for me in znver1 VBox system but not in hardware znver1 system. Weird.

is that the RC release on VBox?

No VirtualBox 6.1 RC does not work with kernel-release 5.3.12 the latest kernel available in Lx 4.1/Rolling. It should work when we get kernel-release 5.4.x built for Lx 4.1/Rolling. It is working in Cooker with kernel 5.4.1.

In Lx 4.1/Rolling with kerne-release 5.3.12 you need to use VirtualBox 6.0.10 if you are using OpenMandriva’s packages.

Ok, will try it tonight on my end and check what is the progress and difference between on this kernel version i will test starting tonight.

This problem as far as I know is limited to me only. However I did a fresh install of znver1 and after ‘dnf --refresh upgrade’ the problem occurred again indicating to me that this is a real issue and an upgraded package might be the cause.

To reproduce issue on a computer with zen cpu (has to be zen cpu for znver1 to work properly):

  1. Install from this ISO: https://abf.openmandriva.org/platforms/rolling/products/82/product_build_lists/2928
  2. Chromium opens instantly as expected.
  3. Then run ‘dnf --refresh upgrade’ and in my case there was a 120 package upgrade all packages from rolling/main/release repo. Chromium now has the 25 second delay and the error message I posted regarding that. The upgraded packages list:

update_list-znver1-Dec-12.txt (23.5 KB)

I knew before filing the bug report this was likely to be a weird one. Partly because of “why things that work in x86_64 system on same computer then don’t work in znver1?”

So now it looks like this was somehow an internet issue not a problem with any package. Why do I think that?

Because a few hours ago I got knocked off the internet, the connection light on modem was blinking not solid like normal. And though computer was showing me connected my router showed me disconnected. So I rebooted cable modem then rebooted router and now this problem has disappeared. Things now appear working normally.

I’m speculating that the above fixed this otherwise I don’t have any explanation for things all of sudden working that haven’t worked for days.

1 Like