Bug 241685 - graphics/drm-fbsd12.0-kmod in some cases makes X unusable
Summary: graphics/drm-fbsd12.0-kmod in some cases makes X unusable
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-x11 (Nobody)
Depends on:
Reported: 2019-11-03 09:11 UTC by Oleh Hushchenkov
Modified: 2019-11-04 09:31 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)

Xorg config for video (309 bytes, text/plain)
2019-11-03 17:11 UTC, Oleh Hushchenkov
no flags Details
Xorg log file (23.10 KB, text/plain)
2019-11-03 17:12 UTC, Oleh Hushchenkov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oleh Hushchenkov 2019-11-03 09:11:46 UTC
I have Intel Haswell based laptop with drm-fbsd12.0-kmod on 12.1-STABLE installed.

When I run Firefox, Xorg starts to consume 10% of CPU and system becomes unresponsible to user input. Even if I close Firefox, system still in this state until I reload the graphical session.

With old i915 and drm2 that still in the tree for 12.1-STABLE everything works fine.
Comment 1 Niclas Zeising freebsd_committer 2019-11-03 09:42:38 UTC
Have you recompiled the module after installing FreeBSD 12.1?
Comment 2 Oleh Hushchenkov 2019-11-03 09:47:27 UTC
(In reply to Niclas Zeising from comment #1)

Hi Niclas,

The system and the module are recompiled from source.

Thanks for reply!
Comment 3 pete 2019-11-03 16:49:50 UTC
Are you using an Xorg.conf on this system?  Also, would you be able to post your Xorg.0.log?
Comment 4 Oleh Hushchenkov 2019-11-03 17:11:24 UTC
Created attachment 208825 [details]
Xorg config for video
Comment 5 Oleh Hushchenkov 2019-11-03 17:12:08 UTC
Created attachment 208826 [details]
Xorg log file
Comment 6 Oleh Hushchenkov 2019-11-03 17:18:46 UTC
(In reply to pete from comment #3)
Uploaded config and log.

But I remember that I already saw a similar problem on another desktop system, also with Haswell CPU.

Comment 7 pete 2019-11-03 17:23:13 UTC
(In reply to Oleh Hushchenkov from comment #6)
Thanks for posting those files.  Is it possible to reproduce this issue with no xorg.conf in place.  This should cause Xorg to auto-configure and use the modesetting Xorg driver.

Also, do you notice anything interesting in /var/log/messages or in your dmesg buffer when the system gets into this state?
Comment 8 Oleh Hushchenkov 2019-11-03 17:35:43 UTC
(In reply to pete from comment #7)
I found that a cause of the problem is

Option "TearFree" "true"

in config file.

Without this option there is no issue. With modesetting driver there is also no issue.

But... without this option or with modesetting driver I have tearing... There is no way to use it without tearfree option.
Comment 9 Oleh Hushchenkov 2019-11-03 17:41:12 UTC
(In reply to pete from comment #7)
/var/log/messages has nothing about the issue.
Comment 10 Jan Beich freebsd_committer 2019-11-03 22:39:09 UTC
Does disabling framebuffer compression help? Add either compat.linuxkpi.enable_fbc=0 or compat.linuxkpi.i915_enable_fbc=0 to /boot/loader.conf then reboot (or reload i915kms).
Does replacing TearFree with compton-yshui (aka picom) with --backend glx and --vsync help? Add --use-damage to improve performance.
Comment 11 Theron Tarigo freebsd_committer 2019-11-03 22:39:44 UTC
(In reply to Oleh Hushchenkov from comment #8)
This reads as being very similar to my experience with Intel(R) HD Graphics 530 (Skylake GT2).  If this is really an Xorg problem and not a DRM problem, might it be resolved by bug #236003?
Comment 12 Oleh Hushchenkov 2019-11-04 08:08:12 UTC
Another way to trigger this behavior is running

sxiv -abrf -s d $path_to_dir_with_1000_image_files

and switch to thumbnail mode.

It looks like a resource leak.
Comment 13 Oleh Hushchenkov 2019-11-04 08:44:16 UTC
(In reply to Jan Beich from comment #10)
Looks lite framebuffer compression is disabled by default.

compat.linuxkpi.enable_fbc does not exist.
compat.linuxkpi.i915_enable_fbc already has 0.

Using compton-yshui on this machine leading to performance loss, latency increase and somehow broke video playback with mpv. Enable --use-damage has no impact to performance. But I successfully use compton-yshui on workstation where discrete GPU has enough power to make effect of compton-yshui not so noticeable.

Thanks for suggestions!
Comment 14 Oleh Hushchenkov 2019-11-04 08:50:53 UTC
(In reply to Theron Tarigo from comment #11)
I don't think that this is Xorg problem because it works pretty well on old DRM from base. It looks like a regression. But with old DRM performance is low and I can't use VAAPI to decode video.

I will look on bug #236003.

Comment 15 Oleh Hushchenkov 2019-11-04 09:31:18 UTC
It seems like patch from bug #236003 (xf86-video-intel: update to 2019-07-10 snapshot and refactor) solved this!

So I will close this as solved.

Thanks Jan for the patch and Theron for pointing me on that.