From: Sergio M. B. <se...@se...> - 2005-11-13 21:48:37
Attachments:
smime.p7s
|
Hi, Today, I test chromium, tuxracer and foobillard and none of then runs try to dig with gdb and all stop on run_texnorm_stage() here is the debug with backtrace:=20 Program received signal SIGFPE, Arithmetic exception. [Switching to Thread -1208801600 (LWP 12723)] 0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/mo= dules/dri/savage_dri.so (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x00ed575b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/savage_d= ri.so Program received signal SIGFPE, Arithmetic exception. [Switching to Thread -1208904000 (LWP 3049)] 0x00c29a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/mo= dules/dri/savage_dri.so (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x00c3675b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/savage_d= ri.so (gdb) bt #0 0x00c3675b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/sava= ge_dri.so #1 0x00be2a84 in _tnl_run_pipeline () from /usr/X11R6/lib/modules/dri/sava= ge_dri.so #2 0x00c462e9 in savageRunPipeline () from /usr/X11R6/lib/modules/dri/sava= ge_dri.so #3 0x00be7ce6 in _tnl_playback_vertex_list () from /usr/X11R6/lib/modules/= dri/savage_dri.so #4 0x00b1f862 in execute_list () from /usr/X11R6/lib/modules/dri/savage_dr= i.so #5 0x00b1fc5c in _mesa_CallList () from /usr/X11R6/lib/modules/dri/savage_= dri.so #6 0x08052d41 in DisplayFunc () at billard3d.c:3015 #7 0x080821d7 in handle_display_event () at sys_stuff.c:90 #8 0x00121a91 in processWindowWorkList (window=3D0x9f82650) at glut_event.= c:1297 #9 0x00122a9b in glutMainLoop () at glut_event.c:1344 #10 0x0805819f in main (argc=3D1, argv=3D0xbf93bec4) at billard3d.c:5194 --=20 S=E9rgio M.B. |
From: Joachim F. <jfr...@fr...> - 2005-11-14 07:37:03
|
I built xorg-6.9RC2 packages for FC4 based on Mike Harris' earlier monolithic 6.9.x testing packages last week. Everything works perfectly - including GL screensavers and "ppracer". > Hi, > Today, I test chromium, tuxracer and foobillard and none of then runs > try to dig with gdb and all stop on run_texnorm_stage() > > here is the debug with backtrace: > > Program received signal SIGFPE, Arithmetic exception. > [Switching to Thread -1208801600 (LWP 12723)] > 0x00ec8a80 in _mesa_test_os_sse_exception_support () from > /usr/X11R6/lib/modules/dri/savage_dri.so (gdb) cont > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0x00ed575b in run_texnorm_stage () from > /usr/X11R6/lib/modules/dri/savage_dri.so Program received signal > SIGFPE, Arithmetic exception. > [Switching to Thread -1208904000 (LWP 3049)] > 0x00c29a80 in _mesa_test_os_sse_exception_support () from > /usr/X11R6/lib/modules/dri/savage_dri.so (gdb) cont > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0x00c3675b in run_texnorm_stage () from > /usr/X11R6/lib/modules/dri/savage_dri.so (gdb) bt > #0 0x00c3675b in run_texnorm_stage () from > /usr/X11R6/lib/modules/dri/savage_dri.so #1 0x00be2a84 in > _tnl_run_pipeline () from /usr/X11R6/lib/modules/dri/savage_dri.so #2 > 0x00c462e9 in savageRunPipeline () from > /usr/X11R6/lib/modules/dri/savage_dri.so #3 0x00be7ce6 in > _tnl_playback_vertex_list () from > /usr/X11R6/lib/modules/dri/savage_dri.so #4 0x00b1f862 in execute_list > () from /usr/X11R6/lib/modules/dri/savage_dri.so #5 0x00b1fc5c in > _mesa_CallList () from /usr/X11R6/lib/modules/dri/savage_dri.so #6 > 0x08052d41 in DisplayFunc () at billard3d.c:3015 > #7 0x080821d7 in handle_display_event () at sys_stuff.c:90 > #8 0x00121a91 in processWindowWorkList (window=3D0x9f82650) at > glut_event.c:1297 #9 0x00122a9b in glutMainLoop () at > glut_event.c:1344 > #10 0x0805819f in main (argc=3D1, argv=3D0xbf93bec4) at billard3d.c:519= 4 > > -- > S=E9rgio M.B. |
From: Ian R. <id...@us...> - 2005-11-14 15:53:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sergio Monteiro Basto wrote: > Today, I test chromium, tuxracer and foobillard and none of then runs > try to dig with gdb and all stop on run_texnorm_stage() > > here is the debug with backtrace: > > Program received signal SIGFPE, Arithmetic exception. > [Switching to Thread -1208801600 (LWP 12723)] > 0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/savage_dri.so > (gdb) cont > Continuing. What platform are you running on? Properly built drivers on Linux or BSD should *NEVER* encounter this code. That code has been removed from the Linux builds for almost a year. I suspect that you're either picking up a very old savage_dri.so or something is not right with your build. The code is #ifdef'ed out at line 186 of src/mesa/x86/x86_common.c: #if defined(__linux__) && !defined(IN_DRI_DRIVER) Clearly, IN_DRI_DRIVER should be defined when building the Savage DRI driver! :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDeLKTX1gOwKyEAw8RAnU9AJ0cRK94kxW+hLsvcxAfJOco12Zf/gCfToz8 x6nRRgMZIR+pyV4HwaIYzYI= =4Ka3 -----END PGP SIGNATURE----- |
From: Sergio M. B. <se...@se...> - 2005-11-14 20:23:43
Attachments:
smime.p7s
|
Hi, On Mon, 2005-11-14 at 07:51 -0800, Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Sergio Monteiro Basto wrote: >=20 > > Today, I test chromium, tuxracer and foobillard and none of then runs > > try to dig with gdb and all stop on run_texnorm_stage() > >=20 > > here is the debug with backtrace:=20 > >=20 > > Program received signal SIGFPE, Arithmetic exception. > > [Switching to Thread -1208801600 (LWP 12723)] > > 0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/li= b/modules/dri/savage_dri.so > > (gdb) cont > > Continuing. >=20 > What platform are you running on? Properly built drivers on Linux or > BSD should *NEVER* encounter this code. That code has been removed from > the Linux builds for almost a year. I suspect that you're either > picking up a very old savage_dri.so or something is not right with your > build. >=20 > The code is #ifdef'ed out at line 186 of src/mesa/x86/x86_common.c: >=20 > #if defined(__linux__) && !defined(IN_DRI_DRIVER) >=20 > Clearly, IN_DRI_DRIVER should be defined when building the Savage DRI > driver! :) I will go investigate this, but this is not the problem because this doesn't stop the app.=20 the problem is in=20 Program received signal SIGSEGV, Segmentation fault. 0x00c3675b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/savage_d= ri.so (gdb) bt #0 0x00c3675b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/sava= ge_dri.so #1 0x00be2a84 in _tnl_run_pipeline () from /usr/X11R6/lib/modules/dri/sava= ge_dri.so #2 0x00c462e9 in savageRunPipeline () from /usr/X11R6/lib/modules/dri/sava= ge_dri.so #3 0x00be7ce6 in _tnl_playback_vertex_list () from /usr/X11R6/lib/modules/= dri/savage_dri.so #4 0x00b1f862 in execute_list () from /usr/X11R6/lib/modules/dri/savage_dr= i.so #5 0x00b1fc5c in _mesa_CallList () from /usr/X11R6/lib/modules/dri/savage_= dri.so #6 0x08052d41 in DisplayFunc () at billard3d.c:3015 #7 0x080821d7 in handle_display_event () at sys_stuff.c:90 #8 0x00121a91 in processWindowWorkList (window=3D0x9f82650) at glut_event.= c:1297 #9 0x00122a9b in glutMainLoop () at glut_event.c:1344 #10 0x0805819f in main (argc=3D1, argv=3D0xbf93bec4) at billard3d.c:5194 thanks, --=20 S=E9rgio M.B. |
From: Ian R. <id...@us...> - 2005-11-14 20:40:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sergio Monteiro Basto wrote: > On Mon, 2005-11-14 at 07:51 -0800, Ian Romanick wrote: >>Sergio Monteiro Basto wrote: >> >>>Today, I test chromium, tuxracer and foobillard and none of then runs >>>try to dig with gdb and all stop on run_texnorm_stage() >>> >>>here is the debug with backtrace: >>> >>>Program received signal SIGFPE, Arithmetic exception. >>>[Switching to Thread -1208801600 (LWP 12723)] >>>0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/savage_dri.so >>>(gdb) cont >>>Continuing. >> >>What platform are you running on? Properly built drivers on Linux or >>BSD should *NEVER* encounter this code. That code has been removed from >>the Linux builds for almost a year. I suspect that you're either >>picking up a very old savage_dri.so or something is not right with your >>build. >> >>The code is #ifdef'ed out at line 186 of src/mesa/x86/x86_common.c: >> >>#if defined(__linux__) && !defined(IN_DRI_DRIVER) >> >>Clearly, IN_DRI_DRIVER should be defined when building the Savage DRI >>driver! :) > > I will go investigate this, but this is not the problem because this > doesn't stop the app. That is true, but there are other places in the code that depend on IN_DRI_DRIVER being correctly set. If it's not set at this place, it is likely that it's not set at the other places either. Having it not set in the other places may be the source of the crash. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDePXaX1gOwKyEAw8RAsthAKCDylfGpu3TRt//OysOqLz9Yobp7wCdHdxZ 117LLrZX3AZbrzX8fv+n4MI= =yyn4 -----END PGP SIGNATURE----- |
From: Sergio M. B. <se...@se...> - 2005-11-15 20:40:01
Attachments:
smime.p7s
|
On Mon, 2005-11-14 at 12:38 -0800, Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Sergio Monteiro Basto wrote: > > On Mon, 2005-11-14 at 07:51 -0800, Ian Romanick wrote: > >>Sergio Monteiro Basto wrote: > >> > >>>Today, I test chromium, tuxracer and foobillard and none of then runs > >>>try to dig with gdb and all stop on run_texnorm_stage() > >>> > >>>here is the debug with backtrace:=20 > >>> > >>>Program received signal SIGFPE, Arithmetic exception. > >>>[Switching to Thread -1208801600 (LWP 12723)] > >>>0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/l= ib/modules/dri/savage_dri.so > >>>(gdb) cont > >>>Continuing. > >> > >>What platform are you running on? Properly built drivers on Linux or > >>BSD should *NEVER* encounter this code. That code has been removed fro= m > >>the Linux builds for almost a year. I suspect that you're either > >>picking up a very old savage_dri.so or something is not right with your > >>build. > >> > >>The code is #ifdef'ed out at line 186 of src/mesa/x86/x86_common.c: > >> > >>#if defined(__linux__) && !defined(IN_DRI_DRIVER) > >> > >>Clearly, IN_DRI_DRIVER should be defined when building the Savage DRI > >>driver! :) > >=20 Hi,=20 Well I downgrade to xorg-6.9RC1 and the problem disappears, so is a very recent regression. About IN_DRI_DRIVE, yes it is defined at all the places. With RC1 I still get this "Arithmetic exception" but 3D apps works without problems. If I recall correctly this "Arithmetic exception" is not new at all. BTW don't know if meters but my laptop is one mobile AMD Athlon(tm) 4 Processor thanks (for your time), > > I will go investigate this, but this is not the problem because this > > doesn't stop the app.=20 >=20 > That is true, but there are other places in the code that depend on > IN_DRI_DRIVER being correctly set. If it's not set at this place, it is > likely that it's not set at the other places either. Having it not set > in the other places may be the source of the crash. --=20 S=E9rgio M.B. |
From: Ian R. <id...@us...> - 2005-11-15 23:16:19
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sergio Monteiro Basto wrote: > On Mon, 2005-11-14 at 12:38 -0800, Ian Romanick wrote: >>Sergio Monteiro Basto wrote: >>>On Mon, 2005-11-14 at 07:51 -0800, Ian Romanick wrote: >>>>Sergio Monteiro Basto wrote: >>>> >>>>>Program received signal SIGFPE, Arithmetic exception. >>>>>[Switching to Thread -1208801600 (LWP 12723)] >>>>>0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/savage_dri.so >>>> >>>>What platform are you running on? Properly built drivers on Linux or >>>>BSD should *NEVER* encounter this code. That code has been removed from >>>>the Linux builds for almost a year. I suspect that you're either >>>>picking up a very old savage_dri.so or something is not right with your >>>>build. >>>> >>>>The code is #ifdef'ed out at line 186 of src/mesa/x86/x86_common.c: >>>> >>>>#if defined(__linux__) && !defined(IN_DRI_DRIVER) >>>> >>>>Clearly, IN_DRI_DRIVER should be defined when building the Savage DRI >>>>driver! :) > > Well I downgrade to xorg-6.9RC1 and the problem disappears, so is a very > recent regression. > About IN_DRI_DRIVE, yes it is defined at all the places. Impossible. Edit src/mesa/x86/x86_common.c and put a '#warning Got here' before and after the '#if defined(__linux__) && !defined(IN_DRI_DRIVER)' at line 186. Rebuild and grep the build output for '#warning'. > With RC1 I still get this "Arithmetic exception" > but 3D apps works without problems. > If I recall correctly this "Arithmetic exception" is not new at all. Re-read my original reply. It was *removed* from the Linux builds about a year ago. I still stand by the problem being somewhere in your build. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDemv4X1gOwKyEAw8RAhpGAJ9ws/DQRbcTVFLlrefofNXLvGYwxACfZD1s NndoQpMqLi3a9ViVnq/SQaQ= =umA9 -----END PGP SIGNATURE----- |
From: Joachim F. <jfr...@fr...> - 2005-11-16 08:04:20
|
Right, RC1 and also RC2 build and work flawlessy under FC4 on an IBM ThinkPad T23. Even for Fedora rawhide, RC2 works essentially correctly except for some GL screensaver flicker whereas RC1 is perfect. This is clearly a build problem related to S.B.'s system. |
From: Sergio M. B. <se...@se...> - 2005-11-18 00:29:50
Attachments:
smime.p7s
|
Hi, After analyze how build Mesa from CVS with "make linux-x86-dri" and how xorg built same Mesa source with "make World". Ian Romanick has point that Mesa code should have IN_DRI_DRIVER Define. So, I found on xc/lib/GL/mesa all subdirs: shader swrast tnl x86 main math and tnl_dd have missing at least -DIN_DRI_DRIVER Xorg build also misses -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=3D1 -DHAVE_ALIAS Ian, and those ones are needed ?=20 As side note I haven't the minimum idea, what side effect this could cause on non Linux or BSD systems.=20 --- xc/lib/GL/mesa/Imakefile.orig 2005-11-17 23:46:56.000000000 +0000 +++ xc/lib/GL/mesa/Imakefile 2005-11-17 23:04:00.000000000 +0000 @@ -50,7 +50,7 @@ MATH_DEFINES =3D -DCCPML #endif - DEFINES =3D $(ALLOC_DEFINES) GlxDefines \ + DEFINES =3D $(ALLOC_DEFINES) GlxDefines -DIN_DRI_DRIVER \ $(MESA_ASM_DEFINES) $(MATH_DEFINES) INCLUDES =3D -I$(INCLUDESRC) -I$(XINCLUDESRC) -I$(EXTINCSRC) \ -I$(GLXLIBSRC)/dri \ On Tue, 2005-11-15 at 15:15 -0800, Ian Romanick wrote: > >>>>>Program received signal SIGFPE, Arithmetic exception. > >>>>>[Switching to Thread -1208801600 (LWP 12723)] > >>>>>0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6= /lib/modules/dri/savage_dri.so > >>>> > >>>>What platform are you running on? Properly built drivers on Linux or > >>>>BSD should *NEVER* encounter this code. That code has been removed f= rom > >>>>the Linux builds for almost a year. I suspect that you're either > >>>>picking up a very old savage_dri.so or something is not right with yo= ur > >>>>build. > >>>> > >>>>The code is #ifdef'ed out at line 186 of src/mesa/x86/x86_common.c: > >>>> > >>>>#if defined(__linux__) && !defined(IN_DRI_DRIVER) > >>>> > >>>>Clearly, IN_DRI_DRIVER should be defined when building the Savage DRI > >>>>driver! :) > >=20 > > Well I downgrade to xorg-6.9RC1 and the problem disappears, so is a ver= y > > recent regression. > > About IN_DRI_DRIVE, yes it is defined at all the places. >=20 > Impossible. Edit src/mesa/x86/x86_common.c and put a '#warning Got > here' before and after the '#if defined(__linux__) && > !defined(IN_DRI_DRIVER)' at line 186. Rebuild and grep the build output > for '#warning'. >=20 > > With RC1 I still get this "Arithmetic exception" > > but 3D apps works without problems. > > If I recall correctly this "Arithmetic exception" is not new at all. >=20 > Re-read my original reply. It was *removed* from the Linux builds about > a year ago. >=20 > I still stand by the problem being somewhere in your build. thanks, --=20 S=E9rgio M.B. |
From: Roland S. <rsc...@hi...> - 2005-11-21 18:15:45
|
Sergio Monteiro Basto wrote: > After analyze how build Mesa from CVS with "make linux-x86-dri" and > how xorg built same Mesa source with "make World". > > Ian Romanick has point that Mesa code should have IN_DRI_DRIVER > Define. So, I found on xc/lib/GL/mesa all subdirs: shader swrast tnl > x86 main math and tnl_dd have missing at least -DIN_DRI_DRIVER I think this should be blocker on the 6.9 (I guess 7.0 isn't affected?) release, though I'm not really sure on the exact consequences. > Xorg build also misses -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 > -DHAVE_ALIAS Ian, and those ones are needed ? Can't comment on the others (though usually care must be taken with the threading stuff!), but not having -DUSE_EXTERNAL_DXTN_LIB=1 will obviously cause it to not support s3tc with the external library (I had already filed a bug about this, https://bugs.freedesktop.org/show_bug.cgi?id=5057). > As side note I haven't the minimum idea, what side effect this could > cause on non Linux or BSD systems. Since the code in question is only built on systems which support dri, there shouldn't be any problems I suspect. The glx server code is built elsewhere (and as a side note, it can't use -DUSE_EXTERNAL_DXTN_LIB=1, at least last time I tried it was not possible to use the dl functions directly). > --- xc/lib/GL/mesa/Imakefile.orig 2005-11-17 23:46:56.000000000 > +0000 +++ xc/lib/GL/mesa/Imakefile 2005-11-17 23:04:00.000000000 > +0000 @@ -50,7 +50,7 @@ MATH_DEFINES = -DCCPML #endif > > - DEFINES = $(ALLOC_DEFINES) GlxDefines \ + DEFINES = > $(ALLOC_DEFINES) GlxDefines -DIN_DRI_DRIVER \ $(MESA_ASM_DEFINES) > $(MATH_DEFINES) INCLUDES = -I$(INCLUDESRC) -I$(XINCLUDESRC) > -I$(EXTINCSRC) \ -I$(GLXLIBSRC)/dri \ I'm not sure if that's the best place to put it, it looks like usually the -Ddefinewhatever are all in the Imakefile.inc files, maybe that would be nicer. Roland |
From: Sergio M. B. <se...@se...> - 2005-11-21 21:24:32
Attachments:
smime.p7s
|
Hi,=20 I remade the patch, and I attach to bug #1709, because resolved the issue there. and I marked the bug has verified. The patch looks to me, obvious but don't know for sure. Its based on this result: http://sergiomb.no-ip.org/xorg/xorgRC2/SOURCES/list thanks,=20 On Mon, 2005-11-21 at 19:15 +0100, Roland Scheidegger wrote: > Sergio Monteiro Basto wrote: > > After analyze how build Mesa from CVS with "make linux-x86-dri" and=20 > > how xorg built same Mesa source with "make World". > >=20 > > Ian Romanick has point that Mesa code should have IN_DRI_DRIVER=20 > > Define. So, I found on xc/lib/GL/mesa all subdirs: shader swrast tnl > > x86 main math and tnl_dd have missing at least -DIN_DRI_DRIVER > I think this should be blocker on the 6.9 (I guess 7.0 isn't affected?) > release, though I'm not really sure on the exact consequences. >=20 > > Xorg build also misses -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=3D1=20 > > -DHAVE_ALIAS Ian, and those ones are needed ? > Can't comment on the others (though usually care must be taken with the > threading stuff!), but not having -DUSE_EXTERNAL_DXTN_LIB=3D1 will > obviously cause it to not support s3tc with the external library (I had > already filed a bug about this, > https://bugs.freedesktop.org/show_bug.cgi?id=3D5057). >=20 > > As side note I haven't the minimum idea, what side effect this could=20 > > cause on non Linux or BSD systems. > Since the code in question is only built on systems which support dri, > there shouldn't be any problems I suspect. The glx server code is built > elsewhere (and as a side note, it can't use -DUSE_EXTERNAL_DXTN_LIB=3D1, > at least last time I tried it was not possible to use the dl functions > directly). >=20 > > --- xc/lib/GL/mesa/Imakefile.orig 2005-11-17 23:46:56.000000000 > > +0000 +++ xc/lib/GL/mesa/Imakefile 2005-11-17 23:04:00.000000000 > > +0000 @@ -50,7 +50,7 @@ MATH_DEFINES =3D -DCCPML #endif > >=20 > > - DEFINES =3D $(ALLOC_DEFINES) GlxDefines \ + DEFINES =3D=20 > > $(ALLOC_DEFINES) GlxDefines -DIN_DRI_DRIVER \ $(MESA_ASM_DEFINES)=20 > > $(MATH_DEFINES) INCLUDES =3D -I$(INCLUDESRC) -I$(XINCLUDESRC)=20 > > -I$(EXTINCSRC) \ -I$(GLXLIBSRC)/dri \ > I'm not sure if that's the best place to put it, it looks like usually=20 > the -Ddefinewhatever are all in the Imakefile.inc files, maybe that=20 > would be nicer. >=20 > Roland --=20 S=E9rgio M.B. |
From: Sergio M. B. <se...@se...> - 2005-12-02 17:44:38
Attachments:
smime.p7s
|
On Mon, 2005-11-21 at 19:15 +0100, Roland Scheidegger wrote: >=20 > > Xorg build also misses -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=3D1=20 > > -DHAVE_ALIAS Ian, and those ones are needed ? > Can't comment on the others (though usually care must be taken with the > threading stuff!), but not having -DUSE_EXTERNAL_DXTN_LIB=3D1 will > obviously cause it to not support s3tc with the external library (I had > already filed a bug about this, > https://bugs.freedesktop.org/show_bug.cgi?id=3D5057). >=20 have you any sampler where I can test s3tc on my r200 ? I having been trying test it with nfsu2 game but it is cracked and doesn't start. =20 > > As side note I haven't the minimum idea, what side effect this could=20 > > cause on non Linux or BSD systems. > Since the code in question is only built on systems which support dri, > there shouldn't be any problems I suspect. The glx server code is built > elsewhere (and as a side note, it can't use -DUSE_EXTERNAL_DXTN_LIB=3D1, > at least last time I tried it was not possible to use the dl functions > directly). > Roland --=20 S=E9rgio M.B. |
From: Roland S. <rsc...@hi...> - 2005-12-03 04:24:21
|
Sergio Monteiro Basto wrote: >>> Xorg build also misses -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 >>> -DHAVE_ALIAS Ian, and those ones are needed ? >> >> Can't comment on the others (though usually care must be taken with >> the threading stuff!), but not having -DUSE_EXTERNAL_DXTN_LIB=1 >> will obviously cause it to not support s3tc with the external >> library (I had already filed a bug about this, >> https://bugs.freedesktop.org/show_bug.cgi?id=5057). >> > > > have you any sampler where I can test s3tc on my r200 ? I having been > trying test it with nfsu2 game but it is cracked and doesn't start. > for software compression (and hw decompression), quake3 (and other games using the same engine) is a good test (you can actually see some slight artifacts in the main game menu due to the compression (r_ext_compressed_textures 1), though it is smart enough to only use it if the extension is available. Roland |
From: Sergio M. B. <se...@se...> - 2005-12-03 18:35:53
Attachments:
smime.p7s
|
Hi Roland, I am trying testing s3tc with q3demo=20 adding -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=3D1 -DHAVE_ALIAS=20 but I am getting this error : Mesa 6.4.1 implementation error: bad S wrap mode in r200SetTexWrap Please report at bugzilla.freedesktop.org Mesa 6.4.1 implementation error: bad T wrap mode in r200SetTexWrap Please report at bugzilla.freedesktop.org Mesa 6.4.1 implementation error: bad R wrap mode in r200SetTexWrap Please report at bugzilla.freedesktop.org any idea of what this might be ? Thanks,=20 On Sat, 2005-12-03 at 05:23 +0100, Roland Scheidegger wrote: > Sergio Monteiro Basto wrote: > >>> Xorg build also misses -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=3D1=20 > >>> -DHAVE_ALIAS Ian, and those ones are needed ? > >>=20 > >> Can't comment on the others (though usually care must be taken with > >> the threading stuff!), but not having -DUSE_EXTERNAL_DXTN_LIB=3D1 > >> will obviously cause it to not support s3tc with the external > >> library (I had already filed a bug about this,=20 > >> https://bugs.freedesktop.org/show_bug.cgi?id=3D5057). > >>=20 > >=20 > >=20 > > have you any sampler where I can test s3tc on my r200 ? I having been > > trying test it with nfsu2 game but it is cracked and doesn't start. > >=20 > for software compression (and hw decompression), quake3 (and other games=20 > using the same engine) is a good test (you can actually see some slight=20 > artifacts in the main game menu due to the compression=20 > (r_ext_compressed_textures 1), though it is smart enough to only use it=20 > if the extension is available. >=20 > Roland >=20 --=20 S=E9rgio M.B. |
From: Felix <fx...@gm...> - 2005-11-15 22:18:14
|
What does your host.def file look like? What I'm getting at, when you build Xorg 6.9RC2, do you use the Mesa copy in extras or do you point MesaSrcDir at a different Mesa checkout? Regards, Felix Am Dienstag, den 15.11.2005, 20:39 +0000 schrieb Sergio Monteiro Basto: > On Mon, 2005-11-14 at 12:38 -0800, Ian Romanick wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > >=20 > > Sergio Monteiro Basto wrote: > > > On Mon, 2005-11-14 at 07:51 -0800, Ian Romanick wrote: > > >>Sergio Monteiro Basto wrote: > > >> > > >>>Today, I test chromium, tuxracer and foobillard and none of then run= s > > >>>try to dig with gdb and all stop on run_texnorm_stage() > > >>> > > >>>here is the debug with backtrace:=20 > > >>> > > >>>Program received signal SIGFPE, Arithmetic exception. > > >>>[Switching to Thread -1208801600 (LWP 12723)] > > >>>0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6= /lib/modules/dri/savage_dri.so > > >>>(gdb) cont > > >>>Continuing. > > >> > > >>What platform are you running on? Properly built drivers on Linux or > > >>BSD should *NEVER* encounter this code. That code has been removed f= rom > > >>the Linux builds for almost a year. I suspect that you're either > > >>picking up a very old savage_dri.so or something is not right with yo= ur > > >>build. > > >> > > >>The code is #ifdef'ed out at line 186 of src/mesa/x86/x86_common.c: > > >> > > >>#if defined(__linux__) && !defined(IN_DRI_DRIVER) > > >> > > >>Clearly, IN_DRI_DRIVER should be defined when building the Savage DRI > > >>driver! :) > > >=20 >=20 >=20 > Hi,=20 > Well I downgrade to xorg-6.9RC1 and the problem disappears, so is a very > recent regression. > About IN_DRI_DRIVE, yes it is defined at all the places. >=20 > With RC1 I still get this "Arithmetic exception" > but 3D apps works without problems. > If I recall correctly this "Arithmetic exception" is not new at all. >=20 > BTW don't know if meters but my laptop is one mobile AMD Athlon(tm) 4 > Processor >=20 > thanks (for your time), >=20 >=20 >=20 > > > I will go investigate this, but this is not the problem because this > > > doesn't stop the app.=20 > >=20 > > That is true, but there are other places in the code that depend on > > IN_DRI_DRIVER being correctly set. If it's not set at this place, it i= s > > likely that it's not set at the other places either. Having it not set > > in the other places may be the source of the crash. >=20 --=20 | Felix K=C3=BChling <fx...@gm...> http://fxk.de.vu = | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: Sergio M. B. <se...@se...> - 2005-11-15 23:26:27
Attachments:
smime.p7s
host-i386.def
|
Hi, I just use monolithic sources, therefore I don't copy any Mesa source neither point MesaSrcDir. This is one of my goals build exclusive with one source. My host.def is one redhat custom it goes in attach I just add this patch to enable savage DRI http://sergiomb.no-ip.org/xorg/xorgRC2/SOURCES/xorg.cf.diff and build it as rpm like I explain on http://sergiomb.no-ip.org/xorg/xorgRC2 For me the best way to build it on Fedora Core 4, this formula has worked well, since xorg-6.8.99.4 snapshot Brian Paul had write recently to xorg-ML this "I see that the Mesa 6.4 release has been incorporated (on RC2) . I'm not sure who's been doing that, but thanks!" Any test I can do further, are welcome Thanks, On Tue, 2005-11-15 at 16:10 -0500, Felix Kühling wrote: > What does your host.def file look like? What I'm getting at, when you > build Xorg 6.9RC2, do you use the Mesa copy in extras or do you point > MesaSrcDir at a different Mesa checkout? > > Regards, > Felix > > Am Dienstag, den 15.11.2005, 20:39 +0000 schrieb Sergio Monteiro Basto: > > On Mon, 2005-11-14 at 12:38 -0800, Ian Romanick wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Sergio Monteiro Basto wrote: > > > > On Mon, 2005-11-14 at 07:51 -0800, Ian Romanick wrote: > > > >>Sergio Monteiro Basto wrote: > > > >> > > > >>>Today, I test chromium, tuxracer and foobillard and none of then runs > > > >>>try to dig with gdb and all stop on run_texnorm_stage() > > > >>> > > > >>>here is the debug with backtrace: > > > >>> > > > >>>Program received signal SIGFPE, Arithmetic exception. > > > >>>[Switching to Thread -1208801600 (LWP 12723)] > > > >>>0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/savage_dri.so > > > >>>(gdb) cont > > > >>>Continuing. > > > >> > > > >>What platform are you running on? Properly built drivers on Linux or > > > >>BSD should *NEVER* encounter this code. That code has been removed from > > > >>the Linux builds for almost a year. I suspect that you're either > > > >>picking up a very old savage_dri.so or something is not right with your > > > >>build. > > > >> > > > >>The code is #ifdef'ed out at line 186 of src/mesa/x86/x86_common.c: > > > >> > > > >>#if defined(__linux__) && !defined(IN_DRI_DRIVER) > > > >> > > > >>Clearly, IN_DRI_DRIVER should be defined when building the Savage DRI > > > >>driver! :) > > > > > > > > > > Hi, > > Well I downgrade to xorg-6.9RC1 and the problem disappears, so is a very > > recent regression. > > About IN_DRI_DRIVE, yes it is defined at all the places. > > > > With RC1 I still get this "Arithmetic exception" > > but 3D apps works without problems. > > If I recall correctly this "Arithmetic exception" is not new at all. > > > > BTW don't know if meters but my laptop is one mobile AMD Athlon(tm) 4 > > Processor > > > > thanks (for your time), > > > > > > > > > > I will go investigate this, but this is not the problem because this > > > > doesn't stop the app. > > > > > > That is true, but there are other places in the code that depend on > > > IN_DRI_DRIVER being correctly set. If it's not set at this place, it is > > > likely that it's not set at the other places either. Having it not set > > > in the other places may be the source of the crash. > > -- Sérgio M.B. |
From: Sergio M. B. <se...@se...> - 2005-11-16 22:09:01
Attachments:
smime.p7s
|
On Tue, 2005-11-15 at 15:15 -0800, Ian Romanick wrote: > Sergio Monteiro Basto wrote: > > On Mon, 2005-11-14 at 12:38 -0800, Ian Romanick wrote: > >>Sergio Monteiro Basto wrote: > >>>On Mon, 2005-11-14 at 07:51 -0800, Ian Romanick wrote: > >>>>Sergio Monteiro Basto wrote: > >>>> > >>>>>Program received signal SIGFPE, Arithmetic exception. > >>>>>[Switching to Thread -1208801600 (LWP 12723)] > >>>>>0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6= /lib/modules/dri/savage_dri.so > >>>> > >>>>What platform are you running on? Properly built drivers on Linux or > >>>>BSD should *NEVER* encounter this code. That code has been removed f= rom > >>>>the Linux builds for almost a year. I suspect that you're either > >>>>picking up a very old savage_dri.so or something is not right with yo= ur > >>>>build. > >>>> > >>>>The code is #ifdef'ed out at line 186 of src/mesa/x86/x86_common.c: > >>>> > >>>>#if defined(__linux__) && !defined(IN_DRI_DRIVER) > >>>> > >>>>Clearly, IN_DRI_DRIVER should be defined when building the Savage DRI > >>>>driver! :) > >=20 > > Well I downgrade to xorg-6.9RC1 and the problem disappears, so is a ver= y > > recent regression. > > About IN_DRI_DRIVE, yes it is defined at all the places. >=20 > Impossible. Edit src/mesa/x86/x86_common.c and put a '#warning Got > here' before and after the '#if defined(__linux__) && > !defined(IN_DRI_DRIVER)' at line 186. Rebuild and grep the build output > for '#warning'. Hi,=20 Well I won=20 make[4]: Entering directory `/home/src/redhat/BUILD/xorg-x11-6.8.99.901/xc/= lib/GL' making all in lib/GL/mesa... make[5]: Entering directory `/home/src/redhat/BUILD/xorg-x11-6.8.99.901/xc/= lib/GL/mesa' making all in lib/GL/mesa/x86... make[6]: Entering directory `/home/src/redhat/BUILD/xorg-x11-6.8.99.901/xc/= lib/GL/mesa/x86' rm -f common_x86.o gcc -m32 -c -g -ansi -Wall -Wpointee-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I../../../../extras/Mesa/src/mesa -I../../../../extras/Mesa/include -I../../../../lib/GL/include -I../../../../extras/Mesa/src/mesa/main -I../../../../extras/Mesa/src/mesa/x86 -I../../../../extras/Mesa/src/mesa/glapi -I../../../.. -I../../../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=3D199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64 -D_GNU_SOURCE -DFUNCPROTO=3D15 -DNARROWPROTO -DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM common_x86.c common_x86.c:188:2: warning: ewarning Got here but what savage DRI got to do with it ? I produce this log with a simple "make world" type by hand. Well with my host.def ! btw yesterday I found the bug that I am talking about https://bugs.freedesktop.org/show_bug.cgi?id=3D1709 this is filed as notabug. thanks,=20 --=20 S=E9rgio M.B. |
From: Sergio M. B. <se...@se...> - 2005-11-16 22:15:21
Attachments:
smime.p7s
|
not "I won" "You won" is what I meant to write=20 sorry=20 --=20 S=E9rgio M.B. |
From: Roland S. <rsc...@hi...> - 2005-12-04 02:09:03
|
Sergio Monteiro Basto wrote: > Hi Roland, > > I am trying testing s3tc with q3demo > adding -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DHAVE_ALIAS > > but I am getting this error : > Mesa 6.4.1 implementation error: bad S wrap mode in r200SetTexWrap > Please report at bugzilla.freedesktop.org > Mesa 6.4.1 implementation error: bad T wrap mode in r200SetTexWrap > Please report at bugzilla.freedesktop.org > Mesa 6.4.1 implementation error: bad R wrap mode in r200SetTexWrap > Please report at bugzilla.freedesktop.org > > any idea of what this might be ? That's weird, looks like an impossible error (can not be caused by direct opengl call, as invalid values wouldn't get past main mesa's error checking, that would only leave some unitialized texture object as a possible cause, since r200SetTexWrap accepts all possible values). Are you sure that build runs with anything at all? I've tried to track down "impossible" errors in the past, and they are often caused by partial recompiles (xorg monolith absolutely _needs_ make World after Imake changes in my experience, and btw the same is sometimes true for builds within mesa itself too (make clean should do the trick there)). Otherwise, I'm unsure what the -DPTHREADS and -DHAVE_ALIAS switches actually do. Maybe they conflict with other options (some xthreads stuff maybe?) which are used in the xorg build. Roland |
From: Sergio M. B. <se...@se...> - 2005-12-05 00:29:46
Attachments:
smime.p7s
MissingMesadDefines.diff
|
On Sun, 2005-12-04 at 03:09 +0100, Roland Scheidegger wrote: > Otherwise, I'm unsure what the -DPTHREADS and -DHAVE_ALIAS switches > actually do. Maybe they conflict with other options (some xthreads > stuff maybe?) which are used in the xorg build. Yes , remove -DPTHREADS and -DHAVE_ALIAS switches, resolve the problem Now, on my r200, glxinfo|grep s3tc I got: GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_SGIS_texture_lod, GL_S3_s3tc but q3demo still say that I don't find texture compression cat q3demo2.log | grep GL_S3_s3tc Mesa: Mesa GL_EXTENSIONS = GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_S3_s3tc ...GL_S3_s3tc not found strange Anyway q3demo runs faster Here it goes the patch that I think that should be applied on Xorg-6.9, enables 2 defines, one needed and test it on my Athlon with one Savage (bug #1709) and other on one r200 (bug #5057). I had be careful about just enable switches ifdef BuildXF86DRI. This 2 Defines doesn't appear to be crucial to a good building of Xorg monolithic tree, so my personal opinion aren't blockers but are the correct way of compiling Mesa on Xorg-6.9 build. Roland I am writing to you because hope that you can review, approved and get submit this patch :). thanks, -- Sérgio M.B. |
From: Sergio M. B. <se...@se...> - 2005-11-19 01:33:05
Attachments:
smime.p7s
|
Hi,=20 with Mesa CVS no luck just a better debug=20 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208609088 (LWP 21869)] 0x00ae0b1b in run_texnorm_stage (ctx=3D0x8a404e0, stage=3D0x8bdcb58) at sav= agerender.c:251 251 GLboolean normalizeS =3D (texObj->WrapS =3D=3D GL_REPEAT); (gdb) bt #0 0x00ae0b1b in run_texnorm_stage (ctx=3D0x8a404e0, stage=3D0x8bdcb58) at= savagerender.c:251 #1 0x00b7dabd in _tnl_run_pipeline (ctx=3D0x8a404e0) at tnl/t_pipeline.c:1= 62 #2 0x00adbe5a in savageRunPipeline (ctx=3D0x8a404e0) at savagetris.c:806 #3 0x00b8475d in _tnl_playback_vertex_list (ctx=3D0x8a404e0, data=3D0x8da0= cac) at tnl/t_save_playback.c:209 #4 0x00b00036 in execute_list (ctx=3D0x8a404e0, list=3D1) at main/dlist.c:= 5678 #5 0x00b03a9a in _mesa_CallList (list=3D1) at main/dlist.c:6746 #6 0x00b72d8b in neutral_CallList (i=3D1) at main/vtxfmt_tmp.h:304 #7 0x08052d41 in DisplayFunc () at billard3d.c:3015 #8 0x080821d7 in handle_display_event () at sys_stuff.c:90 #9 0x00121a91 in processWindowWorkList (window=3D0x8a3a648) at glut_event.= c:1297 #10 0x00122a9b in glutMainLoop () at glut_event.c:1344 #11 0x0805819f in main (argc=3D1, argv=3D0xbfe83c24) at billard3d.c:5194 On Sun, 2005-11-13 at 21:48 +0000, Sergio Monteiro Basto wrote: > Hi, > Today, I test chromium, tuxracer and foobillard and none of then runs > try to dig with gdb and all stop on run_texnorm_stage() >=20 > here is the debug with backtrace:=20 >=20 > Program received signal SIGFPE, Arithmetic exception. > [Switching to Thread -1208801600 (LWP 12723)] > 0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/= modules/dri/savage_dri.so > (gdb) cont > Continuing. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x00ed575b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/savage= _dri.so > Program received signal SIGFPE, Arithmetic exception. > [Switching to Thread -1208904000 (LWP 3049)] > 0x00c29a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/= modules/dri/savage_dri.so > (gdb) cont > Continuing. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x00c3675b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/savage= _dri.so > (gdb) bt > #0 0x00c3675b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/sa= vage_dri.so > #1 0x00be2a84 in _tnl_run_pipeline () from /usr/X11R6/lib/modules/dri/sa= vage_dri.so > #2 0x00c462e9 in savageRunPipeline () from /usr/X11R6/lib/modules/dri/sa= vage_dri.so > #3 0x00be7ce6 in _tnl_playback_vertex_list () from /usr/X11R6/lib/module= s/dri/savage_dri.so > #4 0x00b1f862 in execute_list () from /usr/X11R6/lib/modules/dri/savage_= dri.so > #5 0x00b1fc5c in _mesa_CallList () from /usr/X11R6/lib/modules/dri/savag= e_dri.so > #6 0x08052d41 in DisplayFunc () at billard3d.c:3015 > #7 0x080821d7 in handle_display_event () at sys_stuff.c:90 > #8 0x00121a91 in processWindowWorkList (window=3D0x9f82650) at glut_even= t.c:1297 > #9 0x00122a9b in glutMainLoop () at glut_event.c:1344 > #10 0x0805819f in main (argc=3D1, argv=3D0xbf93bec4) at billard3d.c:5194 >=20 --=20 S=E9rgio M.B. |
From: Brian P. <bri...@tu...> - 2005-11-19 14:42:01
Attachments:
savage.patch
|
Can you print the value of nearby local vars, such as 'texObj', 'reallyEnabled' and 'i'? I bet a patch along the lines of what I've attached might fix the problem. -Brian Sergio Monteiro Basto wrote: > Hi, > with Mesa CVS no luck > just a better debug > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1208609088 (LWP 21869)] > 0x00ae0b1b in run_texnorm_stage (ctx=0x8a404e0, stage=0x8bdcb58) at savagerender.c:251 > 251 GLboolean normalizeS = (texObj->WrapS == GL_REPEAT); > (gdb) bt > #0 0x00ae0b1b in run_texnorm_stage (ctx=0x8a404e0, stage=0x8bdcb58) at savagerender.c:251 > #1 0x00b7dabd in _tnl_run_pipeline (ctx=0x8a404e0) at tnl/t_pipeline.c:162 > #2 0x00adbe5a in savageRunPipeline (ctx=0x8a404e0) at savagetris.c:806 > #3 0x00b8475d in _tnl_playback_vertex_list (ctx=0x8a404e0, data=0x8da0cac) at tnl/t_save_playback.c:209 > #4 0x00b00036 in execute_list (ctx=0x8a404e0, list=1) at main/dlist.c:5678 > #5 0x00b03a9a in _mesa_CallList (list=1) at main/dlist.c:6746 > #6 0x00b72d8b in neutral_CallList (i=1) at main/vtxfmt_tmp.h:304 > #7 0x08052d41 in DisplayFunc () at billard3d.c:3015 > #8 0x080821d7 in handle_display_event () at sys_stuff.c:90 > #9 0x00121a91 in processWindowWorkList (window=0x8a3a648) at glut_event.c:1297 > #10 0x00122a9b in glutMainLoop () at glut_event.c:1344 > #11 0x0805819f in main (argc=1, argv=0xbfe83c24) at billard3d.c:5194 > > > On Sun, 2005-11-13 at 21:48 +0000, Sergio Monteiro Basto wrote: > >>Hi, >>Today, I test chromium, tuxracer and foobillard and none of then runs >>try to dig with gdb and all stop on run_texnorm_stage() >> >>here is the debug with backtrace: >> >>Program received signal SIGFPE, Arithmetic exception. >>[Switching to Thread -1208801600 (LWP 12723)] >>0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/savage_dri.so >>(gdb) cont >>Continuing. >> >>Program received signal SIGSEGV, Segmentation fault. >>0x00ed575b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/savage_dri.so >>Program received signal SIGFPE, Arithmetic exception. >>[Switching to Thread -1208904000 (LWP 3049)] >>0x00c29a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/savage_dri.so >>(gdb) cont >>Continuing. >> >>Program received signal SIGSEGV, Segmentation fault. >>0x00c3675b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/savage_dri.so >>(gdb) bt >>#0 0x00c3675b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/savage_dri.so >>#1 0x00be2a84 in _tnl_run_pipeline () from /usr/X11R6/lib/modules/dri/savage_dri.so >>#2 0x00c462e9 in savageRunPipeline () from /usr/X11R6/lib/modules/dri/savage_dri.so >>#3 0x00be7ce6 in _tnl_playback_vertex_list () from /usr/X11R6/lib/modules/dri/savage_dri.so >>#4 0x00b1f862 in execute_list () from /usr/X11R6/lib/modules/dri/savage_dri.so >>#5 0x00b1fc5c in _mesa_CallList () from /usr/X11R6/lib/modules/dri/savage_dri.so >>#6 0x08052d41 in DisplayFunc () at billard3d.c:3015 >>#7 0x080821d7 in handle_display_event () at sys_stuff.c:90 >>#8 0x00121a91 in processWindowWorkList (window=0x9f82650) at glut_event.c:1297 >>#9 0x00122a9b in glutMainLoop () at glut_event.c:1344 >>#10 0x0805819f in main (argc=1, argv=0xbf93bec4) at billard3d.c:5194 >> |
From: Sergio M. B. <se...@se...> - 2005-11-19 16:54:01
Attachments:
smime.p7s
|
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208236352 (LWP 25396)] 0x00fa4afb in run_texnorm_stage (ctx=3D0x8ce54e0, stage=3D0x8e81b58) at savagerender.c:251 251 GLboolean normalizeS =3D (texObj->WrapS =3D=3D GL_REPEAT); (gdb) print texObj $1 =3D (struct gl_texture_object *) 0x0 (gdb) print reallyEnabled $2 =3D 0 (gdb) print i $3 =3D 1 is this you asking for ? anything that I can do ?=20 And this patch works! yes Thanks,=20 On Sat, 2005-11-19 at 07:41 -0700, Brian Paul wrote: > Can you print the value of nearby local vars, such as 'texObj',=20 > 'reallyEnabled' and 'i'? >=20 > I bet a patch along the lines of what I've attached might fix the problem= . >=20 > -Brian >=20 > Sergio Monteiro Basto wrote: > > Hi,=20 > > with Mesa CVS no luck > > just a better debug=20 > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread -1208609088 (LWP 21869)] > > 0x00ae0b1b in run_texnorm_stage (ctx=3D0x8a404e0, stage=3D0x8bdcb58) at= savagerender.c:251 > > 251 GLboolean normalizeS =3D (texObj->WrapS =3D=3D GL_REPEAT)= ; > > (gdb) bt > > #0 0x00ae0b1b in run_texnorm_stage (ctx=3D0x8a404e0, stage=3D0x8bdcb58= ) at savagerender.c:251 > > #1 0x00b7dabd in _tnl_run_pipeline (ctx=3D0x8a404e0) at tnl/t_pipeline= .c:162 > > #2 0x00adbe5a in savageRunPipeline (ctx=3D0x8a404e0) at savagetris.c:8= 06 > > #3 0x00b8475d in _tnl_playback_vertex_list (ctx=3D0x8a404e0, data=3D0x= 8da0cac) at tnl/t_save_playback.c:209 > > #4 0x00b00036 in execute_list (ctx=3D0x8a404e0, list=3D1) at main/dlis= t.c:5678 > > #5 0x00b03a9a in _mesa_CallList (list=3D1) at main/dlist.c:6746 > > #6 0x00b72d8b in neutral_CallList (i=3D1) at main/vtxfmt_tmp.h:304 > > #7 0x08052d41 in DisplayFunc () at billard3d.c:3015 > > #8 0x080821d7 in handle_display_event () at sys_stuff.c:90 > > #9 0x00121a91 in processWindowWorkList (window=3D0x8a3a648) at glut_ev= ent.c:1297 > > #10 0x00122a9b in glutMainLoop () at glut_event.c:1344 > > #11 0x0805819f in main (argc=3D1, argv=3D0xbfe83c24) at billard3d.c:519= 4 > >=20 > >=20 > > On Sun, 2005-11-13 at 21:48 +0000, Sergio Monteiro Basto wrote: > >=20 > >>Hi, > >>Today, I test chromium, tuxracer and foobillard and none of then runs > >>try to dig with gdb and all stop on run_texnorm_stage() > >> > >>here is the debug with backtrace:=20 > >> > >>Program received signal SIGFPE, Arithmetic exception. > >>[Switching to Thread -1208801600 (LWP 12723)] > >>0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/li= b/modules/dri/savage_dri.so > >>(gdb) cont > >>Continuing. > >> > >>Program received signal SIGSEGV, Segmentation fault. > >>0x00ed575b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/sava= ge_dri.so > >>Program received signal SIGFPE, Arithmetic exception. > >>[Switching to Thread -1208904000 (LWP 3049)] > >>0x00c29a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/li= b/modules/dri/savage_dri.so > >>(gdb) cont > >>Continuing. > >> > >>Program received signal SIGSEGV, Segmentation fault. > >>0x00c3675b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/sava= ge_dri.so > >>(gdb) bt > >>#0 0x00c3675b in run_texnorm_stage () from /usr/X11R6/lib/modules/dri/= savage_dri.so > >>#1 0x00be2a84 in _tnl_run_pipeline () from /usr/X11R6/lib/modules/dri/= savage_dri.so > >>#2 0x00c462e9 in savageRunPipeline () from /usr/X11R6/lib/modules/dri/= savage_dri.so > >>#3 0x00be7ce6 in _tnl_playback_vertex_list () from /usr/X11R6/lib/modu= les/dri/savage_dri.so > >>#4 0x00b1f862 in execute_list () from /usr/X11R6/lib/modules/dri/savag= e_dri.so > >>#5 0x00b1fc5c in _mesa_CallList () from /usr/X11R6/lib/modules/dri/sav= age_dri.so > >>#6 0x08052d41 in DisplayFunc () at billard3d.c:3015 > >>#7 0x080821d7 in handle_display_event () at sys_stuff.c:90 > >>#8 0x00121a91 in processWindowWorkList (window=3D0x9f82650) at glut_ev= ent.c:1297 > >>#9 0x00122a9b in glutMainLoop () at glut_event.c:1344 > >>#10 0x0805819f in main (argc=3D1, argv=3D0xbf93bec4) at billard3d.c:519= 4 > >> >=20 > plain text document attachment (savage.patch) > Index: savagerender.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savagerender.c,v > retrieving revision 1.5.2.1 > diff -u -r1.5.2.1 savagerender.c > --- savagerender.c 31 Oct 2005 21:53:17 -0000 1.5.2.1 > +++ savagerender.c 19 Nov 2005 14:40:22 -0000 > @@ -248,55 +248,57 @@ > for (i =3D 0 ; i < ctx->Const.MaxTextureUnits ; i++) { > GLuint reallyEnabled =3D ctx->Texture.Unit[i]._ReallyEnabled; > struct gl_texture_object *texObj =3D ctx->Texture.Unit[i]._Current= ; > - GLboolean normalizeS =3D (texObj->WrapS =3D=3D GL_REPEAT); > - GLboolean normalizeT =3D (reallyEnabled & TEXTURE_2D_BIT) && > - (texObj->WrapT =3D=3D GL_REPEAT); > - GLfloat *in =3D (GLfloat *)VB->TexCoordPtr[i]->data; > - GLint instride =3D VB->TexCoordPtr[i]->stride; > - GLfloat (*out)[4] =3D store->texcoord[i].data; > - GLint j; > - > - if (!ctx->Texture.Unit[i]._ReallyEnabled || > - VB->TexCoordPtr[i]->size =3D=3D 4) > - /* Never try to normalize homogenous tex coords! */ > - continue; > - > - if (normalizeS && normalizeT) { > - /* take first texcoords as rough estimate of mean value */ > - GLfloat correctionS =3D -floor(in[0]+0.5); > - GLfloat correctionT =3D -floor(in[1]+0.5); > - for (j =3D 0; j < VB->Count; ++j) { > - out[j][0] =3D in[0] + correctionS; > - out[j][1] =3D in[1] + correctionT; > - in =3D (GLfloat *)((GLubyte *)in + instride); > - } > - } else if (normalizeS) { > - /* take first texcoords as rough estimate of mean value */ > - GLfloat correctionS =3D -floor(in[0]+0.5); > - if (reallyEnabled & TEXTURE_2D_BIT) { > - for (j =3D 0; j < VB->Count; ++j) { > - out[j][0] =3D in[0] + correctionS; > - out[j][1] =3D in[1]; > - in =3D (GLfloat *)((GLubyte *)in + instride); > - } > - } else { > - for (j =3D 0; j < VB->Count; ++j) { > - out[j][0] =3D in[0] + correctionS; > - in =3D (GLfloat *)((GLubyte *)in + instride); > - } > - } > - } else if (normalizeT) { > - /* take first texcoords as rough estimate of mean value */ > - GLfloat correctionT =3D -floor(in[1]+0.5); > - for (j =3D 0; j < VB->Count; ++j) { > - out[j][0] =3D in[0]; > - out[j][1] =3D in[1] + correctionT; > - in =3D (GLfloat *)((GLubyte *)in + instride); > - } > - } > + if (reallyEnabled && texObj) { > + GLboolean normalizeS =3D (texObj->WrapS =3D=3D GL_REPEAT); > + GLboolean normalizeT =3D (reallyEnabled & TEXTURE_2D_BIT) && > + (texObj->WrapT =3D=3D GL_REPEAT); > + GLfloat *in =3D (GLfloat *)VB->TexCoordPtr[i]->data; > + GLint instride =3D VB->TexCoordPtr[i]->stride; > + GLfloat (*out)[4] =3D store->texcoord[i].data; > + GLint j; > + > + if (!ctx->Texture.Unit[i]._ReallyEnabled || > + VB->TexCoordPtr[i]->size =3D=3D 4) > + /* Never try to normalize homogenous tex coords! */ > + continue; > + > + if (normalizeS && normalizeT) { > + /* take first texcoords as rough estimate of mean value */ > + GLfloat correctionS =3D -floor(in[0]+0.5); > + GLfloat correctionT =3D -floor(in[1]+0.5); > + for (j =3D 0; j < VB->Count; ++j) { > + out[j][0] =3D in[0] + correctionS; > + out[j][1] =3D in[1] + correctionT; > + in =3D (GLfloat *)((GLubyte *)in + instride); > + } > + } else if (normalizeS) { > + /* take first texcoords as rough estimate of mean value */ > + GLfloat correctionS =3D -floor(in[0]+0.5); > + if (reallyEnabled & TEXTURE_2D_BIT) { > + for (j =3D 0; j < VB->Count; ++j) { > + out[j][0] =3D in[0] + correctionS; > + out[j][1] =3D in[1]; > + in =3D (GLfloat *)((GLubyte *)in + instride); > + } > + } else { > + for (j =3D 0; j < VB->Count; ++j) { > + out[j][0] =3D in[0] + correctionS; > + in =3D (GLfloat *)((GLubyte *)in + instride); > + } > + } > + } else if (normalizeT) { > + /* take first texcoords as rough estimate of mean value */ > + GLfloat correctionT =3D -floor(in[1]+0.5); > + for (j =3D 0; j < VB->Count; ++j) { > + out[j][0] =3D in[0]; > + out[j][1] =3D in[1] + correctionT; > + in =3D (GLfloat *)((GLubyte *)in + instride); > + } > + } > =20 > - if (normalizeS || normalizeT) > - VB->AttribPtr[VERT_ATTRIB_TEX0+i] =3D VB->TexCoordPtr[i] =3D &store->t= excoord[i]; > + if (normalizeS || normalizeT) > + VB->AttribPtr[VERT_ATTRIB_TEX0+i] =3D VB->TexCoordPtr[i] =3D= &store->texcoord[i]; > + } > } > =20 > return GL_TRUE; --=20 S=E9rgio M.B. |
From: Brian P. <bri...@tu...> - 2005-11-19 17:02:49
|
Sergio Monteiro Basto wrote: > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1208236352 (LWP 25396)] > 0x00fa4afb in run_texnorm_stage (ctx=0x8ce54e0, stage=0x8e81b58) at > savagerender.c:251 > 251 GLboolean normalizeS = (texObj->WrapS == GL_REPEAT); > (gdb) print texObj > $1 = (struct gl_texture_object *) 0x0 > (gdb) print reallyEnabled > $2 = 0 > (gdb) print i > $3 = 1 > > is this you asking for ? anything that I can do ? > > And this patch works! yes Good. I'll check in the patch. -Brian |