Menu
▾
▴
mesa3d-dev
|
From: Stephan R. <mai...@op...> - 2010-03-02 13:10:14
|
Hi all,
i have problems running an Application that depends on Mesa. It seems
there is an loop after starting this App and before the GUI loads. I use
- xorg-server-1.8 git from 28.02.2010
- Mesa-7.8 git from 28.02.2010
- xf86-video-intel-2.10.901
- linux-2.6.33
- libdrm git from 28.02.2010
glxgears, an windowmanager and mrxvt as terminal works. can anyone see
where is my problem?
GDB output:
Thread 1 (Thread 0xb5cc7720 (LWP 587)):
#0 0xb7806424 in __kernel_vsyscall ()
#1 0xb5e47fb6 in *__GI___poll (fds=0xb5ec7ff4, nfds=1, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:87
#2 0xb5d5d268 in _xcb_conn_wait (c=0x9571ca0, cond=0xbf9dbbe0,
vector=0x0, count=0x0) at xcb_conn.c:306
#3 0xb5d5ee09 in xcb_wait_for_reply (c=0x9571ca0, request=30,
e=0xbf9dbc6c) at xcb_in.c:390
#4 0xb6283b06 in _XReply (dpy=0x9571358, rep=0xbf9dbcdc, extra=0,
discard=0) at xcb_io.c:461
#5 0xb6c27edf in DRI2GetBuffersWithFormat (dpy=0x9571358,
drawable=2097167, width=0x9c2b0b4, height=0x9c2b0b8,
attachments=0xbf9dbdfc, count=2,
outCount=0xbf9dbe28) at dri2.c:428
#6 0xb6c25ae3 in dri2GetBuffersWithFormat (driDrawable=0x9c2b090,
width=0x9c2b0b4, height=0x9c2b0b8, attachments=0xbf9dbdfc, count=2,
out_count=0xbf9dbe28,
loaderPrivate=0x9c2aff0) at dri2_glx.c:435
#7 0xb592db79 in intel_update_renderbuffers (context=0x95cc468,
drawable=0x9c2b090) at intel_context.c:253
#8 0xb592e1a6 in intel_prepare_render (intel=0x98e6640) at
intel_context.c:395
#9 0xb5929451 in intelClearWithBlit (ctx=0x98e6640, mask=<value
optimized out>) at intel_blit.c:253
#10 0xb592bc92 in intelClear (ctx=0x98e6640, mask=2) at intel_clear.c:169
#11 0xb59cc999 in _mesa_Clear (mask=0) at main/clear.c:183
#12 0xb6c3accb in glClear (mask=16384) at
../../src/mesa/glapi/glapitemp.h:1102
#13 0x085de6f4 in CRenderSystemGL::ClearBuffers (this=0x8c09b1c, r=0,
g=0, b=0, a=0) at RenderSystemGL.cpp:196
#14 0x086714f4 in CGraphicContext::Clear (this=0x8c0a340) at
GraphicContext.cpp:515
#15 0x0831c58c in CApplication::RenderNoPresent (this=0x8c070a0) at
Application.cpp:2007
#16 0x0830ef80 in CApplication::Render (this=0x8c070a0) at
Application.cpp:2202
#17 0x0869f704 in CGUIDialog::DoModal_Internal (this=0xb2e6aa80,
iWindowID=9999, param=...) at GUIDialog.cpp:171
#18 0x0855d38e in CApplicationMessenger::ProcessMessage (this=0x8c07cc4,
pMsg=0xbf9dc6fc) at ApplicationMessenger.cpp:512
#19 0x0855e46f in CApplicationMessenger::SendMessage (this=0x8c07cc4,
message=..., wait=true) at ApplicationMessenger.cpp:98
#20 0x0855e95c in CApplicationMessenger::DoModal (this=0x8c07cc4,
pDialog=0xb2e6aa80, iWindowID=9999, param=...) at
ApplicationMessenger.cpp:818
#21 0x0869f28f in CGUIDialog::DoModal (this=0xb2e6aa80, iWindowID=9999,
param=...) at GUIDialog.cpp:219
#22 0x0855ceee in CApplicationMessenger::ProcessMessage (this=0x8c07cc4,
pMsg=0x9742938) at ApplicationMessenger.cpp:488
#23 0x0855f989 in CApplicationMessenger::ProcessWindowMessages
(this=0x8c07cc4) at ApplicationMessenger.cpp:610
#24 0x083210c3 in CApplication::Process (this=0x8c070a0) at
Application.cpp:4779
#25 0x085779bc in CXBApplicationEx::Run (this=0x8c070a0) at
XBApplicationEx.cpp:89
#26 0x085781fc in main (argc=5, argv=0xbf9dcfb4) at xbmc.cpp:150
A debugging session is active.
Inferior 1 [process 587] will be detached.
greetings
Stephan
--
### OpenELEC.tv ###
The free and open Mediacenter Distribution 4 you
http://www.openelec.tv
|
|
From: Jamey S. <ja...@mi...> - 2010-03-02 18:03:03
|
On Tue, Mar 2, 2010 at 4:37 AM, Stephan Raue <mai...@op...> wrote: > i have problems running an Application that depends on Mesa. It seems there > is an loop after starting this App and before the GUI loads. I use A loop? Or just a hang? > #1 0xb5e47fb6 in *__GI___poll (fds=0xb5ec7ff4, nfds=1, timeout=-1) at > ../sysdeps/unix/sysv/linux/poll.c:87 > #2 0xb5d5d268 in _xcb_conn_wait (c=0x9571ca0, cond=0xbf9dbbe0, vector=0x0, > count=0x0) at xcb_conn.c:306 > #3 0xb5d5ee09 in xcb_wait_for_reply (c=0x9571ca0, request=30, e=0xbf9dbc6c) > at xcb_in.c:390 Judging only by the stack trace, it looks like your application is waiting for a reply that never comes. There are a variety of bugs that can cause that. The sequence number (30) looks reasonable for application startup, which rules out one or two things. For the rest, if the Intel/Mesa folks don't have an answer, it would help if you could get a trace of the X wire protocol using something like Wireshark. Jamey |
|
From: Florian M. <fl...@mi...> - 2010-03-02 19:18:25
|
On Tue, 2 Mar 2010 09:32:57 -0800 Jamey Sharp <ja...@mi...> wrote: > On Tue, Mar 2, 2010 at 4:37 AM, Stephan Raue <mai...@op...> wrote: > > i have problems running an Application that depends on Mesa. It seems there > > is an loop after starting this App and before the GUI loads. I use > > A loop? Or just a hang? > > > #1 0xb5e47fb6 in *__GI___poll (fds=0xb5ec7ff4, nfds=1, timeout=-1) at > > ../sysdeps/unix/sysv/linux/poll.c:87 > > #2 0xb5d5d268 in _xcb_conn_wait (c=0x9571ca0, cond=0xbf9dbbe0, vector=0x0, > > count=0x0) at xcb_conn.c:306 > > #3 0xb5d5ee09 in xcb_wait_for_reply (c=0x9571ca0, request=30, e=0xbf9dbc6c) > > at xcb_in.c:390 > > Judging only by the stack trace, it looks like your application is > waiting for a reply that never comes. There are a variety of bugs that > can cause that. The sequence number (30) looks reasonable for > application startup, which rules out one or two things. > > For the rest, if the Intel/Mesa folks don't have an answer, it would > help if you could get a trace of the X wire protocol using something > like Wireshark. > > Jamey > _______________________________________________ > xorg-devel mailing list > xor...@li... > http://lists.x.org/mailman/listinfo/xorg-devel i'm seeing the same with glxgears, see below for a gdb run... if i login glxgears runs fine, until i start up some programs (licq, psi, twinkle, skype)... then it hangs sometimes and doesnt redraw the screen anymore. if i start it after that point it never draws... seems to me, like some event goes missing somewhere... ? anyway, i'm on amd64 with intel from git, using the new event-driven invalidate stuff... what debugging would be helpful here? dmesg doesn't show anything (abnormal) with kernel drm.debug=1 ... cheers, Flo p.s.: i verified with strace that it hangs on that poll... (gdb) r Starting program: /usr/bin/glxgears [Thread debugging using libthread_db enabled] Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. ^C Program received signal SIGINT, Interrupt. 0x00007ffff766410f in poll () from /lib/libc.so.6 (gdb) bt #0 0x00007ffff766410f in poll () from /lib/libc.so.6 #1 0x00007ffff6219a32 in _xcb_conn_wait () from /usr/lib/libxcb.so.1 #2 0x00007ffff621b5e1 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #3 0x00007ffff72c00be in _XReply () from /usr/lib/libX11.so.6 #4 0x00007ffff7bbe996 in DRI2GetBuffersWithFormat () from //usr/lib64/opengl/xorg-x11/lib/libGL.so.1 #5 0x00007ffff7bbd6c8 in dri2GetBuffersWithFormat () from //usr/lib64/opengl/xorg-x11/lib/libGL.so.1 #6 0x00007ffff5780cef in intel_update_renderbuffers () from /usr/lib64/dri/i965_dri.so #7 0x00007ffff57810b7 in intel_prepare_render () from /usr/lib64/dri/i965_dri.so #8 0x00007ffff57af15a in brw_draw_prims () from /usr/lib64/dri/i965_dri.so #9 0x00007ffff5857383 in vbo_exec_DrawArrays () from /usr/lib64/dri/i965_dri.so #10 0x00007ffff58d2987 in _mesa_meta_Clear () from /usr/lib64/dri/i965_dri.so #11 0x00007ffff577fccb in intelClear () from /usr/lib64/dri/i965_dri.so #12 0x0000000000402be6 in draw () #13 0x000000000040360b in main () (gdb) |
|
From: Jesse B. <jb...@vi...> - 2010-03-02 20:16:55
|
On Tue, 2 Mar 2010 19:50:45 +0100 Florian Mickler <fl...@mi...> wrote: > On Tue, 2 Mar 2010 09:32:57 -0800 > Jamey Sharp <ja...@mi...> wrote: > > > On Tue, Mar 2, 2010 at 4:37 AM, Stephan Raue > > <mai...@op...> wrote: > > > i have problems running an Application that depends on Mesa. It > > > seems there is an loop after starting this App and before the GUI > > > loads. I use > > > > A loop? Or just a hang? > > > > > #1 0xb5e47fb6 in *__GI___poll (fds=0xb5ec7ff4, nfds=1, > > > timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 > > > #2 0xb5d5d268 in _xcb_conn_wait (c=0x9571ca0, cond=0xbf9dbbe0, > > > vector=0x0, count=0x0) at xcb_conn.c:306 > > > #3 0xb5d5ee09 in xcb_wait_for_reply (c=0x9571ca0, request=30, > > > e=0xbf9dbc6c) at xcb_in.c:390 > > > > Judging only by the stack trace, it looks like your application is > > waiting for a reply that never comes. There are a variety of bugs > > that can cause that. The sequence number (30) looks reasonable for > > application startup, which rules out one or two things. > > > > For the rest, if the Intel/Mesa folks don't have an answer, it would > > help if you could get a trace of the X wire protocol using something > > like Wireshark. > > > > Jamey > > _______________________________________________ > > xorg-devel mailing list > > xor...@li... > > http://lists.x.org/mailman/listinfo/xorg-devel > > > > i'm seeing the same with glxgears, see below for a gdb run... > > if i login glxgears runs fine, until i start up some programs (licq, > psi, twinkle, skype)... then it hangs sometimes and doesnt redraw the > screen anymore. if i start it after that point it never draws... > > seems to me, like some event goes missing somewhere... ? > > anyway, i'm on amd64 with intel from git, using the new event-driven > invalidate stuff... > > what debugging would be helpful here? dmesg doesn't show anything > (abnormal) with kernel drm.debug=1 ... > > cheers, > Flo > > p.s.: i verified with strace that it hangs on that poll... So the server is hanging when the client tries to get buffers? Can you see what it's doing at the time? -- Jesse Barnes, Intel Open Source Technology Center |
|
From: Florian M. <fl...@mi...> - 2010-03-02 21:48:52
|
On Tue, 2 Mar 2010 11:50:05 -0800 Jesse Barnes <jb...@vi...> wrote: > So the server is hanging when the client tries to get buffers? Can you > see what it's doing at the time? > i'll try tomorrow... meanwhile, i watched a film and did some other things and now glxgears doesn't start anymore: dmk@schatten ~ $glxgears Mesa: Mesa 7.8-devel DEBUG build Mar 2 2010 19:57:41 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa: Initializing x86-64 optimizations Running synchronized to the vertical refresh. The framerate should be approximately 1/8504368 the monitor refresh rate. X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 133 (DRI2) Minor opcode of failed request: 8 (DRI2SwapBuffers ) Resource id in failed request: 0x1c00002 Serial number of failed request: 32 Current serial number in output stream: 32 does this 1/[bignumber] look alright? maybe that is the culprit... waiting some 10^6 time ... i think the monitor refresh rate is something about 60 hz? not over some khz? which means that 1khz/8504368 is something about 1/8500 hz which amounts to about 140 secs? (it is late and i may have switched nominater and denominator a bit too often... but if i don't have crossed anything, than that could cause some hang... don't it?) cheers, Flo p.s.: my software stack is git master of libdrm, mesa and xf86-video-intel as well as xserver-master + krh's pull request, so that it looks light that: 90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when its buffers become invalid. 68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the DRI2InvalidateBuffers event. 2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front on DRI2GetBuffers if they're just being reused. 543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from the intel DDX. 31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook. de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled compat_output fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for det_monrec_parameter sync_source 4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable in DRI2SwapEvent 780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch 'whot/for-keith' |
|
From: Jesse B. <jb...@vi...> - 2010-03-02 21:59:13
|
On Tue, 2 Mar 2010 22:48:31 +0100
Florian Mickler <fl...@mi...> wrote:
> On Tue, 2 Mar 2010 11:50:05 -0800
> Jesse Barnes <jb...@vi...> wrote:
>
> > So the server is hanging when the client tries to get buffers? Can
> > you see what it's doing at the time?
> >
>
> i'll try tomorrow...
>
> meanwhile, i watched a film and did some other things and now glxgears
> doesn't start anymore:
>
> dmk@schatten ~ $glxgears
> Mesa: Mesa 7.8-devel DEBUG build Mar 2 2010 19:57:41
> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
> compression/decompression unavailable Mesa: Initializing x86-64
> optimizations Running synchronized to the vertical refresh. The
> framerate should be approximately 1/8504368 the monitor refresh rate.
> X Error of failed request: BadDrawable (invalid Pixmap or Window
> parameter) Major opcode of failed request: 133 (DRI2)
> Minor opcode of failed request: 8 (DRI2SwapBuffers )
> Resource id in failed request: 0x1c00002
> Serial number of failed request: 32
> Current serial number in output stream: 32
>
>
> does this 1/[bignumber] look alright? maybe that is the culprit...
> waiting some 10^6 time ... i think the monitor refresh rate is
> something about 60 hz? not over some khz? which means that
> 1khz/8504368 is something about 1/8500 hz which amounts to about 140
> secs? (it is late and i may have switched nominater and denominator a
> bit too often... but if i don't have crossed anything, than that could
> cause some hang... don't it?)
I don't know how gears calculates that these days, but it generally
looks wrong for me too.
You have
commit 529bf185fbcb9f7705b315a5106054ee25c1c77f
Author: Eric Anholt <er...@an...>
Date: Wed Feb 24 17:54:13 2010 -0800
In frame event handling, track drawable id instead of drawable
pointer.
in your xf86-video-intel tree?
--
Jesse Barnes, Intel Open Source Technology Center
|
|
From: Florian M. <fl...@mi...> - 2010-03-03 11:15:06
|
On Tue, 2 Mar 2010 13:59:00 -0800
Jesse Barnes <jb...@vi...> wrote:
> commit 529bf185fbcb9f7705b315a5106054ee25c1c77f
> Author: Eric Anholt <er...@an...>
> Date: Wed Feb 24 17:54:13 2010 -0800
>
> In frame event handling, track drawable id instead of drawable
> pointer.
>
> in your xf86-video-intel tree?
>
yes. before that, glxgears wouldn't ever start ... the error goes away if i restart the xserver...
Am Dienstag, den 02.03.2010, 22:48 +0100 schrieb Florian Mickler:
> On Tue, 2 Mar 2010 11:50:05 -0800
> Jesse Barnes <jb...@vi...> wrote:
>
> > So the server is hanging when the client tries to get buffers? Can you
> > see what it's doing at the time?
> >
>
> i'll try tomorrow...
btw, no. it is glxgears which is hanging. everything else works as it
should.
and it is hanging on this _XReply (@428) here:
@line 428 in mesa/src/glx/dri2.c:
416 XextCheckExtension(dpy, info, dri2ExtensionName, False);
417
418 LockDisplay(dpy);
419 GetReqExtra(DRI2GetBuffers, count * (4 * 2), req);
420 req->reqType = info->codes->major_opcode;
421 req->dri2ReqType = X_DRI2GetBuffersWithFormat;
422 req->drawable = drawable;
423 req->count = count;
424 p = (CARD32 *) & req[1];
425 for (i = 0; i < (count * 2); i++)
426 p[i] = attachments[i];
427
428 if (!_XReply(dpy, (xReply *) & rep, 0, xFalse)) {
429 UnlockDisplay(dpy);
430 SyncHandle();
431 return NULL;
432 }
433
434 *width = rep.width;
435 *height = rep.height;
it's not looping... i verified with strace that glxgears is blocking on
that poll() here...
I tried to follow the program flow up into that.. but besides me
thinking that this _XReply is surfacing in the xserver's dispatch.c
i'm not really advancing here ;) where does this request get handled?
when does _XReply return?
cheers,
Flo
p.s.: if the screen is idle and get's turned off, glxgears is running
fine... (started via ssh... i see the framerate reporting...)
p.p.s.: the whole backtrace when glxgears is hanging:
(gdb) bt full
#0 0x00007f3aef5ea10f in poll () from /lib/libc.so.6
No symbol table info available.
#1 0x00007f3aee19fa32 in _xcb_conn_wait () from /usr/lib/libxcb.so.1
No symbol table info available.
#2 0x00007f3aee1a15e1 in xcb_wait_for_reply ()
from /usr/lib/libxcb.so.1
No symbol table info available.
#3 0x00007f3aef2460be in _XReply () from /usr/lib/libX11.so.6
No symbol table info available.
#4 0x00007f3aefb44f76 in DRI2GetBuffersWithFormat (dpy=0x234c010,
drawable=<value optimized out>, width=0x235f3b4, height=0x235f3b8,
attachments=0x7fffc5ac6450, count=2, outCount=0x7fffc5ac648c) at
dri2.c:428
info = 0x2357960
rep = {type = 112 'p', pad1 = 100 'd', sequenceNumber = 50604,
length = 32767, width = 3984539715, height = 32570, count =
0,
pad2 = 0, pad3 = 37116448, pad4 = 0}
buffers = <value optimized out>
repBuffer = {attachment = 41009200, name = 0, pitch =
3985030468,
cpp = 32570, flags = 2097152}
i = <value optimized out>
#5 0x00007f3aefb43ca8 in dri2GetBuffersWithFormat (
driDrawable=<value optimized out>, width=0x235f3b4,
height=0xffffffffffffffff, attachments=0x234d6d8, count=5277,
out_count=0x7fffc5ac648c, loaderPrivate=0x235f2c0) at dri2_glx.c:435
---Type <return> to continue, or q <return> to quit---
pdraw = <value optimized out>
buffers = <value optimized out>
#6 0x00007f3aed6de927 in intel_update_renderbuffers (
context=<value optimized out>, drawable=0x235f380) at
intel_context.c:252
rb = <value optimized out>
region = <value optimized out>
depth_region = <value optimized out>
intel = 0x2365a20
front_rb = <value optimized out>
back_rb = 0x3
depth_rb = 0x26b9340
stencil_rb = 0x26b9340
buffers = <value optimized out>
screen = 0x235cf20
i = 3
count = <value optimized out>
attachments = {1, 32, 9, 32, 13, 0, 0, 0, 655360, 0}
region_name = <value optimized out>
__func__ = "intel_update_renderbuffers"
#7 0x00007f3aed6decef in intel_prepare_render (intel=0x2365a20)
at intel_context.c:395
driContext = 0x2361d70
drawable = 0x235f380
---Type <return> to continue, or q <return> to quit---
#8 0x00007f3aed70d3ca in brw_try_draw_prims (ctx=0x2365a20,
arrays=0x23b54a8,
prim=0x7fffc5ac65a0, nr_prims=1, ib=0x0,
index_bounds_valid=<value optimized out>, min_index=0, max_index=3)
at brw_draw.c:340
retval = <value optimized out>
warn = <value optimized out>
first_time = <value optimized out>
i = <value optimized out>
intel = 0x7fffc5ac6200
__FUNCTION__ = "brw_try_draw_prims"
warned = 0 '\000'
#9 brw_draw_prims (ctx=0x2365a20, arrays=0x23b54a8,
prim=0x7fffc5ac65a0,
nr_prims=1, ib=0x0, index_bounds_valid=<value optimized out>,
min_index=0,
max_index=3) at brw_draw.c:441
No locals.
#10 0x00007f3aed7c91bf in vbo_exec_DrawArrays (mode=6, start=0, count=4)
at vbo/vbo_exec_array.c:524
ctx = 0x2365a20
prim = {{mode = 6, indexed = 0, begin = 1, end = 1, weak = 0,
pad = 0,
start = 0, count = 4, basevertex = 0}}
__FUNCTION__ = "vbo_exec_DrawArrays"
#11 0x00007f3aed847910 in _mesa_meta_Clear (ctx=0x2365a20, buffers=0)
at drivers/common/meta.c:1461
---Type <return> to continue, or q <return> to quit---
clear = 0x26b47e4
verts = {{x = 0, y = 0, z = -1, r = 0, g = 0, b = 0, a = 0}, {x
= 300,
y = 0, z = -1, r = 0, g = 0, b = 0, a = 0}, {x = 300, y =
300,
z = -1, r = 0, g = 0, b = 0, a = 0}, {x = 0, y = 300, z =
-1,
r = 0, g = 0, b = 0, a = 0}}
metaSave = 4294967003
__PRETTY_FUNCTION__ = "_mesa_meta_Clear"
#12 0x00007f3aed6dd8ac in intelClear (ctx=0x2365a20,
mask=<value optimized out>) at intel_clear.c:182
intel = 0x7fffc5ac6200
colorMask = <value optimized out>
tri_mask = 18
blit_mask = 0
swrast_mask = 0
fb = 0x26b8e20
i = 0
#13 0x0000000000402be6 in draw ()
No symbol table info available.
#14 0x000000000040360b in main ()
No symbol table info available.
|
|
From: Simon T. <sim...@gm...> - 2010-03-03 12:32:10
|
Florian Mickler wrote: > On Tue, 2 Mar 2010 11:50:05 -0800 > Jesse Barnes <jb...@vi...> wrote: > >> So the server is hanging when the client tries to get buffers? Can you >> see what it's doing at the time? >> > > i'll try tomorrow... > > meanwhile, i watched a film and did some other things and now glxgears > doesn't start anymore: > > dmk@schatten ~ $glxgears > Mesa: Mesa 7.8-devel DEBUG build Mar 2 2010 19:57:41 > Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable > Mesa: Initializing x86-64 optimizations > Running synchronized to the vertical refresh. The framerate should be > approximately 1/8504368 the monitor refresh rate. > X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) > Major opcode of failed request: 133 (DRI2) > Minor opcode of failed request: 8 (DRI2SwapBuffers ) > Resource id in failed request: 0x1c00002 > Serial number of failed request: 32 > Current serial number in output stream: 32 > > > does this 1/[bignumber] look alright? maybe that is the culprit... > waiting some 10^6 time ... i think the monitor refresh rate is > something about 60 hz? not over some khz? which means that 1khz/8504368 > is something about 1/8500 hz which amounts to about 140 secs? (it is > late and i may have switched nominater and denominator a bit too > often... but if i don't have crossed anything, than that could > cause some hang... don't it?) FWIW, my glxgears says: The framerate should beapproximately 1/1835103081 the monitor refresh rate. It then runs fine. I'm on radeon r200, but since my update yesterday (git master stack using gentoo overlay) I also have OpenGL problems, most notably, KWin 4.4's compositing doesn't work any more. Probably, this isn't just intel then. My old X did work fine, dating from when the DRI2 Swapbuffers lifetime bugfix hit master (711e26466ae04ae93ff4c48d377d83d68a6320e9). If it helps, I can provide anything that doesn't take me a whole day to gather. > > > cheers, > Flo > > p.s.: my software stack is git master of libdrm, mesa > and xf86-video-intel as well as xserver-master + krh's pull request, so > that it looks light that: > 90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when its buffers become invalid. > 68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the DRI2InvalidateBuffers event. > 2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front on DRI2GetBuffers if they're just being reused. > 543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from the intel DDX. > 31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook. > de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled compat_output > fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for det_monrec_parameter sync_source > 4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable in DRI2SwapEvent > 780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch 'whot/for-keith' > > > _______________________________________________ > xorg-devel mailing list > xor...@li... > http://lists.x.org/mailman/listinfo/xorg-devel > |
|
From: Michel D. <mi...@da...> - 2010-03-03 13:28:44
|
On Wed, 2010-03-03 at 13:31 +0100, Simon Thum wrote: > > It then runs fine. I'm on radeon r200, but since my update yesterday > (git master stack using gentoo overlay) I also have OpenGL problems, > most notably, KWin 4.4's compositing doesn't work any more. Probably, > this isn't just intel then. If your mesa Git checkout doesn't have commit 5f40a7aed12500fd6792e2453f495555c3b5c54d yet, try updating again. Anyway, I think it's unlikely your problem is the same. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer |
|
From: Francisco J. <cur...@ri...> - 2010-03-03 11:30:37
|
Florian Mickler <fl...@mi...> writes: > [...] > p.s.: my software stack is git master of libdrm, mesa > and xf86-video-intel as well as xserver-master + krh's pull request, so > that it looks light that: > 90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when its buffers become invalid. > 68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the DRI2InvalidateBuffers event. > 2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front on DRI2GetBuffers if they're just being reused. > 543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from the intel DDX. > 31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook. > de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled compat_output > fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for det_monrec_parameter sync_source > 4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable in DRI2SwapEvent > 780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch 'whot/for-keith' Is it a side effect of this patch series? Could you try without? |
|
From: Florian M. <fl...@mi...> - 2010-03-03 12:34:28
|
On Wed, 03 Mar 2010 12:31:24 +0100 Francisco Jerez <cur...@ri...> wrote: > Florian Mickler <fl...@mi...> writes: > > > [...] > > p.s.: my software stack is git master of libdrm, mesa > > and xf86-video-intel as well as xserver-master + krh's pull request, so > > that it looks light that: > > 90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when its buffers become invalid. > > 68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the DRI2InvalidateBuffers event. > > 2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front on DRI2GetBuffers if they're just being reused. > > 543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from the intel DDX. > > 31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook. > > de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled compat_output > > fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for det_monrec_parameter sync_source > > 4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable in DRI2SwapEvent > > 780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch 'whot/for-keith' > > Is it a side effect of this patch series? Could you try without? Ah yes. Of course. Should have checked that before... Anyway, I just did, and with current xserver-master it is hanging nontheless... , Flo |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X