System Environment: -------------------------- --Platform:965 --Architecture(32-bit,64-bit,compatiblity):32bit & 64bit --2D driver:master 645980596450ed21c3b8927410a6bfe38a0c55d1 --3D driver:master c98642169496cfa7d8026dbd5214fafbde962002 --DRM:master b0817a42e789a83454e6acba0578116829e2bf51 --Xserver:master 4217ba0cf0c9bbea3774760e836ab372acf3237c --Kernel:2.6.24 Bug detailed description: -------------------------- startx, run glthreads -n 10 ,run failed ,draw nothing . Reproduce steps: ---------------- 1.startx 2../glthreads -n 10 Current result: ---------------- draw nothing Expected result: ---------------- run normally
Created attachment 15439 [details] Xorg.0.log
Is it i915 or I965? glthreads -n 10 runs well here can you try glthreads -n 2?
this case run failed on both 965 & 915, but if I run ./glthreads -n 2 ,it can run normally .
It seems like a X server issue, all thread is waiting for _XReply. Could you roll back the xserver a little bit, i.e. 1 week before to see if this issue still happen?
I have rolled back and retested it , this bug still can be reproduced .
It seems threads has some synchoronize issue with xcb. Can you try build the X server without xcb to see if the issue still exist?
we always build xserver without xcb .
Use -l option which hold mutex around xlib call will make the issue disappear, and you will also see the issue with software rendering. So it should be a GLX issue.
There's nothing xcb-related in the x server. Perhaps you meant xlib?
Using the master tip , this bug can't be reproduced again. verified .
Mass version move, cvs -> git
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.