GNOME developers resolved an annoying bug with fix frame timings

General Discussion
1

My initial user experience with Clear Linux using Gnome was awkward for the first week. The reason is due to the following issues.

Mar 12 00:31:30 clr-linux /usr/libexec/gdm-x-session[4602]: (EE) event4  - Kinesis Freestyle Edge Keyboard: client bug: event processing lagging behind by 16ms, your system is too slow

Mar 12 00:31:30 clr-linux /usr/libexec/gdm-x-session[4602]: (EE) event4  - Kinesis Freestyle Edge Keyboard: client bug: event processing lagging behind by 16ms, your system is too slow

Mar 12 03:20:06 clr-linux /usr/libexec/gdm-x-session[1276]: (II) event11 - Logitech M705: SYN_DROPPED event - some input events have been lost.

Mar 12 03:20:07 clr-linux /usr/libexec/gdm-x-session[1276]: (EE) event11 - Logitech M705: client bug: event processing lagging behind by 12ms, your system is too slow

lots of these

Typing in GNOME Terminal is troublesome until installing the Wandering Pixel extension and enabling GNOME animations. Without this extension, I experience Mutter issue 1471 and UI Stutter (NVIDIA+Xorg) 1561.

The great news is that this annoyance has been resolved with Fix frame timings resulting in stuck clients in certain situations !1754.

Hoping that the bug fix makes it way to Clear Linux. In the mean time, the Wondering Pixel extension is keeping Gnome stable and fluid. Typing behaves as one would expect in Gnome Terminal.

Since yesterday, I am using Clear Linux with joy. Thank you, Justin Donnelly for the work around.

1 Like
2

Created bug issue 2302.

3

Red Hat applied fixes in mutter-3.38.3-2.fc33 recently for Fedora 33. I applied the same patches to mutter 3.38.3 in Clear Linux. Installing build dependencies required beyond 2 gigabyte download. Yikes!

Building instructions after applying patches came from the mutter SPEC file in Clear Linux.

sudo swupd bundle-add c-basic desktop-dev

cd ~/Downloads
curl -LO https://kojipkgs.fedoraproject.org//packages/mutter/3.38.3/2.fc33/src/mutter-3.38.3-2.fc33.src.rpm
rpm -iv mutter-3.38.3-2.fc33.src.rpm

cd ~/rpmbuild/SOURCES
tar xf mutter-3.38.3.tar.xz
cd mutter-3.38.3

patch -p1 < ../0001-window-actor-Special-case-shaped-Java-windows.patch
patch -p1 < ../mutter-commits-after-3.38.3.patch

export http_proxy=http://127.0.0.1:9/
export https_proxy=http://127.0.0.1:9/
export no_proxy=localhost,127.0.0.1,0.0.0.0
export LANG=C.UTF-8
export SOURCE_DATE_EPOCH=1611707506
export GCC_IGNORE_WERROR=1
export AR=gcc-ar
export RANLIB=gcc-ranlib
export NM=gcc-nm

export CFLAGS="$CFLAGS -O3 -Os -falign-functions=32 -fdata-sections -ffat-lto-objects -ffunction-sections -flto=4 -fno-math-errno -fno-semantic-interposition -fno-trapping-math "
export FCFLAGS="$FFLAGS -O3 -Os -falign-functions=32 -fdata-sections -ffat-lto-objects -ffunction-sections -flto=4 -fno-math-errno -fno-semantic-interposition -fno-trapping-math "
export FFLAGS="$FFLAGS -O3 -Os -falign-functions=32 -fdata-sections -ffat-lto-objects -ffunction-sections -flto=4 -fno-math-errno -fno-semantic-interposition -fno-trapping-math "
export CXXFLAGS="$CXXFLAGS -O3 -Os -falign-functions=32 -fdata-sections -ffat-lto-objects -ffunction-sections -flto=4 -fno-math-errno -fno-semantic-interposition -fno-trapping-math "

CFLAGS="$CFLAGS" CXXFLAGS="$CXXFLAGS" LDFLAGS="$LDFLAGS" meson --libdir=lib64 --prefix=/usr --buildtype=plain   builddir

ninja -v -C builddir

sudo ninja -C builddir install

This will fix annoyances mentioned above. Optionally, there is one more thing needed for NVIDIA’s proprietary driver to run fluidly; i.e. moving a window in a circle on top of Firefox playing a YouTube video.

Launch NVIDIA settings.

/opt/nvidia/bin/nvidia-settings

Go to X Server Display Configuration > Advanced… > (enable) Force Full Composition Pipeline. That will implicitly enable the other checkbox Force Composition Pipeline.

Save the X configuration to a writable location; i.e. /tmp/screen.conf.

Edit /tmp/screen.conf and remove everything except the Screen section. For example, this is the Screen section for my display.

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-2"
    Option         "metamodes" "nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Review the file and ensure only the Screen section remains. All that’s left is to persist the change.

sudo mkdir -p /etc/X11/xorg.conf.d
sudo cp /tmp/screen.conf /etc/X11/xorg.conf.d/nvidia-screen-opt.conf

Reboot and enjoy a more stable mutter.

Typing inside a GNOME Terminal behaves like one would expect. Drop down menus work without delays. Screen updates appear immediately while hovering over menu items. My last test involves moving a window around the screen while Firefox is playing a YouTube video. Mutter no longer freezes momentarily.

What a relief!

Other ways to enable full composition pipeline automatically.

Difference between Force Full Composition Pipeline and Force Composition Pipeline.

2 Likes
4

I much enjoy Clear Linux now. Above, I met to add that the optional step for enabling ForceFullCompositionPipeline is needed for the native kernel to not experience desktop freezing, while moving the Terminal window over Firefox playing a YouTube video. The real time kernel-rt is fine and not necessary to enable ForceFullCompositionPipeline.

Upon reading kernel/common/inc/nv-linux.h, it appears (yeah) that the preemptive kernel is supported. That appears to be the case for the NVIDIA 460.56 driver. Well, trying is the only way to find out. Below are the steps taken for installing the proprietary driver. Currently missing is the linux-rt-dev bundle in Clear Linux. Thus the reason for installing manually two RPM files.

Prerequisite:

Install the NVIDIA proprietary driver first as usual for the native or lts kernel.

Preparation:

Extract files from the NVIDIA installer package. Files will reside in NVIDIA-Linux-x86_64-460.56. I will be installing the 460.56 driver later on.

cd ~/Downloads
NVIDIA-Linux-x86_64-460.56.run -x

Install the kernel-rt bundle and two RPMs. An issue was added for the missing linux-rt-dev bundle. In the meantime, ensure the correct OS version when obtaining the two RPMs. Likewise, update the package version accordingly. I’m running 34370.

sudo swup bundle-add kernel-rt

cd ~/Downloads
curl -LO https://cdn.download.clearlinux.org/releases/34370/clear/x86_64/os/Packages/linux-preempt-rt-dev-5.6.19-70.x86_64.rpm
curl -LO https://cdn.download.clearlinux.org/releases/34370/clear/x86_64/os/Packages/linux-preempt-rt-extra-5.6.19-70.x86_64.rpm

sudo rpm -ivh linux-preempt-rt-*-5.6.19-70.*.rpm --nodeps

Set a timeout for the boot manager if not already done. The default is 0. This allows one to select the kernel from the boot screen.

sudo clr-boot-manager get-timeout
sudo clr-boot-manager set-timeout 10

Installation:

Important, ensure booting into multi user mode. Then reboot into the real-time kernel.

sudo systemctl set-default multi-user.target
reboot

Log in and sudo to root. Ensure booted into the real-time kernel.

sudo su
uname -a

Next we will be installing the proprietary driver. This requires setting an environment variable for the installer.

export IGNORE_PREEMPT_RT_PRESENCE=1
cd /home/<USER>/Downloads/NVIDIA-Linux-x86_64-460.56/kernel
make -j 4
make modules_install

Finally, enable graphical boot and reboot.

systemctl set-default graphical.target
reboot

Hurray! The real-time kernel and the proprietary driver work wonderfully. :smile:

5

I’ve no idea what’s a real-time(rt) kernel. Would this work with regular (dkms) kernel?

6

The kernel-rt bundle in Clear Linux installs 5.6.19-70.preempt_rt with real-time kernel patches applied. Not yet available are the kernel-rt-dkms and linux-rt-dev bundles. Thus I tried manual installation without dkms.

It requires setting the IGNORE_PREEMPT_RT_PRESENCE to be set or will not install if using the dkms method. For dkms to work, the following is needed possibly.

