Bug 244306
| Summary: | x11-servers/xorg-server: starting OpenGL application freezes the display (regression with 1.20.7) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Philippe Michel <philippe.michel7> | ||||||
| Component: | Individual Port(s) | Assignee: | freebsd-x11 (Nobody) <x11> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | Mathias.Picker, delphij, freebsd, freebsd, grembo, inbox, ish, james.wright, jrm, o.hushchenkov, oleg.nauman, pi, rhurlin, rkoberman, rsmith, salvadore, tagattie, wulf, zeising | ||||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(x11) |
||||||
| Version: | Latest | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| URL: | https://gitlab.freedesktop.org/xorg/xserver/issues/989 | ||||||||
| Attachments: |
|
||||||||
|
Description
Philippe Michel
2020-02-22 11:10:08 UTC
Created attachment 211830 [details]
Restore xorg-server's FIXDRM option
I have seen very similar bug in the past with xfwm-4.12. It went away after xfwm updating to 4.14 but it is possible that it still exists in some other WMs.
There were several options for me to workaround this at xfwm-4.12 times:
1. Downgrade drm-kmod to 4.11
2. Replace xfwm compositor with compton/picom.
3. Use xf86-video-intel instead of modesetting driver.
4. Rebuild xorg-server with FIXDRM option enabled after enclosed patch has been applied.
Option 4 from the list of workarounds fixed the issue. I didn't try 1 and 3, and 2 is irrelevant (I use fluxbox as WM). I'm not particularly attached to fluxbox, so I suppose I'll look for another window manager that works seamlessly, but for now the workaround is hardly onerous. Thanks for the quick response. Option 3 works on - an X220 running 12.1 and stumpwm - a T530 running 12.1 and fluxbox. Thank you both. I probably see the same issue. My system freezes the moment firefox starts, long before any window is drawn, but glxgears runs fine. I probably should test a few other things like mpv and virtualbox. In any case, it's not just the use of mesa-libs. I will try the patch shortly and see how that works for me. Please update the ticket to "Affects some people". Uninstalling xf86-video-intel and installing the patched xorg-server with the fixdrm knob turned on also fixes the problem (on the X220). I can confirm that FIXDRM fixes the problem for me. All drivers and servers are up to date. Note: System is ThinkPad T520. Sandy Bridge graphics. Just short of 9 years old. Also, just for the record, I have been running modesetting or a long time, so xf86-video-intel was already absent from the system. Just to confirm, this issue happens even with the latest drm-*-kmod from 20200221? For all my tests, I had drm-fbsd12.0-kmod-4.16.g20200221 installed. (In reply to Niclas Zeising from comment #8) Yes.I updated the drm-kmod-* to 20200221 during troubleshooting and the problem remained. Only after the FIXDRM patch would X survive starting firefox. Since then, there have been no problems. It fixes KDE rendering with new xorg-server. Thank you FIXDRM patch also fixed it for me. drm-fbsd12.0-kmod-4.16.g20200221 12.0-STABLE using drm only. xorg-server 1.20.7,1 devd off fixdrm on suid on udev on without patch: on laptop: startx konsole firefox <--- screen frozen I'd ssh into laptop from desktop, kill xinit, got my vt back as if nothing ever happened. Also, a user not part of 'video' group could start firefox just fine user in video group always froze up the screen. (In reply to Peter from comment #12) window manager is i3. Just to confirm, I also have this issue.
(modesetting driver, Intel Kaby Lake, i3 window manager)
1.18 Xorg.0.log:
[ 645.255] (II) modeset(0): [DRI2] Setup complete
[ 645.255] (II) modeset(0): [DRI2] DRI driver: i965
[ 645.255] (II) modeset(0): [DRI2] VDPAU driver: i965
[ 645.305] (--) RandR disabled
[ 645.310] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 645.310] (II) AIGLX: enabled GLX_ARB_create_context
[ 645.310] (II) AIGLX: enabled GLX_ARB_create_context_profile
[ 645.310] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile
[ 645.310] (II) AIGLX: enabled GLX_INTEL_swap_event
[ 645.310] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[ 645.310] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB
[ 645.310] (II) AIGLX: enabled GLX_ARB_fbconfig_float
[ 645.310] (II) AIGLX: enabled GLX_EXT_fbconfig_packed_float
[ 645.310] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[ 645.310] (II) AIGLX: enabled GLX_ARB_create_context_robustness
[ 645.310] (II) AIGLX: Loaded and initialized i965
[ 645.310] (II) GLX: Initialized DRI2 GL provider for screen 0
1.20 Xorg.0.log:
[ 404.294] (II) modeset(0): [DRI2] Setup complete
[ 404.294] (II) modeset(0): [DRI2] DRI driver: i965
[ 404.294] (II) modeset(0): [DRI2] VDPAU driver: i965
[ 404.294] (II) Initializing extension Generic Event Extension
[ 404.294] (II) Initializing extension SHAPE
[ 404.294] (II) Initializing extension MIT-SHM
[ 404.294] (II) Initializing extension XInputExtension
[ 404.294] (II) Initializing extension XTEST
[ 404.294] (II) Initializing extension BIG-REQUESTS
[ 404.295] (II) Initializing extension SYNC
[ 404.295] (II) Initializing extension XKEYBOARD
[ 404.295] (II) Initializing extension XC-MISC
[ 404.295] (II) Initializing extension SECURITY
[ 404.295] (II) Initializing extension XFIXES
[ 404.295] (II) Initializing extension RENDER
[ 404.295] (II) Initializing extension RANDR
[ 404.296] (II) Initializing extension COMPOSITE
[ 404.296] (II) Initializing extension DAMAGE
[ 404.296] (II) Initializing extension MIT-SCREEN-SAVER
[ 404.296] (II) Initializing extension DOUBLE-BUFFER
[ 404.296] (II) Initializing extension RECORD
[ 404.296] (II) Initializing extension DPMS
[ 404.296] (II) Initializing extension Present
[ 404.297] (II) Initializing extension DRI3
[ 404.297] (II) Initializing extension X-Resource
[ 404.297] (II) Initializing extension XVideo
[ 404.297] (II) Initializing extension XVideo-MotionCompensation
[ 404.297] (II) Initializing extension GLX
[ 404.300] (II) AIGLX: Loaded and initialized i965
[ 404.300] (II) GLX: Initialized DRI2 GL provider for screen 0
Will try the patch and report back.
(In reply to rsmith from comment #14) The provided FIXDRM patch fixed the issue for me as well. (In reply to Vladimir Kondratyev from comment #1) Option 3 (xf86-video-intel) worked, but is not desirable for me due to higher current consumption. Option 4 (FIXDRM-patch) works like a charm on my Lenovo TP T450 and fixes the problem for me, too. (In reply to Manuel Stühn from comment #16) > Option 3 (xf86-video-intel) worked, but is not desirable for me > due to higher current consumption. Default AccelMethod is UXA which is not as efficient as SNA. Just additional feedback: for me and a friend, both with X1 Tablet with FreeBSD-stable, this error popped up and the fixdrm patch/option fixed it for us. Thanks a lot! Mathias (In reply to Manuel Stühn from comment #16) (In reply to Jan Beich from comment #17) I had tearing issues with modesetting in the past, that's why I still prefer xf86-video-intel. Seems like I need to test again. Thanks to both of you for your input on power consumption, I'll try both configurations and see what gives me the best mileage. (In reply to Vladimir Kondratyev from comment #1) I tested 2. Running 'picom' triggers the problem, but running 'picom --backend glx' is a workaround (can start firefox, chrome, mpv, etc.). I do confirm that it is needed and it works on x1 7th gen (UHD Graphics 620 (Whiskey Lake)) Do we have a list of hardware and software combinations that need this? From what I can tell, most intel hardware, when using the modesetting driver, needs this fix, unless they are running a compositor, such as picom or compton? It does work however, if they are using xf86-video-intel? Is this correct? We are looking into the proposed patch, but would like a little bit of time figuring out what's going on and why it's needed. I have no problems with it being committed defaulting to off for now, though. (In reply to Niclas Zeising from comment #23) These are the system that I am aware of: Sandy Bridge Ivy Bridge Broadwell Kaby Lake Whiskey Lake You're summary sound right, except picom will trigger the problem if run without arguments, but will be a workaround if run as 'picom --backend glx'. Could you approve the Phab diff and I'll commit it? (In reply to Joseph Mingrone from comment #24) Is this regardless of FreeBSD version and drm-kmod version? According to wulf@'s post (second message here), downgrading drm-kmod to 4.11 is a workaround, so all drm-kmod are not affected. A commit references this bug: Author: jrm Date: Tue Feb 25 17:32:04 UTC 2020 New revision: 527097 URL: https://svnweb.freebsd.org/changeset/ports/527097 Log: x11-servers/xorg-server: Restore FIXDRM as an off-by-default knob This is a workaround for a problem with certain systems [1] after x11-servers/xorg-server was upgraded to 1.20.7. Other workarounds are described in PR 244306. [1] These systems have been reported to have problems: Sandy Bridge Ivy Bridge Broadwell Kaby Lake Whiskey Lake PR: 244306 Submitted by: wulf Reported by: philippe.michel7@free.fr Approved by: x11 (zeising) Differential Revision: https://reviews.freebsd.org/D23834 Changes: head/x11-servers/xorg-server/Makefile head/x11-servers/xorg-server/pkg-message Created attachment 211930 [details]
Update mesa to 19.0.8
Hi!
This issue *might* be fixed by updating mesa. I have a patch (attached) for this. Can those of you who experience this issue please apply it, and rebuild mesa-dri and mesa-libs and xorg-server without the FIXDRM option and try it.
Thank you very much!
(In reply to Niclas Zeising from comment #28) The mesa update doesn't solve the problem. (In reply to Joseph Mingrone from comment #29) > The mesa update doesn't solve the problem. Can you try with "export LIBGL_DRI3_ENABLE=1"? Make sure the environment variable is visible to all GL applications i.e., put it into ~/.profile or ~/.login (after converting to csh-like syntax) rather than ~/.xinitrc. (In reply to Jan Beich from comment #30) With `export LIBGL_DRI3_ENABLE=1` in the environment, everything seems to be working fine after a few minutes. (In reply to Jan Beich from comment #30) Thank you for good information. After adding 'setenv LIBGL_DRI3_ENABLE 1' to ~/.envrc, firefox 73.0.1 works fine on 13.0-CURRENT r358308 with i7-4500U(haswell). (In reply to Masachika ISHIZUKA from comment #32) Is this using modesetting or xf86-video-intel? Which drm-kmod version are you using? Thanks! The FIXDRM option has fixed most of this issue for me but has opened up another issue. I have a dual monitor setup and with the FIXDRM option turned on... I get weird artifacts on the monitor opposite of the monitor displaying the mouse cursor. Move the cursor to the other monitor and the artifacts switches to the opposite monitor. If I rebuild xorg with the FIXDRM option turned off the artifacts go away but of course, the freezing comes back. i5 / 915 intel, i3wm, FreeBSD 12.1-p2, all ports up to date. I recall screen artifacts from some time ago. I thought there is/was an issue somewhere (Gitlab, or one of the GitHub repos maybe?), but I can't find it. If what you are describing was the same as I experienced, the problem occurred after rebooting. If I restarted X after the reboot the artifacts went away. In any case, it sounds like installing xf86-video-intel or forcing DRI3 with the suggestion jbeich posted might be a better solution for you. (In reply to Niclas Zeising from comment #28) I can confirm that the mesa-update and DRI3-Flag works here for this setup: - Intel(R) Core(TM) i5-5300U CPU (HD Graphics 5500) - FreeBSD 12.1-RELEASE-p2 - drm-fbsd12.0-kmod-4.16.g20200221 - mesa-dri-19.0.8 - mesa-libs-19.0.8 - xorg-server 1.20.7_1,1 FIXDRM : off - .login_conf setting :setenv=LIBGL_DRI3_ENABLE=1: - using modesetting-driver (xf86-video-intel not even installed) Thank you! (In reply to Niclas Zeising from comment #28) Works on my Sandy Bridge ThinkPad T520. LIBGL_DRI3_ENABLE is set to 1. xorg-server built without FIXDRM. Latest drm-KMOD (20200221) installed. (In reply to Niclas Zeising from comment #33) I'm using modeset and drm-current-kmod-4.16.g20200221. This is good working with i5-7500(kaby lake), too. (In reply to Niclas Zeising from comment #28) I can confirm that the mesa update works. - Intel(R) Core(TM) i7-7700HQ (Intel HD Graphics 630) - FreeBSD 12.1-STABLE r354571 GENERIC amd64 - drm-fbsd12.0-kmod-4.16.g20200221 - gpu-firmware-kmod-g20200130 - mesa-dri-19.0.8 - mesa-libs-19.0.8 - xorg-server-1.20.7_1,1 (OPTIONS_FILE_UNSET+=FIXDRM) - LIBGL_DRI3_ENABLE=1 is set. The intel driver is not installed; the modesetting driver is used. The only problem with this update is that mesa still has a build dependency on Python 2.7. (see mesa-dri/Makefile.common). So, in mesa-dri/Makefile.common I changed "python:2.7,build" to "python:build", re-built and re-installed mesa-libs and mesa-dri and it worked fine with Python 3.7. Other than xorg-server, libosmesa and mesa-dri I did *not* have to rebuild any of the programs that require mesa-libs. I can confirm that the mesa update works. - Intel(R) Xeon(R) CPU E3-1505M v6 (Intel HD Graphics P630) - FreeBSD 13.0-CURRENT r358478 GENERIC amd64 - drm-kmod 54164ffbc9dd6f37dae4d898bf7a516200ab3c5c - gpu-firmware-kmod c9eb7f3ce53ae220e1c76004265593e06b5c583b - mesa-dri-19.0.8 - mesa-libs-19.0.8 - xorg-server-1.20.7_1,1 (OPTIONS_FILE_UNSET+=FIXDRM) - LIBGL_DRI3_ENABLE=1 is set. However, it seems wired memory would increase rather quickly, which may or maybe not related. (In reply to Xin LI from comment #40) The issue with wired memory is caused by https://svnweb.freebsd.org/base?view=revision&revision=358363 . Thanks for the report! Mesa patch tested successfully with the following settings: - Intel(R) Celeron(R) CPU 1007U (3rd Gen Core processor Graphics Controller) - FreeBSD 13.0-CURRENT r358179 GENERIC amd64 - drm-current-kmod-4.16.g20200221 - gpu-firmware-kmod-g20200130 - mesa-dri-19.0.8 - mesa-libs-19.0.8 - xorg-server 1.20.7_1,1 FIXDRM : off - LIBGL_DRI3_ENABLE=1 is set - using modesetting-driver (xf86-video-intel not even installed) (In reply to Niclas Zeising from comment #28) One thing not solved by the mesa update is multimedia/mpv locking up the display when using VAAPI. Additionally, mpv complains when I use VDPAU (since it's emulated by libvdpau-va-gl). So, since this update enables the use of the vulkan API on Intel graphics hardware, I have rebuilt miltimedia/mpv with vulkan support. This also works fine; no more lockups with mpv and somewhat lower CPU usage when using it. And I can now play vkquake. ;-) Hit the same issue of OpenGl apps freezing on MacBookAir (Broadwell). Simply setting the LIBGL_DRI3_ENABLE flag fixed it for me without changing anything else; - Intel(R) Core(TM) i7-5650U CPU (HD Graphics 6000) - FreeBSD 12.1-STABLE (r358483) - drm-fbsd12.0-kmod-4.16.g20200221 (built from ports) - mesa-dri-18.3.2_9 (pkg) - mesa-libs-18.3.2_3 (pkg) - xorg-server 1.20.7_1,1 (pkg) - using modesetting-driver (configured vua /etc/X11/xorg.conf) - added "export LIBGL_DRI3_ENABLE=1" to my ~/.zshrc A commit references this bug: Author: zeising Date: Sun Mar 8 19:27:28 UTC 2020 New revision: 528071 URL: https://svnweb.freebsd.org/changeset/ports/528071 Log: graphics/mesa-libs: Change default to use DRI3 Change the default mesa configuration to use DRI3 rather than the older DRI2 interface. This should improve performance somewhat, and alleviates the need for the FIXDRM option in x11-servers/xorg-server. Remove the FIXDRM option from x11-servers/xorg-server. Add an UPDATING entry for the change. For users of graphics/drm-legacy-kmod or the base graphics drivers, this might cause regressions. If you experience problems when running OpenGL applications please force the use of the DRI2 backend by setting the LIBGL_DRI3_DISABLE environment variable to 1 before starting any OpenGL application. This is easiest done by adding it to your shell startup file or .xinitrc. Add UPDATING entry for xorg-server, detailing the change of device configuration backend. PR: 196678, 244306 (for tracking) Changes: head/UPDATING head/graphics/mesa-dri/files/patch-src_egl_drivers_dri2_platform__x11.c head/graphics/mesa-dri/files/patch-src_glx_glxext.c head/graphics/mesa-libs/Makefile head/x11-servers/xorg-server/Makefile Hi! Thank you to all of you who have helped testing, and sorry for keeping you waiting. I've just committed an update that makes mesa use DRI3 by default, which should alleviate the need for the FIXDRM option. If you still have trouble, even after updating mesa-libs past 18.3.2_4, please let me know asap. Regards Niclas Zeising FreeBSD Graphics Team Will do. Thanks Niclas. (In reply to Niclas Zeising from comment #46) Will the mesa ports be updated to 19.0.x? (In reply to rsmith from comment #48) There is already a seperate PR for that here; https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235570 After the switch to use DRI3, this bug should be solved. If the issue persists, please reopen this bug, or create a new one. |
