Bug 41736 - mesa xdemo manywin aborts with intel_do_flush_locked error
mesa xdemo manywin aborts with intel_do_flush_locked error
Status: NEW
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965
unspecified
x86 (IA32) All
: high major
Assigned To: Intel 3D Bugs Mailing List
:
: 18262 50873 (view as bug list)
Depends on:
Blocks: 18262
  Show dependency treegraph
 
Reported: 2011-10-12 17:20 UTC by cc
Modified: 2015-08-31 18:33 UTC (History)
9 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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:        2.6.31.12
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-1.13.2.902
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.