[Mesa-dev] [Bug 88354] glXSwapBuffers() can cause BadMatch or lock X when performed repeatedly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=88354

GitLab Migration User  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|NEEDINFO|RESOLVED

--- Comment #4 from GitLab Migration User  ---
-- 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/97.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 88354] glXSwapBuffers() can cause BadMatch or lock X when performed repeatedly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=88354

Eero Tamminen  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #3 from Eero Tamminen  ---
On SKL with Ubuntu 16.04, using latest Mesa from Git everything seems to work
fine, same with older Mesa 11.2 coming with Ubuntu.  No crashes / locks either
with Intel DDX or modesetting, with DRI3 or DRI2.

I would think that the issue is either fixed in Mesa, or culprit is something
else than Mesa. Can you try newer Mesa, and if that doesn't help, newer Intel
DDX version?


Btw. your test program shows interesting difference between DRI3 & DRI2.

I increased the test loop count a bit.  With Intel XX / DRI2, test goes through
10 000 rounds "instantly".

With DRI3, it takes 5-10x longer, and perf says following of the Xorg 100% CPU
usage:
-
23.83%  Xorg Xorg  [.] SyncAddTriggerToSyncObject  
18.20%  Xorg intel_drv.so  [.] 0x0010a5e5  
16.83%  Xorg Xorg  [.] TimerSet
16.49%  Xorg Xorg  [.] present_pixmap  
14.41%  Xorg Xorg  [.] present_event_notify
 7.96%  Xorg Xorg  [.] SyncDeleteTriggerFromSyncObject 
...
-


With modesetting instead of Intel DDX:
- test takes even longer and seems to be limited to 60 FPS
- with DRI2, CPU usage is ~1% (LIBGL_DRI3_DISABLE=1 Mesa option)
- with DRI3, CPU usage is 100%
-
Overview:
 98.99% Xorg
 80.49% [kernel.kallsyms]
  6.66% [unknown]  (I think this is on kernel side also)
  5.12% [vdso]
  3.99% modesetting_drv.so
  1.68% libc-2.23.so
  1.64% libdrm.so.2.4.0

Details:
 16.55%  Xorg   [kernel.kallsyms][k] copy_user_enhanced_fast_string   
  9.27%  Xorg   [kernel.kallsyms][k] do_sys_poll  
  8.13%  Xorg   [kernel.kallsyms][.] entry_SYSCALL_64_fastpath   
  5.43%  Xorg   [kernel.kallsyms][k] _raw_spin_unlock_irqrestore 
  4.51%  Xorg   [kernel.kallsyms][k] entry_SYSCALL_64_after_swapgs
  4.44%  Xorg   [kernel.kallsyms][k] _raw_spin_lock_irqsave 
  4.20%  Xorg   [kernel.kallsyms][k] kfree   
  3.79%  Xorg   [kernel.kallsyms][k] drm_ioctl
  3.48%  Xorg   [kernel.kallsyms][k] drm_wait_vblank   
  3.44%  Xorg   [kernel.kallsyms][k] kmem_cache_alloc_trace
-

In general, with DRI3, first (few thousand) swaps go faster than the later
ones.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 88354] glXSwapBuffers() can cause BadMatch or lock X when performed repeatedly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=88354

--- Comment #2 from Seán de Búrca leftmost...@gmail.com ---
I believe I'm using DRI2. My Xorg logs contain the following:

(II) GLX: Initialized DRI2 GL provider for screen 0

If this may be incorrect, please let me know. I am using xorg-server 1.16.2.901
and X Intel driver 2.99.916.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 88354] glXSwapBuffers() can cause BadMatch or lock X when performed repeatedly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=88354

Eero Tamminen eero.t.tammi...@intel.com changed:

   What|Removed |Added

 CC||eero.t.tammi...@intel.com

--- Comment #1 from Eero Tamminen eero.t.tammi...@intel.com ---
What about the X server and X intel driver versions?

Are you using DRI2 or DRI3?  If latter, can you reproduce the issue also with
DRI2?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 88354] glXSwapBuffers() can cause BadMatch or lock X when performed repeatedly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=88354

Bug ID: 88354
   Summary: glXSwapBuffers() can cause BadMatch or lock X when
performed repeatedly
   Product: Mesa
   Version: 10.4
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: GLX
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: leftmost...@gmail.com

Created attachment 112152
  -- https://bugs.freedesktop.org/attachment.cgi?id=112152action=edit
Test program demonstrating crash/lock

When running a simple program to test window and GL context creation, I
experience program crashes or X lockups when the main loop calls
glXSwapBuffers() too rapidly. When the swap interval is not set, this appears
to always cause X to lock, with only the mouse responding. (n.b. When
attempting to drag windows, the cursor changes appropriately but the windows do
not respond.) If glXSwapIntervalMESA(1) is called, this occasionally merely
results in a program crash after some number of loops. In both cases, the
following error appears in the output and the program stops execution:

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  147 ()
  Minor opcode of failed request:  1
  Serial number of failed request:  163
  Current serial number in output stream:  1034

After the end of execution, if X is locked, it remains locked until restarted.
Putting a one second delay into the main loop prevents the crash and programs
using GLX while rendering real results have not yet elicited any crashes,
suggesting this is a race condition somewhere. The test program I am using to
reproduce this is attached.

I am using mesa 10.4.1 with the i965 drivers on an Intel HD 3000 with kernel
3.17.8. All packages are from the Fedora 21 repositories.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev