1. Problem
I’m using Google Chrome as the default browser in my Gentoo/Linux laptop. Recently I noticed that the browser freezes all its rendering of web pages including even user interfaces. After tens of seconds it often recovers (but not always) and works normally as if there was no issue. The terminal logs say nothing before the freeze, but it always outputs “InitializeSandbox() called with multiple threads in process gpu-process.” after the recovering. It seems the issue occurs more often when the cases such as the CPU utilization is high, using the other applications in another workspace, and maybe using applications with HW-accelerations (not sure).
2. What I tried with no effect
The followings are what I tried during the freeze, but none of them works.
- restarting window manager
- changing to another workspace
- moving the frozen window to another workspace
- creating a new browser window
I also tried some general workarounds. However, the browser continued freezing.
- restarting the browser
- restarting the computer
- disabling all the extensions with –disable-extensions argument
- clear all the data in ~/.config/google-chrome and ~/.cache/google-chrome
- reinstalling the browser
3. Workaround and Solution
(A) Disable hardware accelerations (just as a temporal workaround)
Some web pages I found encouraged to disable hardware accelerations by launching the browser with –disable-gpu flag. It indeed worked for me, but I wanted to enable hardware-accelerations for video decode (e.g. YouTube).
(B) Use modesetting as Xorg video driver instead of xf86-video-intel (the solution)
According the Gentoo Wiki, the xf86-video-intel is deprecating these years and the major Linux distributions are migrating to the modesetting driver. So I deleted xf86-video-intel package and changed the Xorg driver from intel to modesetting. Google Chrome is now working perfectly stable in Xorg environment. The below is my /etc/X11/xorg.conf.d/20-intel.conf.
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
Option "AccelMethod" "glamor"
Option "DRI" "3"
BusID "PCI:0:2:0"
EndSection
Instead, after the migration to the modesetting driver, it starts screen tearing. The issue could be solved by using compositor. After installed picom and with the following ~/.config/picom/picom.conf, screen is now smooth and everything works perfectly.
unredir-if-possible = false;
vsync = true;
backend = "glx";
glx-no-stencil = true;
glx-no-rebind-pixmap = true;