sudo mkdir -p /etc/profile.d
sudo echo 'export IGNORE_PREEMPT_RT_PRESENCE=1' >/etc/profile.d/nvidia-allow-rt-install.sh
7

There is a nice write up at Arch Linux describing real-time. I am delighted that one is able to install the NVIDIA proprietary driver on top of 5.6.19-70.preempt_rt in Clear Linux. I can confirm that it works well, at least for 5.6.19-70.preempt_rt (kernel-rt bundle).

1 Like
8

Running the NVIDIA proprietary driver with the real-time kernel is not yet ready. I put it through testing by running hackbench and cyclictest from the performance-tools bundle.

Preparation:

sudo su
sync; echo 3 > /proc/sys/vm/drop_caches
exit

Testing:

Terminal 1:  hackbench -l 500000
Terminal 2:  sudo cyclictest --smp -p98 -m -D 120 -q
Terminal 3:  time ls -R /usr

Error:

[  119.020144] BUG: scheduling while atomic: irq/68-s-nvidia/1167/0x00000002
[  119.020148] Modules linked in: hid_logitech_hidpp joydev hid_logitech_dj snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device mc cdc_acm eeepc_wmi asus_wmi battery sparse_keymap rfkill wmi_bmof mxm_wmi kvm_amd nvidia_drm(POE) nvidia_modeset(POE) snd_hda_codec_hdmi igb snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore nvidia(POE) ccp k10temp nvidiafb vgastate fb_ddc i2c_piix4 wmi pinctrl_amd
[  119.020164] Preemption disabled at:
[  119.020164] [<ffffffffc061e10d>] os_acquire_spinlock+0xd/0x20 [nvidia]
[  119.020297] CPU: 2 PID: 1167 Comm: irq/68-s-nvidia Tainted: P           OE     5.6.19-70.preempt_rt #1
...
[  119.020299] Call Trace:
[  119.020302]  show_stack+0x47/0x56
[  119.020305]  dump_stack+0x5a/0x78
[  119.020308]  ? os_acquire_spinlock+0xd/0x20 [nvidia]
[  119.020433]  __schedule_bug.cold+0x89/0x9a
[  119.020435]  __schedule+0x484/0x6a0
[  119.020437]  schedule+0x4e/0x110
[  119.020438]  rt_spin_lock_slowlock_locked+0x120/0x2e0
[  119.020439]  rt_spin_lock_slowlock+0x43/0x70
[  119.020441]  rt_spin_lock+0x43/0x50
[  119.020442]  __wake_up_common_lock+0x4b/0xa0
[  119.020444]  __wake_up+0xe/0x20
[  119.020445]  ep_poll_callback+0xb3/0x260
[  119.020447]  __wake_up_common+0x80/0x190
[  119.020448]  __wake_up_common_lock+0x63/0xa0
[  119.020450]  __wake_up+0xe/0x20
[  119.020451]  nv_post_event+0x107/0x140 [nvidia]
[  119.020576]  _nv035455rm+0x59/0x80 [nvidia]
[  119.020722] WARNING: kernel stack frame pointer at 00000000b492050d in irq/68-s-nvidia:1167 has bad value 00000000c72cdeb3

Someone posted a bug in August, 2020. Well, I gave the proprietary driver a try and was hopeful it would work with the real-time kernel.

9

I will post a new thread in the near future on how to run the real-time kernel with the proprietary driver. Giving up was not an option and thus tried again. It has been 1.5 days and unable to get the driver to fail. It is wonderful indeed. 1.5 days is too soon to call it success.

10

The NVIDIA 455.x and 460.x drivers, for some reason, do not pass due to the spin-lock issue.

So I next tried 450.102.04. This version works with the real-time kernel. Simply set IGNORE_PREEMPT_RT_PRESENCE=1 when installing the kernel modules. It has been over a week and have not experienced any issues with 450.x no matter the level of stress testing. Now I switch back and forth between the real-time and native kernels.

Off-topic:

I next focused on Firefox, VAAPI, FFmpeg, x264 (8, 10 bits), x265 (8, 10, 12 bits), and oh my a journey in itself. In Firefox, H.264 via h264ify and vp9 are handled via hardware acceleration on the GPU. This makes h264ify optional with vp9 working.