|Summary:||mesa xdemo manywin aborts with intel_do_flush_locked error|
|Component:||Drivers/DRI/i965||Assignee:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|Status:||RESOLVED MOVED||QA Contact:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|Priority:||medium||CC:||artanisshen, blubb_tec, christophe.prigent, eodabash, harvey.harrison, jiewen.lin, org.freedesktop, sgothel, stacktracer, vasyl.demin, waqasahmadtarar786|
|i915 platform:||i915 features:|
|Bug Depends on:|
Description cc 2011-10-12 17:20:35 UTC
Mesa xdemo manywin fails with following commits on the both IVB and SNB platform, the case finished unexpectly,end report a message: intel_do_flush_locked failed: No such file or directory System Environment: OSD: Fedora release 13 (Goddard) Kernel_version: 18.104.22.168 Libdrm: (master)2.4.26-11-gc82ef03e4c92017bf5644f294ea04e30500f8d4c Mesa: (master)a13eed4b826d0bb5dfcb5e63651987a232df8a06 Xserver: (master)xorg-server-1.11.0-176-gfae7ed62ad476114bd37b566202cf6b6546c0a1f Xf86_video_intel: (master)2.16.0-119-gd0184b59095d5b8fab1a65ceba075d29189130d4 Cairo: (master)3d51ec8a7928f313d73023cabe0d760cf1946458 Libva: (master)8384a84cd03a1c0ef4c57f7d0c2e8cc6e71b7c91 Kernel_unstable: (drm-intel-next)64a742fac3a22f57303d8f1b7e347350a1c48254 Bug detailed description: start X,then run manywin n(n>1), the case finished unexpectly, end report a message:intel_do_flush_locked failed: No such file or directory. Reproduce steps: ---------------- 1. xinit & 2. ./manywin 8
Comment 1 cc 2012-01-17 19:29:28 UTC
This issue is still on. the latest environment: Kernel_version: 3.2.0_stable_20120112+ Libdrm: (master)2.4.30-1-g66518ab5653cfdc840cd69e7b653ec05df060584 Mesa: (8.0)9489ae8938b74551913337876656bcb9178a8905
Comment 2 Illya Klymov 2012-09-10 13:39:09 UTC
Same happens for me OSD: ArchLinux x86_64 Libdrm: 2.4.39-1 Mesa: 8.0.4-3 Xserver: 1.12.4-1 xf86-video-intel: 2.20.6-1 Tested also with latest GIT - same problem persists
Comment 3 ye.tian 2012-10-25 07:12:09 UTC
This issue is still on Pineview. environment: OSD: ArchLinux i386 Libdrm: (master)libdrm-2.4.39 Mesa: (9.0)03785fe360e2e63d1a63a6130e7e44141444c9d8 Xserver: (server-1.13-branch)xorg-server-1.13.0 Xf86_video_intel: (master)2.20.12 Cairo: (master)fab6958eff35a94cf46e38f19a7e75e10aa2b182 Libva: (master)ab06c8cb5d41e21b03c3d17c5898fae8261113e6 Libva_intel_driver:(master)a97403b2b9b5542aa6dd311b23b562a413abd431 Kernel: 3.6.3
Comment 4 Guang Yang 2012-10-29 03:39:41 UTC
This issue occurs on IVB ,too. Testing Environment: Libdrm: (master)libdrm-2.4.39 Mesa: (9.0)5fe5aa8e55a8db0b80f6ff9838bad47ce0406fd0 Xserver: (server-1.13-branch)xorg-server-1.13.0 Xf86_video_intel: (master)2.20.12 Cairo: (master)fab6958eff35a94cf46e38f19a7e75e10aa2b182 Libva: (master)ab06c8cb5d41e21b03c3d17c5898fae8261113e6 Libva_intel_driver: (master)a97403b2b9b5542aa6dd311b23b562a413abd431 Kernel: (linux-3.2.y)9f2a940965286754f3a34d5737c3097c05db8725
Comment 5 meng 2013-03-11 05:42:34 UTC
The problem still exists on the driver. environment -------------------- Libdrm: (master)libdrm-2.4.42 Mesa: (9.1)mesa-9.1(git-17493b8) Xserver: (server-1.13-branch)xorg-server-22.214.171.1242 Xf86_video_intel:(master)2.21.3 Cairo: (master)1.12.14 Libva: (master)libva-1.1.0 Libva_intel_driver: (master)00f65b78e6de520a4820702207ce098c6b073724 Kernel: 3.8
Comment 6 Eric Anholt 2013-09-30 23:30:38 UTC
*** Bug 18262 has been marked as a duplicate of this bug. ***
Comment 7 Eric Anholt 2013-09-30 23:33:02 UTC
This app is doing context sharing between multiple xlib Displays, which is crazy. We don't support that. If we were to support that, we would need some even-more-global structure than the per-Display intel_screen in which to store things like the bufmgr.
Comment 8 Sven Gothel 2013-10-30 23:07:03 UTC
Re comment 7: Eric, how else can one achieve non-blocking rendering w/ I/O, if not using exclusive X11 display connections for multiple shared GL context and X11 events ? Using one X11 display connection for the many shared context, one would need to add synchronization for the X11 display commands, which is bogus. For JOGL, we explicitly use exclusive display connections to achieve block-free multithreading. We would love to see this fixed to enable shared GL context in a concurrent use-case, since it is essential to many applications of our user base. Note: The described mechanism works flawless on all other OpenGL driver implementations, including other Mesa backends, as well with NV and AMD proprietary drivers. Further more, the spec does not disclose such scenario, as long the display connection references the 'same' display. See: <https://jogamp.org/bugzilla/show_bug.cgi?id=873#c4>
Comment 9 Sven Gothel 2013-10-30 23:14:11 UTC
*** Bug 50873 has been marked as a duplicate of this bug. ***
Comment 10 org.freedesktop 2013-10-30 23:34:15 UTC
I can attest that this problem would essentially cripple my software on Intel GPUs. I've worked hard to ensure that the rendering code works on every OpenGL context I can find, but the engine itself is heavily dependent on being able to constantly stream resources in a manner that won't block the main renderer. Without the ability to do this, I'm essentially left with the option of not supporting Intel, which would be silly!
Comment 11 Sven Gothel 2013-10-31 00:18:45 UTC
RE: comment 7: Eric, maybe you can store these buffer details in a storage space accessible via a [hash] map on the unique X11 display connection name. This is one way how we (JOGL) mitigate other issues and cache unique details regarding the display device as referenced by multiple connections. Sort of a display-local-storage, similar to TLS. Since I don't know Mesa's or DRM's infrastructure I don't know whether such thing already exists.
Comment 12 Sven Gothel 2013-10-31 00:19:49 UTC
re comment 11: .. maybe only as a slow path, if you cannot find the reference locally .. where you exit w/ said error message.
Comment 13 Harvey Harrison 2014-01-26 06:19:37 UTC
I'm curious if there has been any movement on this issue. I've gotten a few reports of this now from external users and all I can tell them is that we do not support the linux Intel driver at this time. We require the shared context as we load all of our resources async into a master context, trying not to block the individual display rendering while we do so.
Comment 14 Elvis Stansvik 2015-05-22 16:18:18 UTC
I'm curious as well. I'm hitting this issue when trying to run BricsCAD, a proprietary CAD software, on my Lenovo X220. My environment: OSD: ArchLinux x86_64 Libdrm: 2.4.61-1 Mesa: 10.5.5-1 Xserver: 1.17.1-5 xf86-video-intel: 2.99.917-5 How come this is marked as low importance?
Comment 15 Agens1989 2015-08-29 16:10:33 UTC
(In reply to Elvis Stansvik from comment #14) > I'm curious as well. I'm hitting this issue when trying to run BricsCAD, a > proprietary CAD software, on my Lenovo X220. > Same on different laptop. > How come this is marked as low importance? This was a bug in the bug, fixed.
Comment 16 Andreas Reis 2015-08-31 16:15:32 UTC
Got the same issue on my HSW 4200U since only a few days. Hitting it with Steam and Chromium – seems one of them runs fine, then the next one fails. Chrome just falls back to software rendering for everything, Steam aborts with "intel_do_flush_locked failed: Invalid argument". drm-intel-nightly mesa-git libdrm-git xf86-video-intel (All versions from yesterday.)
Comment 17 Chris Wilson 2015-08-31 18:33:11 UTC
(In reply to Andreas Reis from comment #16) > Got the same issue on my HSW 4200U since only a few days. Hitting it with > Steam and Chromium – seems one of them runs fine, then the next one fails. > > Chrome just falls back to software rendering for everything, Steam aborts > with "intel_do_flush_locked failed: Invalid argument". > > drm-intel-nightly > mesa-git > libdrm-git > xf86-video-intel > (All versions from yesterday.) This is a completely different problem. The original ENOENT is likely a very old bug in mesa or libdrm (for example not tracking name reuse). EINVAL is new, and I presume a cmdparser failure, so please file a new bug with a minimal example and the dmesg, you may need to use drm.debug=7.
Comment 18 org.freedesktop 2017-06-19 14:00:36 UTC
Still broken: $ glxinfo | grep OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.0.5 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 17.0.5 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.0.5 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions: $ uname -a Linux copperhead 4.10.13-1-ARCH #1 SMP PREEMPT Thu Apr 27 12:15:09 CEST 2017 x86_64 GNU/Linux $ manywin 2 2 windows 0, 0 Name: 0 Display: 0x223e110 Window: 0x5400002 Context: 0x22538b0 GL_VERSION: 3.0 Mesa 17.0.5 GL_VENDOR: Intel Open Source Technology Center GL_RENDERER: Mesa DRI Intel(R) Sandybridge Mobile 100, 0 sharing Name: 1 Display: 0x26e1bc0 Window: 0x5a00002 Context: 0x26e4080 GL_VERSION: 3.0 Mesa 17.0.5 GL_VENDOR: Intel Open Source Technology Center GL_RENDERER: Mesa DRI Intel(R) Sandybridge Mobile intel_do_flush_locked failed: No such file or directory xorg-bdftopcf 1.0.5-1 xorg-server 1.19.3-2 xorg-server-common 1.19.3-2 xorg-server-xephyr 1.19.3-2 xorg-server-xwayland 1.19.3-2 xorg-xrandr 1.5.0-1 xorg-xrdb 1.1.0-2 libdrm 2.4.80-1 This is still breaking asynchronous texture/mesh/shader loading under JOGL.
Comment 19 GitLab Migration User 2019-09-25 18:49:01 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1373.