Re: [Dri-devel] Problem wih latest r200
marc == marc poulhies [EMAIL PROTECTED] writes: marc Hi, marc I have a radeon 8500 LE (Radeon R200 QL [Radeon 8500 LE]) and i experience marc problems with r200-* packages from begining september. I use gcc-3.2 and xfree marc 4.2.0. The install script does his work, but when starting X, it just swithes marc off my monitor but nothing seems freeze as i can reboot with CTRL ALT DEL. I was marc wondering if i am having problems with gcc 3.2/2.95... Yes, I have the same problems, too. Try to use libxaa.a posted here by J. R. Fonseca. I haven't tested this, though - will do it later. marc Another thing is that on my gentoo-1.4rc1, the install.sh script had some marc problems doing his job, and sometimes it thinks he has done his job, but it is marc linking files to 'not' (surely an error output of some command) and all my marc libGL.so* are dead links. I tried to find the error but did not succed. Yes yes, the problem is opengl-update (for having XFree86-OpenGL and Nvidia-OpenGL). The libs aren't kept in /usr/X11R6/lib but in /usr/lib/opengl/xfree. Plus: libGLU.so is in /usr/lib but install.sh wants them to be in /usr/X11R6/lib. Well, anyways: I always comment out the following lines in my install.sh: # Make sure libGL and libGLU have correct links # rm -f $XF86_GL_DIR/libGL.so # rm -f $XF86_GL_DIR/libGL.so.1 # ln -s $XF86_GL_DIR/libGL.so.1.2 $XF86_GL_DIR/libGL.so # ln -s $XF86_GL_DIR/libGL.so.1.2 $XF86_GL_DIR/libGL.so.1 # rm -f $XF86_GL_DIR/libGLU.so # rm -f $XF86_GL_DIR/libGLU.so.1 # ln -s $XF86_GL_DIR/libGLU.so.1.3 $XF86_GL_DIR/libGLU.so; # ln -s $XF86_GL_DIR/libGLU.so.1.3 $XF86_GL_DIR/libGLU.so.1; With this modifications - as the snapshots do not include libGL Co. - you are safe (well, at least I am ;-). Bye, Adam. -- Adam Duck ([EMAIL PROTECTED]) Bockenheimer Landstr. 135 / Zi. 211 60325 Frankfurt/Main __ A TRUE Klingon Warrior does not comment his code! --- Klingon Programmer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Turn your life around dri-devel
= dri-devel, we don't want to waste your time...or ours = = You must be determined to earn a bare minimum of $10,000 in the next 45-90 = days = and to develop a net worth of over 1 Million Dollars Cash in the next 24-36 = months. = My mission is to help other people develop their life long dreams. Part of = what I'm = looking for are those people who are committed to that BIG of a picture and = are = not afraid to work for it. = = We can help you: = = REGARDLESS OF YOUR CURRENT AGE = OR YOUR DEBT LOAD! = NOT MLM or FRANCHISE = = Don't bother to call unless you are serious. = = Learn the Facts - CALL 1(800)775-0719 (24 Hrs) = = = $10,000 IN 45 - 90 DAYS = = RETIREMENT IN 3-5 YEARS = = = = 8CB3699686A841FA22CD41E916CB0FCFBF709042F11733D4063BED17002CDE1E = DMLWOWNTJJIDBTIAGOR = _ = = To be taken off the list = http://new-biz-opportunities.com/NewUpdates/Opt-Out/index.htm = = = --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Problem wih latest r200
Hi, I have a radeon 8500 LE (Radeon R200 QL [Radeon 8500 LE]) and i experience problems with r200-* packages from begining september. I use gcc-3.2 and xfree 4.2.0. The install script does his work, but when starting X, it just swithes off my monitor but nothing seems freeze as i can reboot with CTRL ALT DEL. I was wondering if i am having problems with gcc 3.2/2.95... Another thing is that on my gentoo-1.4rc1, the install.sh script had some problems doing his job, and sometimes it thinks he has done his job, but it is linking files to 'not' (surely an error output of some command) and all my libGL.so* are dead links. I tried to find the error but did not succed. Marc - This mail sent through IMP: http://horde.org/imp/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon: two-sided lighting issues
Michel Dänzer wrote: On Fre, 2002-10-11 at 18:52, Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). [...] One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) I may have stumbled upon this one, see the attached patch. Unfortunately, this doesn't fix the black roofs in bzflag, I wonder if it helps with flightgear... Index: radeon_state.c === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_state.c,v retrieving revision 1.18 diff -p -u -r1.18 radeon_state.c --- radeon_state.c 25 Aug 2002 22:24:39 - 1.18 +++ radeon_state.c 12 Oct 2002 01:24:14 - @@ -885,7 +885,7 @@ void radeonUpdateMaterial( GLcontext *ct GLuint mask = ~0; if (ctx-Light.ColorMaterialEnabled) - mask = ~ctx-Light.ColorMaterialBitmask; + mask = ctx-Light.ColorMaterialBitmask; The old code is correct -- if colormaterial is enabled, then calls to glMaterial should only affect the bits of the material that aren't being covered by colormaterial. In other words, the colormaterial should reflect the current color - anything set by glMaterial is instantly overrided by the current color. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] radeon snapshots, assertio failures and segfaults
Hi everyone, Hopefully a useful data point: the radeon nightly snapshots now work for me as long as I use Jose's libxaa.a. Without the new libxaa.a, I get the much reported blank screen. Looks like we need to bundle libxaa.a with the nightly backups. The radeon driver works fine most of the time, but still falls over with our medical imaging application. This differs from the usual OpenGL game in that it has multiple popup windows with multiple GL contexts. There are two symptoms: (a) Repeatable assertion failures as follows: radeon_vtxfmt.c:1045: radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed. This one is well documented and I believe near the top of Keith's todo list! A workaround is RADEON_NO_TCL=1 or RADEON_NO_VTXFMT=1. (b) More sporadic (but not rare) segfaults, which nothing seems to work around. Seemed to be introduced some time in August, I don't get these with the 1 August snapshots. Here's a debug trace, showing that this one too is to do with destroying contexts in the multiple context applications: Program received signal SIGSEGV, Segmentation fault. 0x4207adb8 in chunk_free () from /lib/i686/libc.so.6 (gdb) where #0 0x4207adb8 in chunk_free () from /lib/i686/libc.so.6 #1 0x4207ac24 in free () from /lib/i686/libc.so.6 #2 0x4051dd08 in _mesa_extensions_dtr (ctx=0x84c4988) at extensions.c:351 #3 0x4050523a in _mesa_free_context_data (ctx=0x84c4988) at context.c:1723 #4 0x4050527f in _mesa_destroy_context (ctx=0x84c4988) at context.c:1738 #5 0x4062191d in radeonDestroyContext (driContextPriv=0x8445308) at radeon_context.c:575 #6 0x404f05ff in driDestroyContext (dpy=0x8170878, scrn=0, contextPrivate=0x8445308) at dri_util.c:762 #7 0x4005c7df in __glXFreeContext () from /usr/X11R6/lib/libGL.so.1 Let me know if there's anything I can do to help of the testing variety. I regret that understanding the source is well beyond me. Andrew --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Problem wih latest r200
M Hi, M I have a radeon 8500 LE (Radeon R200 QL [Radeon 8500 LE]) and i experience M problems with r200-* packages from begining september. I use gcc-3.2 and xfree M 4.2.0. The install script does his work, but when starting X, it just swithes M off my monitor but nothing seems freeze as i can reboot with CTRL ALT DEL. I was M wondering if i am having problems with gcc 3.2/2.95... M Another thing is that on my gentoo-1.4rc1, the install.sh script had some M problems doing his job, and sometimes it thinks he has done his job, but it is M linking files to 'not' (surely an error output of some command) and all my M libGL.so* are dead links. I tried to find the error but did not succed. M Marc I had this same issue. What you need to do is compile the latest cvs from scratch (under the doc section of dri.sourceforge.net). Also, I noticed that if you loaded ATI's fglr200 module, you must reboot your system (a simple rmmod doesn't work) before starting X or else the monitor will do what you said. Joe --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon snapshots, assertio failures and segfaults
A. H. Gee wrote: Hi everyone, Hopefully a useful data point: the radeon nightly snapshots now work for me as long as I use Jose's libxaa.a. Without the new libxaa.a, I get the much reported blank screen. Looks like we need to bundle libxaa.a with the nightly backups. The radeon driver works fine most of the time, but still falls over with our medical imaging application. This differs from the usual OpenGL game in that it has multiple popup windows with multiple GL contexts. There are two symptoms: (a) Repeatable assertion failures as follows: radeon_vtxfmt.c:1045: radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed. This one is well documented and I believe near the top of Keith's todo list! A workaround is RADEON_NO_TCL=1 or RADEON_NO_VTXFMT=1. (b) More sporadic (but not rare) segfaults, which nothing seems to work around. Seemed to be introduced some time in August, I don't get these with the 1 August snapshots. Here's a debug trace, showing that this one too is to do with destroying contexts in the multiple context applications: Program received signal SIGSEGV, Segmentation fault. 0x4207adb8 in chunk_free () from /lib/i686/libc.so.6 (gdb) where #0 0x4207adb8 in chunk_free () from /lib/i686/libc.so.6 #1 0x4207ac24 in free () from /lib/i686/libc.so.6 #2 0x4051dd08 in _mesa_extensions_dtr (ctx=0x84c4988) at extensions.c:351 #3 0x4050523a in _mesa_free_context_data (ctx=0x84c4988) at context.c:1723 #4 0x4050527f in _mesa_destroy_context (ctx=0x84c4988) at context.c:1738 #5 0x4062191d in radeonDestroyContext (driContextPriv=0x8445308) at radeon_context.c:575 #6 0x404f05ff in driDestroyContext (dpy=0x8170878, scrn=0, contextPrivate=0x8445308) at dri_util.c:762 #7 0x4005c7df in __glXFreeContext () from /usr/X11R6/lib/libGL.so.1 I've just looked over this code and it seems ok. Probably what is happening is something else, somewhere else, is being free'd twice, or freed without being allocated. This will usually corrupt the internal datastructures used by free/malloc result in a crash later on, like the above. As for tracking it down, try ElectricFence, or even Purify if you have access to it (I think I heard they do a linux version now)... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon snapshots, assertio failures and segfaults
Keith Whitwell [EMAIL PROTECTED] writes: As for tracking it down, try ElectricFence, or even Purify if you have access to it (I think I heard they do a linux version now)... Valgrind can propably help also: http://developer.kde.org/~sewardj/ --j --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] gcc-3.2 problem and Makefile inconsistency
Hello, I've looked into my gcc-3.2 problem again and found out that gcc-3.2 with -march=athlon produces the problem I described in every detail in a previos mail (wirebox example). What made this so tedious to find (the problem was appearing and disappearing arbitrarily) is an inconsistency in the Makefiles. When I run a global make from xc/xc it uses the optimization options I specified in host.def (-O2 -march=athlon). When I run make locally in a subdirectory (I tried lib/GL/mesa/src/drv[/radeon]) it uses only -O2. I looked into the local Makefile and found that the definition of CFLAGS appears twice in the Makefile. The first one specifies -O2 -march=athlon in CDEBUGFLAGS, the second one specifies only -O2. So in effect a local make uses only -O2. Doing a global make CDEBUGFLAGS is specified on make the command line and of make for all subdirectories in xc/xc/xmakefile: for i in $(SUBDIRS) ;\ do \ echo making all in $(CURRENT_DIR)/$$i...; \ $(MAKE) -C $$i $(MFLAGS) $(PARALLELMFLAGS) CDEBUGFLAGS=$(CDEBUGFLAGS) all; \ done This overrides the variable definitions of CDEBUGFLAGS in all subdirectories. Now we still have to find the exact cause of the problem with -march=athlon. First of all, can anyone reproduce it? Best regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gcc-3.2 problem and Makefile inconsistency
Hi, I think I'm able to reproduce the incorrect dark lighting with 'pulsar -light' as you described it. I tried to capture it in screen-shots here: http://thibs.menloschool.org/~aibara/pulsar-light1.png http://thibs.menloschool.org/~aibara/pulsar-light2.png I've built everything from a dri cvs checkout with gcc 3.2 about a week or so back, and then have recently installed the 20021011 radeon daily snapshot on top of that XFree86 installation. (Which resulted in the radeon.o DRM kernel module being built with gcc 3.2) Afaik I didn't use -march=athlon: #define DefaultGcc2i386Opt -O2 #define MesaUse3DNow YES This is a Radeon 64MB VIVO on a 760MP / SMP Athlon machine. --AHI At 12 October, 2002 Felix Kühling wrote: Hello, I've looked into my gcc-3.2 problem again and found out that gcc-3.2 with -march=athlon produces the problem I described in every detail in a previos mail (wirebox example). What made this so tedious to find (the problem was appearing and disappearing arbitrarily) is an inconsistency in the Makefiles. When I run a global make from xc/xc it uses the optimization options I specified in host.def (-O2 -march=athlon). When I run make locally in a subdirectory (I tried lib/GL/mesa/src/drv[/radeon]) it uses only -O2. I looked into the local Makefile and found that the definition of CFLAGS appears twice in the Makefile. The first one specifies -O2 -march=athlon in CDEBUGFLAGS, the second one specifies only -O2. So in effect a local make uses only -O2. Doing a global make CDEBUGFLAGS is specified on make the command line and of make for all subdirectories in xc/xc/xmakefile: for i in $(SUBDIRS) ;\ do \ echo making all in $(CURRENT_DIR)/$$i...; \ $(MAKE) -C $$i $(MFLAGS) $(PARALLELMFLAGS) CDEBUGFLAGS=$(CDEBUGFLAGS) all; \ done This overrides the variable definitions of CDEBUGFLAGS in all subdirectories. Now we still have to find the exact cause of the problem with -march=athlon. First of all, can anyone reproduce it? Best regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gcc-3.2 problem and Makefile inconsistency
On Sat, 12 Oct 2002 10:59:21 -0700 Allen H. Ibara [EMAIL PROTECTED] wrote: Hi, I think I'm able to reproduce the incorrect dark lighting with 'pulsar -light' as you described it. I was referring to another problem. I described it in a mail with subject Strange effects with Radeon7500 last monday. So far nobody has been able to reproduce it. Snapshots will never have a problem since they are not optimized for a specific CPU. Am I the only one using -march=athlon? ;) I tried to capture it in screen-shots here: http://thibs.menloschool.org/~aibara/pulsar-light1.png http://thibs.menloschool.org/~aibara/pulsar-light2.png I've built everything from a dri cvs checkout with gcc 3.2 about a week or so back, and then have recently installed the 20021011 radeon daily snapshot on top of that XFree86 installation. (Which resulted in the radeon.o DRM kernel module being built with gcc 3.2) Afaik I didn't use -march=athlon: #define DefaultGcc2i386Opt -O2 #define MesaUse3DNow YES This is a Radeon 64MB VIVO on a 760MP / SMP Athlon machine. --AHI At 12 October, 2002 Felix Kühling wrote: [snip] Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gcc-3.2 problem and Makefile inconsistency
Am Samstag, 12. Oktober 2002 20:19 schrieb Felix Kühling: On Sat, 12 Oct 2002 10:59:21 -0700 Allen H. Ibara [EMAIL PROTECTED] wrote: Hi, I think I'm able to reproduce the incorrect dark lighting with 'pulsar -light' as you described it. I was referring to another problem. I described it in a mail with subject Strange effects with Radeon7500 last monday. So far nobody has been able to reproduce it. Snapshots will never have a problem since they are not optimized for a specific CPU. Am I the only one using -march=athlon? ;) So far, Yes. 'cause I haven't a gcc-3.2 system so far on my dual Athlon MP 1900+, AMD 760MPX...;-) All is smooth gcc-2.95.3 stuff. -Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach 64 and zsnes bug.
Hi i'm using mach64 dri binary 20020916 and i've a problem with zsnes 1.36 build with openGL support. If i don't use DRI, and launch zsnes with openGL 640x480 display, all work fine, but very slowly. But if i use DRI, and laucnh zsnes, i've 2 time the right side off the screen. Zsnes work faster, no special bug, but i've 2 time the right side, and i don't understand why. I've try with an ATI 128, and a radeon : no problem. And i use the same zsnes binary on the 3 computer. I've a debian unstable and a linux 2.4.18. I've no problem with other OpenGL Apps, like chromium, tuxracer, I've try other zsnes version and i've the same problem. Is it a DRI or a zsnes bug? i don't know. And i'd hope you could help me :) Bye Roswel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Fw: Re: [Dri-devel] gcc-3.2 problem and Makefile inconsistency
Date: Sat, 12 Oct 2002 13:19:02 -0700 From: Allen H. Ibara [EMAIL PROTECTED] To: Felix Kühling [EMAIL PROTECTED] Subject: Re: [Dri-devel] gcc-3.2 problem and Makefile inconsistency I was referring to another problem. I described it in a mail with subject Strange effects with Radeon7500 last monday. So far nobody has been able to reproduce it. Snapshots will never have a problem since they are not optimized for a specific CPU. Am I the only one using -march=athlon? ;) Doh. Ok. So I rebuilt the XServer from DRI CVS again today, this time with: #define DefaultGcc2i386Opt -O3 -march=athlon Your gltest program produces a wireframe cube which promptly disappears when I resize the window (and flickers faintly as I resize it) It also produces this output: radeonUpdatePageFlipping allow 0 current 0 radeon_makeX86Normal3fv/195 CVAL 0 OFFSET 14 VAL 8051984 radeon_makeX86Normal3fv/196 CVAL 4 OFFSET 20 VAL 8051988 radeon_makeX86Normal3fv/197 CVAL 8 OFFSET 25 VAL 805198c radeon_makeX86Normal3fv done radeonUpdatePageFlipping allow 0 current 0 Also: gears, morph3d, and bounce from the Mesa Demos produce a black window as soon as they're started. (and don't even flicker when I resize them) All of the above programs spit out: radeonUpdatePageFlipping allow 0 current 0 about 3 times when I start them up, and then continuously stream that text to stderr as I'm moving or resizing the window. On the other hand Q3A 1.31 seems totally unaffected. --AHI --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gcc-3.2 problem and Makefile inconsistency
More results: I get the same strange behaviour when I compile with -march=pentium2. I could narrow it down to lib/GL/mesa/src/drv/radeon/radeon_state.c. Then I split radeon_state.c and put only one non-static function at a time in a new radeon_state2.c along with the necessary static functions. Only radeon_state2 was compiled with -march=athlon. I could reproduce the error with only radeonUpdateScissor and radeonUpdateViewportOffset in radeon_state2.c. On the other hand I don't get the error if I compile everything with -march=athlon except radeon_state2.c which means that I've neatly isolated the problem :) I had gcc generate assembler output for radeon_state2.c with -mcpu=athlon and -march=athlon. A diff of the two assembler files and radeon_state2.c (for comparing line numbers) are attached. The version compiled with -march=athlon uses %mm0, the other one doesn't. My guess is that some other part of the radeon driver or Mesa makes assumptions about the MMX state which are not true when compiling with -march=athlon. I tried disabling MesaUse3DNow and MesaUseMMX in host.def, but that didn't help. Regards, Felix On Sat, 12 Oct 2002 18:57:45 +0200 Felix Kühling [EMAIL PROTECTED] wrote: Hello, I've looked into my gcc-3.2 problem again and found out that gcc-3.2 with -march=athlon produces the problem I described in every detail in a previos mail (wirebox example). What made this so tedious to find (the problem was appearing and disappearing arbitrarily) is an inconsistency in the Makefiles. When I run a global make from xc/xc it uses the optimization options I specified in host.def (-O2 -march=athlon). When I run make locally in a subdirectory (I tried lib/GL/mesa/src/drv[/radeon]) it uses only -O2. I looked into the local Makefile and found that the definition of CFLAGS appears twice in the Makefile. The first one specifies -O2 -march=athlon in CDEBUGFLAGS, the second one specifies only -O2. So in effect a local make uses only -O2. Doing a global make CDEBUGFLAGS is specified on make the command line and of make for all subdirectories in xc/xc/xmakefile: for i in $(SUBDIRS) ;\ do \ echo making all in $(CURRENT_DIR)/$$i...; \ $(MAKE) -C $$i $(MFLAGS) $(PARALLELMFLAGS) CDEBUGFLAGS=$(CDEBUGFLAGS) all; \ done This overrides the variable definitions of CDEBUGFLAGS in all subdirectories. Now we still have to find the exact cause of the problem with -march=athlon. First of all, can anyone reproduce it? __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- radeon_state2_noathlon.s2002-10-13 01:11:30.0 +0200 +++ radeon_state2_athlon.s 2002-10-13 01:04:03.0 +0200 @@ -183,17 +183,17 @@ .loc 1 83 0 movl%eax, -16(%ebp) .loc 1 85 0 - movl12760(%ebx), %edi + movl12760(%ebx), %esi .loc 1 86 0 - fildl 28(%edi) + fildl 28(%esi) fstps -24(%ebp) .loc 1 87 0 - fildl 32(%edi) + fildl 32(%esi) .loc 1 86 0 movl-24(%ebp), %ecx .loc 1 87 0 fsts-24(%ebp) - fildl 40(%edi) + fildl 40(%esi) faddp %st, %st(1) fsts-24(%ebp) .loc 1 88 0 @@ -212,25 +212,23 @@ .loc 1 93 0 movl216(%ebx), %edx .loc 1 91 0 - movl-24(%ebp), %esi + movd-24(%ebp), %mm0 .loc 1 93 0 fildl 8(%edx) movl%ecx, -24(%ebp) flds-24(%ebp) fxch%st(1) - fucompp - fnstsw %ax - andb$69, %ah - xorb$64, %ah + fucomip %st(1), %st + fstp%st(0) jne .L14 + jp .L14 fildl 16(%edx) - movl%esi, -24(%ebp) + movd%mm0, -24(%ebp) flds-24(%ebp) fxch%st(1) - fucompp - fnstsw %ax - andb$69, %ah - cmpb$64, %ah + fucomip %st(1), %st + fstp%st(0) + jp .L14 je .L13 .L14: .loc 1 105 0 @@ -240,7 +238,7 @@ .LBE6: movl%ecx, 8(%edx) .loc 1 100 0 - movl%esi, 16(%edx) + movd%mm0, 16(%edx) .loc 1 111 0 .LBB7: movl$31, %edx @@ -248,18 +246,18 @@ .loc 1 105 0 movl%eax, -20(%ebp) .loc 1 107 0 - movl4(%eax), %esi + movl4(%eax), %edi .loc 1 111 0 - movl28(%edi), %eax + movl28(%esi), %eax decl%eax .loc 1 107 0 - andl$-7968, %esi + andl$-7968, %edi .loc 1 111 0 andl$31, %eax subl%eax, %ecx .loc 1 112 0 - movl40(%edi), %eax - addl32(%edi), %eax + movl
