From: Adam K K. <ad...@vo...> - 2005-07-27 11:07:12
|
I have an interesting problem with an HP Pavilion. It's an IGP320M with a Radeon Mobility. DRI works just fine when using WindowMaker or gnome. However, when I try to use xfce4 instead, X locks up when the splash screen would normally be displayed. I can move the mouse around, but I can't always control-alt-delete out of it (though sometimes I can... I think the difference may have to do with whether it was the first time X started up since I rebooted). I can ssh into the machine and reboot it. If I disable the DRI, xfce4 has no problems. This is with recent Mesa cvs and drm 1.16.0 (2.6.12.3, specifically, though I've noticed this with each of the 2.6.12 releases.... Can't speak about anything earlier). Any ideas? Thanks, Adam |
From: Adam K K. <ad...@vo...> - 2005-08-08 15:11:27
|
Adam K Kirchhoff wrote: > > I have an interesting problem with an HP Pavilion. It's an IGP320M > with a Radeon Mobility. DRI works just fine when using WindowMaker or > gnome. However, when I try to use xfce4 instead, X locks up when the > splash screen would normally be displayed. I can move the mouse > around, but I can't always control-alt-delete out of it (though > sometimes I can... I think the difference may have to do with whether > it was the first time X started up since I rebooted). I can ssh into > the machine and reboot it. If I disable the DRI, xfce4 has no problems. > > This is with recent Mesa cvs and drm 1.16.0 (2.6.12.3, specifically, > though I've noticed this with each of the 2.6.12 releases.... Can't > speak about anything earlier). > > Any ideas? > > Thanks, > Adam > No one knows what's going on here? Has anyone ever seen this before? Adam |
From: Jerome G. <j.g...@gm...> - 2005-08-08 15:22:45
|
On 8/8/05, Adam K Kirchhoff <ad...@vo...> wrote: > Adam K Kirchhoff wrote: >=20 > > > > I have an interesting problem with an HP Pavilion. It's an IGP320M > > with a Radeon Mobility. DRI works just fine when using WindowMaker or > > gnome. However, when I try to use xfce4 instead, X locks up when the > > splash screen would normally be displayed. I can move the mouse > > around, but I can't always control-alt-delete out of it (though > > sometimes I can... I think the difference may have to do with whether > > it was the first time X started up since I rebooted). I can ssh into > > the machine and reboot it. If I disable the DRI, xfce4 has no problems= . > > > > This is with recent Mesa cvs and drm 1.16.0 (2.6.12.3, specifically, > > though I've noticed this with each of the 2.6.12 releases.... Can't > > speak about anything earlier). > > > > Any ideas? > > > > Thanks, > > Adam > > >=20 > No one knows what's going on here? Has anyone ever seen this before? I don't know much about this, but did you try with lastest xorg cvs, radeon driver and dri changed a bit lattly, maybe it's fixed now... Jerome Glisse |
From: Adam K K. <ad...@vo...> - 2005-08-10 02:58:11
|
Jerome Glisse wrote: >On 8/8/05, Adam K Kirchhoff <ad...@vo...> wrote: > > >>Adam K Kirchhoff wrote: >> >> >> >>>I have an interesting problem with an HP Pavilion. It's an IGP320M >>>with a Radeon Mobility. DRI works just fine when using WindowMaker or >>>gnome. However, when I try to use xfce4 instead, X locks up when the >>>splash screen would normally be displayed. I can move the mouse >>>around, but I can't always control-alt-delete out of it (though >>>sometimes I can... I think the difference may have to do with whether >>>it was the first time X started up since I rebooted). I can ssh into >>>the machine and reboot it. If I disable the DRI, xfce4 has no problems. >>> >>>This is with recent Mesa cvs and drm 1.16.0 (2.6.12.3, specifically, >>>though I've noticed this with each of the 2.6.12 releases.... Can't >>>speak about anything earlier). >>> >>>Any ideas? >>> >>>Thanks, >>>Adam >>> >>> >>> >>No one knows what's going on here? Has anyone ever seen this before? >> >> > >I don't know much about this, but did you try with lastest xorg cvs, >radeon driver >and dri changed a bit lattly, maybe it's fixed now... > >Jerome Glisse > > > > Jerome, Thanks for the tip. I updated to not only the latest Mesa cvs and drm cvs, but the latest xorg cvs. This is a vast improvement, and XFCE4 works with DRI enabled. But... glxgears segfaults: (gdb) run Starting program: /usr/X11R6/bin/glxgears [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 5369)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 5369)] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0xb7a300e4 in execute_list (ctx=0x805e7b8, list=145) at main/dlist.c:6420 #2 0xb7a30940 in _mesa_CallList (list=1) at main/dlist.c:6749 #3 0xb7a81a3d in neutral_CallList (i=1) at vtxfmt_tmp.h:304 #4 0xb7e8d615 in glCallList (list=1) at glapitemp.h:85 #5 0x08049fa4 in ?? () #6 0x00000001 in ?? () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x3f800000 in ?? () #10 0x00000000 in ?? () #11 0x0804c050 in ?? () #12 0xbfd011f8 in ?? () #13 0xb7db1509 in XPending () from /usr/X11R6/lib/libX11.so.6 #14 0x0804a6dd in ?? () #15 0x0804c050 in ?? () #16 0xbfd01250 in ?? () #17 0xbfd01258 in ?? () #18 0xb7b1159b in _mesa_set_enable (ctx=0x804c050, cap=3221225472, state=0 '\0') at main/enable.c:1017 #19 0x0804a8d9 in ?? () #20 0x0804c050 in ?? () #21 0x01400002 in ?? () ---Type <return> to continue, or q <return> to quit--- #22 0x00000000 in ?? () #23 0x00000000 in ?? () #24 0x00000000 in ?? () #25 0x0000012c in ?? () #26 0x0000012c in ?? () #27 0xbfd01320 in ?? () #28 0xbfd01324 in ?? () #29 0xbfd01314 in ?? () #30 0xb7d3ec6a in pthread_mutex_unlock () from /lib/libpthread.so.0 #31 0xb7c0d469 in __libc_start_main () from /lib/libc.so.6 #32 0x08049141 in ?? () All the xscreensaver apps work, as does blender. So far, it's just glxgears that crashes. Any ideas? Adam |
From: Jerome G. <j.g...@gm...> - 2005-08-10 01:50:14
|
On 8/8/05, Adam K Kirchhoff <ad...@vo...> wrote: > Jerome, >=20 > Thanks for the tip. I updated to not only the latest Mesa cvs and > drm cvs, but the latest xorg cvs. This is a vast improvement, and XFCE4 > works with DRI enabled. But... glxgears segfaults: >=20 > (gdb) run > Starting program: /usr/X11R6/bin/glxgears > [Thread debugging using libthread_db enabled] > [New Thread 16384 (LWP 5369)] >=20 > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 5369)] > 0x00000000 in ?? () > (gdb) bt > #0 0x00000000 in ?? () > #1 0xb7a300e4 in execute_list (ctx=3D0x805e7b8, list=3D145) at > main/dlist.c:6420 > #2 0xb7a30940 in _mesa_CallList (list=3D1) at main/dlist.c:6749 > #3 0xb7a81a3d in neutral_CallList (i=3D1) at vtxfmt_tmp.h:304 > #4 0xb7e8d615 in glCallList (list=3D1) at glapitemp.h:85 > #5 0x08049fa4 in ?? () > #6 0x00000001 in ?? () > #7 0x00000000 in ?? () > #8 0x00000000 in ?? () > #9 0x3f800000 in ?? () > #10 0x00000000 in ?? () > #11 0x0804c050 in ?? () > #12 0xbfd011f8 in ?? () > #13 0xb7db1509 in XPending () from /usr/X11R6/lib/libX11.so.6 > #14 0x0804a6dd in ?? () > #15 0x0804c050 in ?? () > #16 0xbfd01250 in ?? () > #17 0xbfd01258 in ?? () > #18 0xb7b1159b in _mesa_set_enable (ctx=3D0x804c050, cap=3D3221225472, > state=3D0 '\0') at main/enable.c:1017 > #19 0x0804a8d9 in ?? () > #20 0x0804c050 in ?? () > #21 0x01400002 in ?? () > ---Type <return> to continue, or q <return> to quit--- > #22 0x00000000 in ?? () > #23 0x00000000 in ?? () > #24 0x00000000 in ?? () > #25 0x0000012c in ?? () > #26 0x0000012c in ?? () > #27 0xbfd01320 in ?? () > #28 0xbfd01324 in ?? () > #29 0xbfd01314 in ?? () > #30 0xb7d3ec6a in pthread_mutex_unlock () from /lib/libpthread.so.0 > #31 0xb7c0d469 in __libc_start_main () from /lib/libc.so.6 > #32 0x08049141 in ?? () >=20 > All the xscreensaver apps work, as does blender. So far, it's just > glxgears that crashes. >=20 > Any ideas? Hhhmm i have got this things with Ian change but it disapear with lastest Mesa (he fixed such issue). Maybe you still have an old copy of libGL laying around in some dark place :) Double check that you don't have an old libGL (the one with current xorg cvs may not cause that, thus install the one from mesa cvs). Anyway glxgears isn't the killer app you want to start everyday and look at the beautifull gear :) Jerome Glisse |
From: Adam K K. <ad...@vo...> - 2005-08-10 00:38:13
|
Jerome Glisse wrote: >On 8/8/05, Adam K Kirchhoff <ad...@vo...> wrote: > > >>Jerome, >> >> Thanks for the tip. I updated to not only the latest Mesa cvs and >>drm cvs, but the latest xorg cvs. This is a vast improvement, and XFCE4 >>works with DRI enabled. But... glxgears segfaults: >> >>(gdb) run >>Starting program: /usr/X11R6/bin/glxgears >>[Thread debugging using libthread_db enabled] >>[New Thread 16384 (LWP 5369)] >> >>Program received signal SIGSEGV, Segmentation fault. >>[Switching to Thread 16384 (LWP 5369)] >>0x00000000 in ?? () >>(gdb) bt >>#0 0x00000000 in ?? () >>#1 0xb7a300e4 in execute_list (ctx=0x805e7b8, list=145) at >>main/dlist.c:6420 >>#2 0xb7a30940 in _mesa_CallList (list=1) at main/dlist.c:6749 >>#3 0xb7a81a3d in neutral_CallList (i=1) at vtxfmt_tmp.h:304 >>#4 0xb7e8d615 in glCallList (list=1) at glapitemp.h:85 >>#5 0x08049fa4 in ?? () >>#6 0x00000001 in ?? () >>#7 0x00000000 in ?? () >>#8 0x00000000 in ?? () >>#9 0x3f800000 in ?? () >>#10 0x00000000 in ?? () >>#11 0x0804c050 in ?? () >>#12 0xbfd011f8 in ?? () >>#13 0xb7db1509 in XPending () from /usr/X11R6/lib/libX11.so.6 >>#14 0x0804a6dd in ?? () >>#15 0x0804c050 in ?? () >>#16 0xbfd01250 in ?? () >>#17 0xbfd01258 in ?? () >>#18 0xb7b1159b in _mesa_set_enable (ctx=0x804c050, cap=3221225472, >> state=0 '\0') at main/enable.c:1017 >>#19 0x0804a8d9 in ?? () >>#20 0x0804c050 in ?? () >>#21 0x01400002 in ?? () >>---Type <return> to continue, or q <return> to quit--- >>#22 0x00000000 in ?? () >>#23 0x00000000 in ?? () >>#24 0x00000000 in ?? () >>#25 0x0000012c in ?? () >>#26 0x0000012c in ?? () >>#27 0xbfd01320 in ?? () >>#28 0xbfd01324 in ?? () >>#29 0xbfd01314 in ?? () >>#30 0xb7d3ec6a in pthread_mutex_unlock () from /lib/libpthread.so.0 >>#31 0xb7c0d469 in __libc_start_main () from /lib/libc.so.6 >>#32 0x08049141 in ?? () >> >>All the xscreensaver apps work, as does blender. So far, it's just >>glxgears that crashes. >> >>Any ideas? >> >> > >Hhhmm i have got this things with Ian change but it disapear with >lastest Mesa (he fixed such issue). Maybe you still have an old copy >of libGL laying around in some dark place :) Double check that you >don't have an old libGL (the one with current xorg cvs may not cause >that, thus install the one from mesa cvs). > >Anyway glxgears isn't the killer app you want to start everyday and >look at the beautifull gear :) > >Jerome Glisse > > > > Yeah, but I've now tried ppracer and bzflag. I get segfaults with both of those as well. I've updated by locate database, and pulled up all copies of libGL.so.1. I've also run ldd on those particular apps. It's definitly linking to the correct copy of libGL.so.1 (which is from Mesa CVS). Adam |
From: Roland S. <rsc...@hi...> - 2005-08-10 14:36:41
|
Adam K Kirchhoff wrote: >>> Thanks for the tip. I updated to not only the latest Mesa cvs and >>> drm cvs, but the latest xorg cvs. This is a vast improvement, and XFCE4 >>> works with DRI enabled. But... glxgears segfaults: >>> >>> (gdb) run >>> Starting program: /usr/X11R6/bin/glxgears >>> [Thread debugging using libthread_db enabled] >>> [New Thread 16384 (LWP 5369)] >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread 16384 (LWP 5369)] >>> 0x00000000 in ?? () >>> (gdb) bt >>> #0 0x00000000 in ?? () >>> #1 0xb7a300e4 in execute_list (ctx=0x805e7b8, list=145) at >>> main/dlist.c:6420 >>> #2 0xb7a30940 in _mesa_CallList (list=1) at main/dlist.c:6749 >>> #3 0xb7a81a3d in neutral_CallList (i=1) at vtxfmt_tmp.h:304 >>> #4 0xb7e8d615 in glCallList (list=1) at glapitemp.h:85 Try this patch here: http://marc.theaimsgroup.com/?l=mesa3d-dev&m=112337787415898&w=2 That should fix the issue. I believe it not only fixes it, but it's the right thing to do, mesa maps the gl vertex attrib functions (such as glNormal) to glVertexAttribNV functions somewhere in the display list code - and the dispatch offsets for these won't exist otherwise (unless you have a driver which claims to support NV_vertex_program). Someone might want to check this in (with a better comment...), I can't until next week. Roland |
From: Adam K K. <ad...@vo...> - 2005-08-10 14:50:18
|
Roland Scheidegger wrote: > Adam K Kirchhoff wrote: > >>>> Thanks for the tip. I updated to not only the latest Mesa cvs and >>>> drm cvs, but the latest xorg cvs. This is a vast improvement, and >>>> XFCE4 >>>> works with DRI enabled. But... glxgears segfaults: >>>> >>>> (gdb) run >>>> Starting program: /usr/X11R6/bin/glxgears >>>> [Thread debugging using libthread_db enabled] >>>> [New Thread 16384 (LWP 5369)] >>>> >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to Thread 16384 (LWP 5369)] >>>> 0x00000000 in ?? () >>>> (gdb) bt >>>> #0 0x00000000 in ?? () >>>> #1 0xb7a300e4 in execute_list (ctx=0x805e7b8, list=145) at >>>> main/dlist.c:6420 >>>> #2 0xb7a30940 in _mesa_CallList (list=1) at main/dlist.c:6749 >>>> #3 0xb7a81a3d in neutral_CallList (i=1) at vtxfmt_tmp.h:304 >>>> #4 0xb7e8d615 in glCallList (list=1) at glapitemp.h:85 >>> > > Try this patch here: > http://marc.theaimsgroup.com/?l=mesa3d-dev&m=112337787415898&w=2 > That should fix the issue. I believe it not only fixes it, but it's > the right thing to do, mesa maps the gl vertex attrib functions (such > as glNormal) to glVertexAttribNV functions somewhere in the display > list code - and the dispatch offsets for these won't exist otherwise > (unless you have a driver which claims to support NV_vertex_program). > > Someone might want to check this in (with a better comment...), I > can't until next week. > > Roland > Roland, Thanks! That fixed the crahes for me. Adam |
From: Keith W. <ke...@tu...> - 2005-08-10 14:57:56
|
Roland Scheidegger wrote: > Adam K Kirchhoff wrote: > >>>> Thanks for the tip. I updated to not only the latest Mesa cvs and >>>> drm cvs, but the latest xorg cvs. This is a vast improvement, and >>>> XFCE4 >>>> works with DRI enabled. But... glxgears segfaults: >>>> >>>> (gdb) run >>>> Starting program: /usr/X11R6/bin/glxgears >>>> [Thread debugging using libthread_db enabled] >>>> [New Thread 16384 (LWP 5369)] >>>> >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to Thread 16384 (LWP 5369)] >>>> 0x00000000 in ?? () >>>> (gdb) bt >>>> #0 0x00000000 in ?? () >>>> #1 0xb7a300e4 in execute_list (ctx=0x805e7b8, list=145) at >>>> main/dlist.c:6420 >>>> #2 0xb7a30940 in _mesa_CallList (list=1) at main/dlist.c:6749 >>>> #3 0xb7a81a3d in neutral_CallList (i=1) at vtxfmt_tmp.h:304 >>>> #4 0xb7e8d615 in glCallList (list=1) at glapitemp.h:85 > > > Try this patch here: > http://marc.theaimsgroup.com/?l=mesa3d-dev&m=112337787415898&w=2 > That should fix the issue. I believe it not only fixes it, but it's the > right thing to do, mesa maps the gl vertex attrib functions (such as > glNormal) to glVertexAttribNV functions somewhere in the display list > code - and the dispatch offsets for these won't exist otherwise (unless > you have a driver which claims to support NV_vertex_program). > > Someone might want to check this in (with a better comment...), I can't > until next week. This should all be shifted from relying on the NV extension to the ARB one, that might mean changing the display list code as well. The ARB extensions are pretty much central to the future development of Mesa and the drivers, while the NV ones will remain peripheral. Keith |
From: Ian R. <id...@us...> - 2005-08-10 23:36:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Keith Whitwell wrote: > Roland Scheidegger wrote: > >> Try this patch here: >> http://marc.theaimsgroup.com/?l=mesa3d-dev&m=112337787415898&w=2 >> That should fix the issue. I believe it not only fixes it, but it's >> the right thing to do, mesa maps the gl vertex attrib functions (such >> as glNormal) to glVertexAttribNV functions somewhere in the display >> list code - and the dispatch offsets for these won't exist otherwise >> (unless you have a driver which claims to support NV_vertex_program). >> >> Someone might want to check this in (with a better comment...), I >> can't until next week. > > This should all be shifted from relying on the NV extension to the ARB > one, that might mean changing the display list code as well. > > The ARB extensions are pretty much central to the future development of > Mesa and the drivers, while the NV ones will remain peripheral. In this particular case, we can't (without changing *lots* of code). The ARB attributes do not alias the fixed-function attributes, but the NV attributes do. Mesa is relying on the aliasing happening. I'm not sure what the "right" answer is here, but I'm open to suggestions. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC+o9QX1gOwKyEAw8RAi8VAJ4kRFZ2JTou/JD+kStDUmxmf2DP/ACePzy0 Vqa2w8wNyLUTmFysoEaXzq4= =uBco -----END PGP SIGNATURE----- |
From: Brian P. <bri...@tu...> - 2005-08-11 14:01:52
|
Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Keith Whitwell wrote: > >>Roland Scheidegger wrote: >> >> >>>Try this patch here: >>>http://marc.theaimsgroup.com/?l=mesa3d-dev&m=112337787415898&w=2 >>>That should fix the issue. I believe it not only fixes it, but it's >>>the right thing to do, mesa maps the gl vertex attrib functions (such >>>as glNormal) to glVertexAttribNV functions somewhere in the display >>>list code - and the dispatch offsets for these won't exist otherwise >>>(unless you have a driver which claims to support NV_vertex_program). >>> >>>Someone might want to check this in (with a better comment...), I >>>can't until next week. >> >>This should all be shifted from relying on the NV extension to the ARB >>one, that might mean changing the display list code as well. >> >>The ARB extensions are pretty much central to the future development of >>Mesa and the drivers, while the NV ones will remain peripheral. > > > In this particular case, we can't (without changing *lots* of code). > The ARB attributes do not alias the fixed-function attributes, but the > NV attributes do. Mesa is relying on the aliasing happening. > > I'm not sure what the "right" answer is here, but I'm open to > suggestions. :) The GL_ARB_v_p extension is somewhat layered on the GL_NV_v_p extension at this time. Before we can fully move away from that, we need to work out the non-aliasing vertex attribute stuff. I started on that back in the winter, but there's a lot of work to be done yet. It's a long-term project. -Brian |