Current tinderbox regression (trapproto)
http://tinderbox.x.org/builds/2008-10-25-0023/ http://tinderbox.x.org/builds/2008-10-25-0023/logs/libXTrap/#build /home/cjb/xorg-build/include/X11/extensions/xtraplibp.h:106: error: expected ')' before '*' token This is caused by the commit below: http://gitweb.freedesktop.org/?p=xorg/proto/trapproto.git;a=commit;h=9ccbd8597a74a84931a4f931ce5da7f1aa9717cb -- Chris Ball <[EMAIL PROTECTED]> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
i915.ko needs unknown symbol drm_vbl_send_signals
Compiling drm from git ( git clone git://anongit.freedesktop.org/git/mesa/drm ) I got this message when depmod symbols kernel anything I am missing ? thanks -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
On Sat, Oct 25, 2008 at 01:42:31PM +0100, Colin Guthrie wrote: > Well they didn't appear to come up I'll have a look and see if I can > get more info. Not being able to log in to debug it due to lack of > keyboard meant I didn't really research/probe as much as I should have > done... :) lshal | grep evdev should show a number of lines with input.x11_driver = evdev. These devices should all be added to the server. If they aren't there's a bug somewhere in the server. Does it work w/o any xorg.conf? Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Lockup on intel dri
Colin Guthrie wrote:
OK, got a good 'un. Hopefully this is understandable. Please let me know
if you prefer to do this via BZ. I'm happy either way as I read this
list quite often.
I realised it may be useful to see the backtrace for compiz too... Not
sure if it's relevant or not.
But both traces are in the attached. Compiz shows stuff related to xcb.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x7ff6a7d96694 in __lll_lock_wait () from /lib64/libpthread.so.0
(gdb) bt
#0 0x7ff6a7d96694 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x7ff6a7d91f34 in _L_lock_100 () from /lib64/libpthread.so.0
#2 0x7ff6a7d91941 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x7ff6a4d35664 in dri_fake_bo_exec (bo=0x937a4a0, used=1208,
cliprects=0x1348a30, num_cliprects=1, DR4=0) at intel_bufmgr_fake.c:1060
#4 0x7ff693e2ed1f in _intel_batchbuffer_flush (batch=0x193e640,
file=, line=) at
intel_batchbuffer.c:152
#5 0x7ff693e42812 in i915_emit_state (intel=0x13ce960) at i915_vtbl.c:345
#6 0x7ff693e56ef1 in intelRenderStart (ctx=0x13ce960) at intel_tris.c:998
#7 0x7ff693af6370 in run_render (ctx=0x11fc5c0, stage=0x80) at
tnl/t_vb_render.c:275
#8 0x7ff693aed374 in _tnl_run_pipeline (ctx=0x13ce960) at
tnl/t_pipeline.c:158
#9 0x7ff693e60810 in intelRunPipeline (ctx=0x13ce960) at intel_tris.c:987
#10 0x7ff693aedef9 in _tnl_draw_prims (ctx=0x13ce960, arrays=, prim=0x7fffb05c63f0, nr_prims=1, ib=0x0, min_index=0,
max_index=3) at tnl/t_draw.c:402
#11 0x7ff693ae52a9 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at
vbo/vbo_exec_array.c:267
#12 0x7ff6a582281d in ?? () from
/usr/lib64/xorg/modules/extensions//libglx.so
#13 0x7ff6a581ccb6 in ?? () from
/usr/lib64/xorg/modules/extensions//libglx.so
#14 0x7ff6a5820e32 in ?? () from
/usr/lib64/xorg/modules/extensions//libglx.so
#15 0x00447464 in Dispatch () at dispatch.c:454
#16 0x0042d64d in main (argc=10, argv=0x7fffb05c66d8, envp=) at main.c:441
(gdb) bt full
#0 0x7ff6a7d96694 in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x7ff6a7d91f34 in _L_lock_100 () from /lib64/libpthread.so.0
No symbol table info available.
#2 0x7ff6a7d91941 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x7ff6a4d35664 in dri_fake_bo_exec (bo=0x937a4a0, used=1208,
cliprects=0x1348a30, num_cliprects=1, DR4=0) at intel_bufmgr_fake.c:1060
bufmgr_fake = (dri_bufmgr_fake *) 0x11fc530
batch = {start = 18859456, used = 0, DR1 = 154641568, DR4 = 0,
num_cliprects = 18859456, cliprects = 0x13ce960}
ret = -1
retry_count = 0
__PRETTY_FUNCTION__ = "dri_fake_bo_exec"
#4 0x7ff693e2ed1f in _intel_batchbuffer_flush (batch=0x193e640,
file=, line=) at
intel_batchbuffer.c:152
intel = (struct intel_context *) 0x13ce960
used = 1208
was_locked = 0 '\0'
#5 0x7ff693e42812 in i915_emit_state (intel=0x13ce960) at i915_vtbl.c:345
i915 = (struct i915_context *) 0x13ce960
state = (struct i915_hw_state *) 0x13e3470
i =
count = 0
aper_count = 1
dirty =
aper_array = {0x937a4a0, 0x38ad8d0, 0x1, 0x15e42e0, 0x40,
0x3f80015bf290, 0x100010, 0x15fd5a0, 0x3f80015bfa08,
0x3f74f95a3f74f95a, 0x3f5b5fc03f74f95a}
__FUNCTION__ = "i915_emit_state"
#6 0x7ff693e56ef1 in intelRenderStart (ctx=0x13ce960) at intel_tris.c:998
No locals.
#7 0x7ff693af6370 in run_render (ctx=0x11fc5c0, stage=0x80) at
tnl/t_vb_render.c:275
tnl = (TNLcontext *) 0x15bf290
tab =
pass =
#8 0x7ff693aed374 in _tnl_run_pipeline (ctx=0x13ce960) at
tnl/t_pipeline.c:158
tnl = (TNLcontext *) 0x15bf290
i = 10
#9 0x7ff693e60810 in intelRunPipeline (ctx=0x13ce960) at intel_tris.c:987
intel = (struct intel_context *) 0x13ce960
#10 0x7ff693aedef9 in _tnl_draw_prims (ctx=0x13ce960, arrays=, prim=0x7fffb05c63f0, nr_prims=1, ib=0x0, min_index=0,
max_index=3) at tnl/t_draw.c:402
bo = {0x0, 0x4e20, 0x7fffb05c63f0, 0x4e45d5, 0x0, 0x7fffb05c62f0,
0x42c8, 0xb91f1976b800, 0x0, 0x3ff0, 0x0, 0x0,
0x3c91a62633145c07, 0x7ff6a6c9d240, 0x0, 0x43380001,
0x3ff921fb54442d18, 0x0, 0x3c91a62633145c07, 0x7ff693ae0727, 0x1642100,
0x7ff693ae0479, 0x0, 0x13ce960, 0x13ce960, 0x7ff693e393da, 0x13ce960,
0x13ce960, 0x400020,
0x7ff693aad1e0, 0x13ce960, 0x4, 0x0}
nr_bo = 0
tnl = (TNLcontext *) 0x15bf290
#11 0x7ff693ae52a9 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at
vbo/vbo_exec_arra
makekeys [was: Re: Current tinderbox regression (libX11)]
So, the issue is that best_z is initialized to 0 but only updated if: max_rehash < MIN_REHASH && max_rehash < best_max_rehash If that does not happen before z hist KTNUM the loop falls through and z gets set to 0 in the line 'z = best_z;'. One possiblity would be to just error out after next1: if best_z is still 0 with a message that KTNUM needs to be increased. Or, not constrain z to be less than KTNUM and use something like: z < KTNUM : z ? KTNUM-1 where it gets used as an array index. That would include setting the initial value of i in the loop which NULLs the end of the name array and the j in tab[j]. Or a complete rewrite of the optimal hash algorithm. :) OTOH, it may be the case that KTNUM can safely be made large enough to guarentee a solution. WIth 32 bit ints and 32 bit struct memeber alignment the KTNUM-dependent arrays in makekeys need 136*KTNUM octets of VM. So the current setting uses about half a meg of VM. With 64bit pointers that is just under one meg. Even doubling KTNUM would only be a hardship for those compiling on (not just for) archaic or embedded boxen. I'm leaning towards an informative error message and future increments of KTNUM as needed to find a happy hash value. Comments? Incidently, with the current keysyms it would have been sufficient to increase KTNUM to 3200 since it tests up to 3193 and then chooses 3079 as the best option. But I left it at $(primes 4096|tail -1) (having chosen a prime for no good reason :) to future proof it. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Lockup on intel dri
Colin Guthrie wrote:
Eric Anholt wrote:
Could you get a gdb backtrace?
Hmm it seems that whenever the machine is locked up and I attach gdb to
the process it just prints:
"Redelivering pending alarm clock"
And then gdb freeze :s
I've attached gdb to X process before the lockup this time and will see
what happens when it next occurs.
OK, got a good 'un. Hopefully this is understandable. Please let me know
if you prefer to do this via BZ. I'm happy either way as I read this
list quite often.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x7ff123d7b694 in __lll_lock_wait () from /lib64/libpthread.so.0
(gdb) info threads
* 1 Thread 0x7ff12455d6f0 (LWP 22427) 0x7ff123d7b694 in __lll_lock_wait ()
from /lib64/libpthread.so.0
(gdb) bt
#0 0x7ff123d7b694 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x7ff123d76f34 in _L_lock_100 () from /lib64/libpthread.so.0
#2 0x7ff123d76941 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x7ff120d1a664 in dri_fake_bo_exec (bo=0x2e853c0, used=1304,
cliprects=0x1799210, num_cliprects=1, DR4=0) at intel_bufmgr_fake.c:1060
#4 0x7ff10fe13d1f in _intel_batchbuffer_flush (batch=0x1ec1ec0,
file=, line=) at
intel_batchbuffer.c:152
#5 0x7ff10fe27812 in i915_emit_state (intel=0x1952a20) at i915_vtbl.c:345
#6 0x7ff10fe3bef1 in intelRenderStart (ctx=0x1952a20) at intel_tris.c:998
#7 0x7ff10fadb370 in run_render (ctx=0x17805c0, stage=0x80) at
tnl/t_vb_render.c:275
#8 0x7ff10fad2374 in _tnl_run_pipeline (ctx=0x1952a20) at
tnl/t_pipeline.c:158
#9 0x7ff10fe45810 in intelRunPipeline (ctx=0x1952a20) at intel_tris.c:987
#10 0x7ff10fad2ef9 in _tnl_draw_prims (ctx=0x1952a20, arrays=, prim=0x7fff2c5ab3e0, nr_prims=1, ib=0x0, min_index=0,
max_index=3) at tnl/t_draw.c:402
#11 0x7ff10faca2a9 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at
vbo/vbo_exec_array.c:267
#12 0x7ff12180781d in ?? () from
/usr/lib64/xorg/modules/extensions//libglx.so
#13 0x7ff121801cb6 in ?? () from
/usr/lib64/xorg/modules/extensions//libglx.so
#14 0x7ff121805e32 in ?? () from
/usr/lib64/xorg/modules/extensions//libglx.so
#15 0x00447464 in Dispatch () at dispatch.c:454
#16 0x0042d64d in main (argc=10, argv=0x7fff2c5ab6c8, envp=) at main.c:441
(gdb) bt full
#0 0x7ff123d7b694 in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x7ff123d76f34 in _L_lock_100 () from /lib64/libpthread.so.0
No symbol table info available.
#2 0x7ff123d76941 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x7ff120d1a664 in dri_fake_bo_exec (bo=0x2e853c0, used=1304,
cliprects=0x1799210, num_cliprects=1, DR4=0) at intel_bufmgr_fake.c:1060
bufmgr_fake = (dri_bufmgr_fake *) 0x1780530
batch = {start = 24643008, used = 0, DR1 = 48780224, DR4 = 0,
num_cliprects = 24643008, cliprects = 0x1952a20}
ret = -1
retry_count = 0
__PRETTY_FUNCTION__ = "dri_fake_bo_exec"
#4 0x7ff10fe13d1f in _intel_batchbuffer_flush (batch=0x1ec1ec0,
file=, line=) at
intel_batchbuffer.c:152
intel = (struct intel_context *) 0x1952a20
used = 1304
was_locked = 0 '\0'
#5 0x7ff10fe27812 in i915_emit_state (intel=0x1952a20) at i915_vtbl.c:345
i915 = (struct i915_context *) 0x1952a20
state = (struct i915_hw_state *) 0x1967530
i =
count = 0
aper_count = 1
dirty =
aper_array = {0x2e853c0, 0x17f6be0, 0x1, 0x1952a20, 0x179efe0,
0xfff0, 0x1952a20, 0x12, 0x904480, 0x7ff10fe24473, 0x3f64ee6f3f7e8809}
__FUNCTION__ = "i915_emit_state"
#6 0x7ff10fe3bef1 in intelRenderStart (ctx=0x1952a20) at intel_tris.c:998
No locals.
#7 0x7ff10fadb370 in run_render (ctx=0x17805c0, stage=0x80) at
tnl/t_vb_render.c:275
tnl = (TNLcontext *) 0x1b42b10
tab =
pass =
#8 0x7ff10fad2374 in _tnl_run_pipeline (ctx=0x1952a20) at
tnl/t_pipeline.c:158
tnl = (TNLcontext *) 0x1b42b10
i = 10
#9 0x7ff10fe45810 in intelRunPipeline (ctx=0x1952a20) at intel_tris.c:987
intel = (struct intel_context *) 0x1952a20
#10 0x7ff10fad2ef9 in _tnl_draw_prims (ctx=0x1952a20, arrays=, prim=0x7fff2c5ab3e0, nr_prims=1, ib=0x0, min_index=0,
max_index=3) at tnl/t_draw.c:402
bo = {0x0, 0x0, 0x0, 0x0, 0x0, 0x7fff2c5ab2e0, 0x7fff2c5ab360,
0x7fff2c5ab4f8, 0x7fff2c5ab4e0, 0x7fff2c5ab460, 0x1902710, 0xff0a,
0x0, 0x195dcf0, 0x2e85d80, 0x7ff10faabf26, 0x1952a20, 0x2, 0x195dcf0,
0x7ff10fac5727, 0x1bc59e0, 0x7ff10fac5479, 0x0, 0x1952a20, 0x1952a20,
0x7ff10fe1e3da, 0x179efe0,
Re: Current tinderbox regression (libX11)
[Grrr. Forgot to CC the list -JimC] > "Chris" == Chris Ball <[EMAIL PROTECTED]> writes: Chris> http://tinderbox.x.org/builds/2008-10-25-0007/ Chris> http://tinderbox.x.org/builds/2008-10-25-0007/logs/libX11/#build Chris> /bin/sh: line 1: 17581 Segmentation fault ../src/util/makekeys < Chris> /home/cjb/xorg-build/include/X11/keysymdef.h > ks_tables_h I got a divide-by-zero error instead of a segv; assuming it is due to the same bug, I just pushed a work-around: commit b1022fa6d7e97640049e93ffa108083fc8d71b05 Author: James Cloos <[EMAIL PROTECTED]> Date: Sat Oct 25 09:12:45 2008 -0400 Increase size of working arrays in the makekeys utility program. Makekeys is used to create an optimal hash of the keysyms defined in x11proto’s keysymdef.h. The recent addition of new keysyms there has triggered a bug in makekeys where it tries to use a zero on the rhs of the % (mod) operator (resulting in a divide by zero error) whenever it fails to find a solution within its constraints. Increasing the size of the arrays allows it to find a solution for the current set of keysyms. Makekeys is only run durring the build process, so this has no impact on users of libX11, only on the amount of VM needed to build it. It still needs a more complete fix, but this allows compiles to progress until that is completed. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Lockup on intel dri
Eric Anholt wrote: > Could you get a gdb backtrace? Hmm it seems that whenever the machine is locked up and I attach gdb to the process it just prints: "Redelivering pending alarm clock" And then gdb freeze :s I've attached gdb to X process before the lockup this time and will see what happens when it next occurs. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: donation 2x radeonhd ati pci-e HD3450 LP for europian xorg developer
Tiago Vignatti wrote: > Hi Jelle, > > Jelle de Jong escreveu: >> I recently bought two cub 3d hd3450 ati radeonhd 16x pci-e devices for >> an multigpu muliseat setup. However currently the radeonhd does not >> support this. It does not want to setup the second card I tried both the >> randr 1.2 as the official xorg configuration styles. I posted logs on >> the radeonhd mailinglist, but multigpu support does not seem to be an >> development priority. So I was forced to buy nvidea cards and install >> nvidia kernel crap to get my systems working like I needed. > > yeah, seems that the closed drivers all do ASIC init themselves. So it's > a win for them while our server doesn't have a method to post secondaries. > > >> Now I got two spare devices, that I can either return to the shop or >> donate to an European developer. The only thing I would like in return >> is to get personal emails about the status of the multigpu/multicpu >> support and that it will be working in 6 months. If that is unreasonable >> we can workout something else. I do need to know what to do in a short >> time because of guarantee issues on the devices. > > Thanks for the offer (though I'm from south america). I cannot accept > this right now because I'm already busy with all my hackish volunteering > stuffs. Why don't you adventure and try it yourself? It's a good time :) > > > Thank you, > Thank you Tiago for responding. To the subject of trying to fix the multi GPU issues on the driver by myself. I would probably have the skills to do this, however I always have a lot of trouble getting familiar with the code structures of free software projects, without documentation how the code is constructed and why it is done that way, I have to spent an awful lot of time and energy reading en testing source code to get familiar with the project. This process is always getting to my nerves and personal health by all the "why" and "how" questions popping up in my head. Maybe this will change in the future, lets hope so, but for now I rather leave the development to people already gone through the process of getting to know the code structure. Best regards, Jelle ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Lockup on intel dri
Eric Anholt wrote: > On Fri, 2008-10-24 at 10:55 +0100, Colin Guthrie wrote: >> Hi, >> >> I'm wondering if anyone can advice of how to address this lockup? >> >> I'm running mesa master from a couple days ago + a few minor patches >> (quite similar to the Fedora dev package) + xserver 1.5.2 + patches >> (very similar to the Fedora dev package - I also cherry picked the dix >> backtrace stuff too). I'm using intel 2.5.0. >> >> I'm getting the >> [mi] mieqEnequeue: out-of-order valuator event; dropping. >> [mi] EQ overflowing. The server is probably stuck in an infinite loop. >> error but I know that's somewhat misleading. >> >> As I have the backtrace cherry-picks from master the following was >> dumped into my log. >> [mi] EQ overflowing. The server is probably stuck in an infinite loop. >> Backtrace: >> 0: /etc/X11/X(xorg_backtrace+0x26) [0x4e6d56] >> 1: /etc/X11/X(mieqEnqueue+0x291) [0x4c75d1] >> 2: /etc/X11/X(xf86PostMotionEventP+0xc4) [0x4831d4] >> 3: /etc/X11/X(xf86PostMotionEvent+0xb1) [0x4833b1] >> 4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7f67798bbf46] >> 5: /etc/X11/X [0x484115] >> 6: /etc/X11/X [0x4671d7] >> 7: /lib64/libpthread.so.0 [0x7f677cf38d20] >> 8: /lib64/libpthread.so.0 [0x7f677cf37694] >> 9: /lib64/libpthread.so.0 [0x7f677cf32f34] >> 10: /lib64/libpthread.so.0(pthread_mutex_lock+0x71) [0x7f677cf32941] >> 11: /usr/lib64/libdrm_intel.so.1 [0x7f6779ed6664] >> 12: /usr/lib64/dri/i915_dri.so(_intel_batchbuffer_flush+0x186) >> [0x7f6768dc9d1f] >> 13: /usr/lib64/dri/i915_dri.so(intelFlush+0xe9) [0x7f6768dde202] >> 14: /usr/lib64/libdricore.so(_mesa_Flush+0x64) [0x7f67689e158c] >> 15: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f677a9c5a9b] >> 16: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f677a9c1e32] >> 17: /etc/X11/X(Dispatch+0x364) [0x447464] >> 18: /etc/X11/X(main+0x45d) [0x42d64d] >> 19: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f677b8d8316] >> 20: /etc/X11/X(FontFileCompleteXLFD+0x279) [0x42ca29] >> >> >> I don't have anything special in my kernel and I'm not using GEM. My h/w >> is i945GM. >> >> The above was with an older evdev, but (as it was mentioned, I upgraded >> to 2.0.99.2 and got the following (similar output): >> [mi] EQ overflowing. The server is probably stuck in an infinite loop. >> Backtrace: >> 0: /etc/X11/X(xorg_backtrace+0x26) [0x4e6d56] >> 1: /etc/X11/X(mieqEnqueue+0x291) [0x4c75d1] >> 2: /etc/X11/X(xf86PostMotionEventP+0xc4) [0x4831d4] >> 3: /etc/X11/X(xf86PostMotionEvent+0xb1) [0x4833b1] >> 4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7f48dc25d1a7] >> 5: /etc/X11/X [0x484115] >> 6: /etc/X11/X [0x4671d7] >> 7: /lib64/libpthread.so.0 [0x7f48df8dad20] >> 8: /lib64/libpthread.so.0 [0x7f48df8d9694] >> 9: /lib64/libpthread.so.0 [0x7f48df8d4f34] >> 10: /lib64/libpthread.so.0(pthread_mutex_lock+0x71) [0x7f48df8d4941] >> 11: /usr/lib64/libdrm_intel.so.1 [0x7f48dc878664] >> 12: /usr/lib64/dri/i915_dri.so(_intel_batchbuffer_flush+0x186) >> [0x7f48cb76ad1f] >> 13: /usr/lib64/dri/i915_dri.so(intelFlush+0xe9) [0x7f48cb77f202] >> 14: /usr/lib64/dri/i915_dri.so [0x7f48cb76c7ba] >> 15: /usr/lib64/dri/i915_dri.so(intelTexImage2D+0x7d) [0x7f48cb76d4f3] >> 16: /usr/lib64/libdricore.so(_mesa_TexImage2D+0x2a9) [0x7f48cb3fdc71] >> 17: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd36d933] >> 18: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd360a87] >> 19: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd35fa42] >> 20: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd363e32] >> 21: /etc/X11/X(Dispatch+0x364) [0x447464] >> 22: /etc/X11/X(main+0x45d) [0x42d64d] >> 23: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f48de27a316] >> 24: /etc/X11/X(FontFileCompleteXLFD+0x279) [0x42ca29] >> >> >> (evdev itself did odd things but that's another story!) >> >> >> Any ideas? > > So, it looks like somebody leaked the lock in libdrm, or we're > attempting to double-lock it. The second seems unlikely since we > batchbuffer_flush so regularly, but it's hard to say. Could you get a > gdb backtrace? A lot of information is missing in server backtraces. > Also, does whatever app you're running that causes this failure run in > direct rendering mode? That may make it easier to get a decent > backtrace. I'll double check to see if there are any weird patches we apply that could cause this. Well it's generally triggered when "using" the desktop. As I am running compiz I'm tagging it as the app that triggers it and it does indeed run in direct rendering mode AFAIK. I'll see if I can get a gdb backtrace, but it's tricky at home as I only have one sensible machine here so sshing in to get the backtrace is tricky (can be done with a bit of jiggery pokery on my headless machine + a telly!) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/]
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
Peter Hutterer wrote: > On Fri, Oct 24, 2008 at 04:26:39PM +0100, Colin Guthrie wrote: >> Thanks for the info Peter. I did actually have the patch below already >> applied but had to turn AEI off to get keyboard support at KDM login. > > why is that? Shouldn't you get the devices anyway? > putting evdev devices in your xorg.conf is discouraged, to say the very least. Well they didn't appear to come up I'll have a look and see if I can get more info. Not being able to log in to debug it due to lack of keyboard meant I didn't really research/probe as much as I should have done... :) I guess I'll have to see why evdev is not loaded (and/or just doesn't work at login!). I had previously thought that it needed an entry in xorg.conf with an "auto" device or something but I can tell from your response this is bunkum! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
