From: danalien <dri...@da...> - 2005-02-02 09:32:13
|
Hi, I managed to get DRI from CVS going, /* info: ProSavage (KN133, TwisterK), DRI (CVS 2005.02.01 @05:44 GMT+1) */ I've tried Quake (1), and it works (can play..) .. although you can 'crash it' by just pressing ESC (which on my nvidia PC would show me the Menu) Tried, Q3A too ... but it dosn't work (can't play, only navigate about in the menu but as soon as I try to start any form of game, *boom*, I'm greeted by the same "Received signal 11, exiting..." msg I got from Quake 1 in the terminal) /* info: I know they both work on my hardware, as I've run them with other drivers (it was either via's 1st release of the savage driver source or one of tim roberts releases [don't recall exactly which of em' it was, as I was experimenting with both back and forth] ... I just recall fragging loads on my notebook on the train =) ) */ -- // with regards // UID :: dri-users :: <${gofigurewhatmyemailis}@datormaffian.com> - - - /\/\ (^.^) (")") *This is the cute kitty virus, please copy this into your sig so it can spread |
From: Felix <fx...@gm...> - 2005-02-02 16:18:10
|
Am Mittwoch, den 02.02.2005, 10:32 +0100 schrieb danalien:=20 > Hi, >=20 > I managed to get DRI from CVS going,=20 >=20 > /* info: ProSavage (KN133, TwisterK), DRI (CVS 2005.02.01 @05:44 GMT+1) *= / >=20 > I've tried Quake (1), and it works (can play..) .. although you can 'cras= h it' by just pressing ESC > (which on my nvidia PC would show me the Menu) >=20 > Tried, Q3A too ... but it dosn't work (can't play, only navigate about in= the menu but as soon as > I try to start any form of game, *boom*, I'm greeted by the same "Receive= d signal 11, exiting..." msg=20 > I got from Quake 1 in the terminal) >=20 > /* info: I know they both work on my hardware, as I've run them with othe= r drivers (it was either via's 1st release of > the savage driver source or one of tim roberts releases [don't recall exa= ctly which of em' it was, as I was experimenting > with both back and forth] ... I just recall fragging loads on my notebook= on the train =3D) ) */ >=20 I just fixed a problem in CVS that might be related. A new snapshot will be available in about 2 hours. Could you give that a try? If it doesn't fix your problem it would be helpful to see a backtrace. Follow these steps: 1. enable core dumps: ulimit -c unlimited 2. run quake1 or quake3 and trigger a segmentation fault. 3. run gdb to get a backtrace: gdb -c core `which quake...` (insert the real quake executable name) 4. in gdb type "bt <enter>" 5. Send us the output. Thanks, Felix --=20 | Felix K=FChling <fx...@gm...> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: danalien <dri...@da...> - 2005-02-02 16:31:30
|
On Wednesdayen den 2 February 2005 17.20, Felix K=FChling wrote: > I just fixed a problem in CVS that might be related. A new snapshot wil= l > be available in about 2 hours. or I could just fetch it myself from CVS :-), it's mesa's? dir. not xorg'= s? *right* > Could you give that a try? If it doesn't=20 > fix your problem it would be helpful to see a backtrace. Follow these > steps: >=20 > 1. enable core dumps: ulimit -c unlimited > 2. run quake1 or quake3 and trigger a segmentation fault. > 3. run gdb to get a backtrace: gdb -c core `which quake...` (inser= t > the real quake executable name) > 4. in gdb type "bt <enter>" > 5. Send us the output. sure. l8r --=20 // with regards // UID :: dri-users :: <${gofigurewhatmyemailis}@datormaffian.com> - - - /\/\ (^.^) (")") *This is the cute kitty virus, please copy this into your sig so it can = spread |
From: Felix <fx...@gm...> - 2005-02-02 16:37:47
|
Am Mittwoch, den 02.02.2005, 17:31 +0100 schrieb danalien: > On Wednesdayen den 2 February 2005 17.20, Felix K=FChling wrote: >=20 > > I just fixed a problem in CVS that might be related. A new snapshot wil= l > > be available in about 2 hours. >=20 > or I could just fetch it myself from CVS :-), it's mesa's? dir. not xorg'= s? *right* Yes. I assume you read the building instructions ... ;-) >=20 > > Could you give that a try? If it doesn't=20 > > fix your problem it would be helpful to see a backtrace. Follow these > > steps: > >=20 > > 1. enable core dumps: ulimit -c unlimited > > 2. run quake1 or quake3 and trigger a segmentation fault. > > 3. run gdb to get a backtrace: gdb -c core `which quake...` (inser= t > > the real quake executable name) > > 4. in gdb type "bt <enter>" > > 5. Send us the output. >=20 > sure. >=20 >=20 > l8r >=20 --=20 | Felix K=FChling <fx...@gm...> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: danalien <dri...@da...> - 2005-02-03 01:08:22
Attachments:
quake3.dump
|
On Wednesdayen den 2 February 2005 17.40, Felix K=FChling wrote: > Yes. I assume you read the building instructions ... ;-) j00pe. :). /* and btw, does anyone else having to 'ln -s /usr/X11R6/include/X11 incl= ude/X11" prior to "make linux-dri-x86"? and no, I haven't installed anything in a non-standard place. as you = might allready have seen. */ anyhow, let's move along. > Follow these steps: >=20 > 1. enable core dumps: ulimit -c unlimited > 2. run quake1 or quake3 and trigger a segmentation fault. > 3. run gdb to get a backtrace: gdb -c core `which quake...` (inser= t > the real quake executable name) > 4. in gdb type "bt <enter>" > 5. Send us the output. "Error, Will Robinson, Error." =3D) 1. ulimit -c unlimited=20 2. quake3 (switch to a VT) 3. ps aux | grep -i quake3.x86 4. gdb=20 (in gdb) 5.0 attach $PID_OY_QUAKE3X86 5.1 cont (switch to X, and crash it by trying to run a single player...) (back to VT) 5.2 bt 5.3 cont (wait for it to exit) 6. from now on it's obvious what to do next =3D) BTW. I don't get why you "-c core" - "Use file file as a core dump to exa= mine." ... as you we don't have a 'core' file to start with, that we want to examine= ... anyway.. I've attached the gdb dump. happy reading :-) --=20 // with regards // UID :: dri-users :: <${gofigurewhatmyemailis}@datormaffian.com> - - - /\/\ (^.^) (")") *This is the cute kitty virus, please copy this into your sig so it can = spread |
From: Felix <fx...@gm...> - 2005-02-03 01:20:27
|
Am Donnerstag, den 03.02.2005, 02:08 +0100 schrieb danalien: > On Wednesdayen den 2 February 2005 17.40, Felix K=FChling wrote: > > Yes. I assume you read the building instructions ... ;-) >=20 > j00pe. :). >=20 >=20 > /* and btw, does anyone else having to 'ln -s /usr/X11R6/include/X11 incl= ude/X11" prior to "make linux-dri-x86"? > and no, I haven't installed anything in a non-standard place. as you = might allready have seen. */ >=20 > anyhow, let's move along. >=20 >=20 > > Follow these steps: > >=20 > > 1. enable core dumps: ulimit -c unlimited > > 2. run quake1 or quake3 and trigger a segmentation fault. > > 3. run gdb to get a backtrace: gdb -c core `which quake...` (inser= t > > the real quake executable name) > > 4. in gdb type "bt <enter>" > > 5. Send us the output. >=20 > "Error, Will Robinson, Error." =3D) >=20 > 1. ulimit -c unlimited=20 > 2. quake3 > (switch to a VT) > 3. ps aux | grep -i quake3.x86 > 4. gdb=20 > (in gdb) > 5.0 attach $PID_OY_QUAKE3X86 > 5.1 cont > (switch to X, and crash it by trying to run a single player...) This is dangerous. If it crashes while holding the DRI lock, you won't be able to switch VTs back to your debugger. The only safe way to attach to a running DRI application is to run gdb in an ssh session from somewhere else. > (back to VT) > 5.2 bt > 5.3 cont > (wait for it to exit) > 6. from now on it's obvious what to do next =3D) >=20 >=20 > BTW. I don't get why you "-c core" - "Use file file as a core dump to exa= mine." ... > as you we don't have a 'core' file to start with, that we want to examine= ... anyway.. My plan was to let it crash, produce a core dump and then look at the core dump "offline". This is safe, even if you can't log in remotely. >=20 > I've attached the gdb dump. happy reading :-) If you compiled this from source, it would be nice if you could add "-g" to the compiler options. This will give some line number debug output. While you're tweaking compiler options, "-O0" is best for debugging. ;-) Thanks, Felix --=20 | Felix K=FChling <fx...@gm...> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: danalien <dri...@da...> - 2005-02-03 01:47:04
|
On Thursdayen den 3 February 2005 02.08, danalien wrote: > 4. gdb=20 oops, I ment 4. gdb 2>&1 | tee quake3.dump :-) *d'ooh, if you wondered how I 'magically' created that dump in a VT,= that looses it's "buffer" (except what can fit on your screen) when you = switch back and forth* On Thursdayen den 3 February 2005 02.22, Felix K=FChling wrote: >This is safe, even if you can't log in remotely. aha, but I think you could log it remotely =3DD mkfifo quake3.dump (in an other ssh session or vt...what ever) lftp ${myremotehosteI'vebookmarked} put $PATH_TO_FILE/quake3.dump (back to 'main gdb' VT/ssh session...) gdb 2>&1 | tee quake3.dump ... etc... jadda jadda jadda ... I haven't double-checked *this (prior to posting *this_msg),=20 but I've played around with FIFO's before, and I'm fairly sure=20 it'll work as I've scribbled it =3D) *snaps his wipe at linux* PS. I've found that 'lftp' can cope with 'FIFOs' while 'ncftp' can't!=20 if you where an ncftp-l0v3r as I was, until finding this out :-) --=20 // with regards // UID :: dri-users :: <${gofigurewhatmyemailis}@datormaffian.com> - - - /\/\ (^.^) (")") *This is the cute kitty virus, please copy this into your sig so it can = spread |
From: Felix <fx...@gm...> - 2005-02-03 16:35:46
|
Am Donnerstag, den 03.02.2005, 02:46 +0100 schrieb danalien: > On Thursdayen den 3 February 2005 02.08, danalien wrote: >=20 > > 4. gdb=20 >=20 > oops, I ment >=20 > 4. gdb 2>&1 | tee quake3.dump >=20 > :-) *d'ooh, if you wondered how I 'magically' created that dump in a VT,= that looses it's "buffer" (except what can fit on your screen) when you sw= itch back and forth* >=20 >=20 > On Thursdayen den 3 February 2005 02.22, Felix K=FChling wrote: > >This is safe, even if you can't log in remotely. >=20 > aha, but I think you could log it remotely =3DD I can't reproduce your segfault with the Quake3 Demo. I even tried the 3D driver from a binary snapshot to exclude any local changes in my source tree. Could be that your Q3 version does something different. Or it could be problem specific to your compiler version. (gcc --version? I haven't tried gcc-3.4 yet.) Could you try quake3 with a savage_dri.so from a binary snapshot? You don't need to install the snapshot. Just run quake3 like this (in bash): LIBGL_DRIVERS_PATH=3D<path to savage_dri.so from snapshot> quake3 That savage_dri.so includes debug information. So if it still crashes you can get a backtrace with line numbers. You could also inspect some variable values to find out which one is causing trouble. >=20 >=20 > mkfifo quake3.dump >=20 > (in an other ssh session or vt...what ever) > lftp ${myremotehosteI'vebookmarked} > put $PATH_TO_FILE/quake3.dump >=20 > (back to 'main gdb' VT/ssh session...) > gdb 2>&1 | tee quake3.dump >=20 > ... etc... jadda jadda jadda ... >=20 >=20 > I haven't double-checked *this (prior to posting *this_msg),=20 > but I've played around with FIFO's before, and I'm fairly sure=20 > it'll work as I've scribbled it =3D) *snaps his wipe at linux* The FIFO doesn't help you if your console is locked and unusable. ;-) That's what happens when the application crashes while holding the lock and the debugger prevents that the application terminates and releases the lock. You can try it if you like. Insert this code somewhere in savageCreateContext (for example): LOCK_HARDWARE(imesa); assert(0); Then run glxgears in the debugger locally. If you have a second computer to log in from, you can kill the debugger. Otherwise you'll have to reboot your computer. --=20 | Felix K=FChling <fx...@gm...> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: danalien <dri...@da...> - 2005-02-08 10:46:59
|
Oki oki, *does like in movie-fliming, clipping 'the board', and says:* = "Take Two" :-) sorry for the delay in reply, but my ISP had it's smtp down (some failure= somewhere, who really knows what *it was) and by the time it/they where back-up, I g= ot sidetracked *abit* :) On Thursdayen den 3 February 2005 02.22, Felix K=FChling wrote: > This is dangerous. If it crashes while holding the DRI lock, you won't > be able to switch VTs back to your debugger. The only safe way to attac= h > to a running DRI application is to run gdb in an ssh session from > somewhere else. Oki, Mr. I've gone and logged/done everything remotely [see attachments b= elow] :P =20 =20 On Thursdayen den 3 February 2005 02.22, Felix K=FChling wrote: > If you compiled this from source, it would be nice if you could add "-g= " > to the compiler options. This will give some line number debug output. > While you're tweaking compiler options, "-O0" is best for debugging. ;-= ) happy now?!?, for your pleasure I've attached: quake3.dump.-.-O0.-g.-march=3Dathlon-xp.-mtune=3Dathlon-xp.-m3dnow.-msse.= -mftpmath=3Dsse.-mmmx.-pipe quake3.dump.-.-O2.-g.-march=3Dathlon-xp.-mtune=3Dathlon-xp.-m3dnow.-msse.= -mftpmath=3Dsse.-mmmx.-pipe quake3.dump.-.-O2.-march=3Dathlon-xp.-mtune=3Dathlon-xp.-m3dnow.-msse.-mf= tpmath=3Dsse.-mmmx.-pipe :-) BTW, I think 'we' are narrowing on the bug. I say this, because, with -O0= , q3a plays without a hick-up. So, what ever is going on, is inbetween the optimization -O0 and -O2. On Thursdayen den 3 February 2005 02.46, danalien wrote: > aha, but I think you could log it remotely =3DD > > [...]=20 >=20 > I haven't double-checked *this (prior to posting *this_msg),=20 > but I've played around with FIFO's before, and I'm fairly sure=20 > it'll work as I've scribbled it =3D) *snaps his wipe at linux* oki, BTW it's actually=20 1st)=20 (go to 'main gdb' VT/ssh session...) =A0 gdb 2>&1 | tee quake3.dump then, 2nd) (in an other ssh session or vt...what ever) =A0 lftp ${myremotehosteI'vebookmarked} =A0 put $PATH_TO_FILE/quake3.dump *oops* /* laajnux whips danalien instead :) */ On Thursdayen den 3 February 2005 17.38, Felix K=FChling wrote: > > aha, but I think you could log it remotely =3DD >=20 > I can't reproduce your segfault with the Quake3 Demo.=20 > Could be that your Q3 version does something different.=20 './quake3.x86 --version' says: "Linux Quake3 full executable [Nov 14 2002 04:46:24]" /* My q3a runs q3a-team arena, too. So, either the Demo is diff, or not, = or it's coz' you're running compiled drivers with -O0 (not -O2) ... or its g= cc related */ > I even tried the 3D driver from a binary snapshot to exclude any local=20 > changes in my source tree.=20 then I'll assume you've compiled it/them with -O0? :-) > Could you try quake3 with a savage_dri.so from a binary snapshot? You > don't need to install the snapshot. Just run quake3 like this (in bash)= : >=20 > LIBGL_DRIVERS_PATH=3D<path to savage_dri.so from snapshot> quake3 nahh, pass. right now (noteboo is packed down ATM, it's midnight over her= e...). But if they are compiled with -O0 ... we know why they have/will work :) PS. if not -O0, may we assume it's the difference in our gcc's? [see '2st= eps' below] > You could also inspect some variable values to find out which one is ca= using trouble. jupp, guess I/we'll bench ourselfs with going thru what's between -O0 and= -O2 :) *Oi vey* > Or it could be problem specific to your compiler version. (gcc --versio= n? I > haven't tried gcc-3.4 yet.) I'm gcc 3.4.3 (I use the one archlinux.org packeged for me) /* here's the PKBUILD-script: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/gcc/PKGBUILD?rev=3D1.37= &cvsroot=3DCurrent&only_with_tag=3DCURRENT&content-type=3Dtext/vnd.viewcv= s-markup if you're curious how "they've" packeged it, etc=20 */ You? =20 > The FIFO doesn't help you if your console is locked and unusable. ;-) yeah, that's true (I am aware of it's lacking), maybe the 'serial-port lo= gging' method=20 doesn't have these hick-ups. (read on some ML, the kernel developers use(= d) this=20 method in debugging laajnux) but, as Q3a/mesa/X11/drm/etc,etc dosen't lock anything, it's all good, i= sn't it?! *:P* :-) /* btw, the only reason I've done it remotely is coz' of the nag of switc= hing out of/in to Quake3 in fullscreen-mode, to do the debuging... */ > That's what happens when the application crashes while holding the lock > and the debugger prevents that the application terminates and releases > the lock. You can try it if you like. Insert this code somewhere in > savageCreateContext (for example): >=20 > LOCK_HARDWARE(imesa); > assert(0); >=20 > Then run glxgears in the debugger locally. If you have a second compute= r > to log in from, you can kill the debugger. Otherwise you'll have to > reboot your computer. I could, but, as we won't have use of it (ATM), I'll pass :-) PPS. It's been a few days since I've done the actually 'debugging' so if = this email isn't well formated/thought out, it's coz' it's been a few days b= etween execution=20 and writing :-) --=20 // with regards // UID :: dri-users :: <${gofigurewhatmyemailis}@datormaffian.com> - - - /\/\ (^.^) (")") *This is the cute kitty virus, please copy this into your sig so it can = spread |
From: Felix <fx...@gm...> - 2005-02-08 12:22:32
|
Am Dienstag, den 08.02.2005, 01:20 +0100 schrieb danalien: > Oki oki, *does like in movie-fliming, clipping 'the board', and says:* = "Take Two" >=20 > :-) >=20 > sorry for the delay in reply, but my ISP had it's smtp down (some failure= somewhere, > who really knows what *it was) and by the time it/they where back-up, I g= ot sidetracked *abit* :) >=20 >=20 > On Thursdayen den 3 February 2005 02.22, Felix K=FChling wrote: > > This is dangerous. If it crashes while holding the DRI lock, you won't > > be able to switch VTs back to your debugger. The only safe way to attac= h > > to a running DRI application is to run gdb in an ssh session from > > somewhere else. >=20 > Oki, Mr. I've gone and logged/done everything remotely [see attachments b= elow] :P =20 >=20 >=20 > =20 > On Thursdayen den 3 February 2005 02.22, Felix K=FChling wrote: > > If you compiled this from source, it would be nice if you could add "-g= " > > to the compiler options. This will give some line number debug output. > > While you're tweaking compiler options, "-O0" is best for debugging. ;-= ) >=20 > happy now?!?, for your pleasure I've attached: >=20 > quake3.dump.-.-O0.-g.-march=3Dathlon-xp.-mtune=3Dathlon-xp.-m3dnow.-msse.= -mftpmath=3Dsse.-mmmx.-pipe > quake3.dump.-.-O2.-g.-march=3Dathlon-xp.-mtune=3Dathlon-xp.-m3dnow.-msse.= -mftpmath=3Dsse.-mmmx.-pipe > quake3.dump.-.-O2.-march=3Dathlon-xp.-mtune=3Dathlon-xp.-m3dnow.-msse.-mf= tpmath=3Dsse.-mmmx.-pipe >=20 > :-) That's better. But the line where it fails looks pretty innocent. :-/ The only thing that could be wrong is that ctx->Const is NULL or invalid. But that sounds rather unlikely. Or optimizations are messing up the line numbers. >=20 > BTW, I think 'we' are narrowing on the bug. I say this, because, with -O0= , q3a plays without a hick-up. >=20 > So, what ever is going on, is inbetween the optimization -O0 and -O2. I compile with -O2 here, the snapshots are compiled with -Os. My gcc version is "gcc (GCC) 3.3.5 (Debian 1:3.3.5-5)", snapshots are built with some 3.3.x version (Ubuntu) too. >=20 >=20 >=20 > On Thursdayen den 3 February 2005 02.46, danalien wrote: [snip] > On Thursdayen den 3 February 2005 17.38, Felix K=FChling wrote: > > > aha, but I think you could log it remotely =3DD > >=20 > > I can't reproduce your segfault with the Quake3 Demo.=20 > > Could be that your Q3 version does something different.=20 >=20 > './quake3.x86 --version' says: >=20 > "Linux Quake3 full executable [Nov 14 2002 04:46:24]" Q3 1.11 linux-i386 Dec 4 1999 >=20 > /* My q3a runs q3a-team arena, too. So, either the Demo is diff, or not, = or > it's coz' you're running compiled drivers with -O0 (not -O2) ... or its g= cc related */ I'd blame it on the compiler version. I think I can try a gcc-3.4 later this week. >=20 > > I even tried the 3D driver from a binary snapshot to exclude any local=20 > > changes in my source tree.=20 >=20 > then I'll assume you've compiled it/them with -O0? :-) -Os. >=20 > > Could you try quake3 with a savage_dri.so from a binary snapshot? You > > don't need to install the snapshot. Just run quake3 like this (in bash)= : > >=20 > > LIBGL_DRIVERS_PATH=3D<path to savage_dri.so from snapshot> quake3 >=20 > nahh, pass. right now (noteboo is packed down ATM, it's midnight over her= e...). >=20 > But if they are compiled with -O0 ... we know why they have/will work :) >=20 >=20 > PS. if not -O0, may we assume it's the difference in our gcc's? [see '2st= eps' below] >=20 >=20 > > You could also inspect some variable values to find out which one is ca= using trouble. >=20 > jupp, guess I/we'll bench ourselfs with going thru what's between -O0 and= -O2 :) *Oi vey* When I can reproduce the problem with gcc-3.4 here, it will be a lot easier. >=20 >=20 > > Or it could be problem specific to your compiler version. (gcc --versio= n? I > > haven't tried gcc-3.4 yet.) >=20 > I'm gcc 3.4.3 (I use the one archlinux.org packeged for me) >=20 > /* here's the PKBUILD-script: > http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/gcc/PKGBUILD?rev=3D1.37= &cvsroot=3DCurrent&only_with_tag=3DCURRENT&content-type=3Dtext/vnd.viewcvs-= markup > if you're curious how "they've" packeged it, etc=20 > */ >=20 [snip] --=20 | Felix K=FChling <fx...@gm...> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: Felix <fx...@gm...> - 2005-02-09 12:11:53
|
Am Dienstag, den 08.02.2005, 01:20 +0100 schrieb danalien: > Oki oki, *does like in movie-fliming, clipping 'the board', and says:* = "Take Two" >=20 > :-) >=20 > sorry for the delay in reply, but my ISP had it's smtp down (some failure= somewhere, > who really knows what *it was) and by the time it/they where back-up, I g= ot sidetracked *abit* :) >=20 >=20 > On Thursdayen den 3 February 2005 02.22, Felix K=FChling wrote: > > This is dangerous. If it crashes while holding the DRI lock, you won't > > be able to switch VTs back to your debugger. The only safe way to attac= h > > to a running DRI application is to run gdb in an ssh session from > > somewhere else. >=20 > Oki, Mr. I've gone and logged/done everything remotely [see attachments b= elow] :P =20 >=20 >=20 > =20 > On Thursdayen den 3 February 2005 02.22, Felix K=FChling wrote: > > If you compiled this from source, it would be nice if you could add "-g= " > > to the compiler options. This will give some line number debug output. > > While you're tweaking compiler options, "-O0" is best for debugging. ;-= ) >=20 > happy now?!?, for your pleasure I've attached: >=20 > quake3.dump.-.-O0.-g.-march=3Dathlon-xp.-mtune=3Dathlon-xp.-m3dnow.-msse.= -mftpmath=3Dsse.-mmmx.-pipe > quake3.dump.-.-O2.-g.-march=3Dathlon-xp.-mtune=3Dathlon-xp.-m3dnow.-msse.= -mftpmath=3Dsse.-mmmx.-pipe > quake3.dump.-.-O2.-march=3Dathlon-xp.-mtune=3Dathlon-xp.-m3dnow.-msse.-mf= tpmath=3Dsse.-mmmx.-pipe >=20 > :-) >=20 > BTW, I think 'we' are narrowing on the bug. I say this, because, with -O0= , q3a plays without a hick-up. >=20 > So, what ever is going on, is inbetween the optimization -O0 and -O2. Hmm, I recompiled Mesa with gcc-3.4 and all your options above (except -mftpmath is really -mfpmath (no ftp ;-)). I still can't reproduce the segfault. Debian's version of gcc-3.4 is a CVS snapshot from 20041218 so there might be a bug in your version that's been fixed after the upstream 3.4.3 release. If there is an upgraded package available for your distribution, try it. Otherwise, if you're still interested in this problem, you can try to track down which option enabled by -O2 is causing trouble. See the gcc manpage for the list of options. I suspect that -funit-at-a-time might be responsible, but that's just a guess. Report a bug in your distribution's bug tracking system. If you want to workaround the problem for now, you can disable the texture normalization stage. It's not essential. Edit the pipeline definition near the top of savage_xmesa.c. Comment out the line " &_savage_texnorm_stage,". [snip] --=20 | Felix K=FChling <fx...@gm...> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: danalien <dri...@da...> - 2005-02-24 17:25:24
|
wopsi, had this in my 'drafts' a little to long :) On Wednesdayen den 9 February 2005 13.14, Felix K=FChling wrote: > > happy now?!?, for your pleasure I've attached: > >=20 > > quake3.dump.-.-O0.-g.-march=3Dathlon-xp.-mtune=3Dathlon-xp.-m3dnow.-mss= e.-mftpmath=3Dsse.-mmmx.-pipe > > quake3.dump.-.-O2.-g.-march=3Dathlon-xp.-mtune=3Dathlon-xp.-m3dnow.-mss= e.-mftpmath=3Dsse.-mmmx.-pipe > > quake3.dump.-.-O2.-march=3Dathlon-xp.-mtune=3Dathlon-xp.-m3dnow.-msse.-= mftpmath=3Dsse.-mmmx.-pipe > >=20 > > :-) > >=20 > > BTW, I think 'we' are narrowing on the bug. I say this, because, with -= O0, q3a plays without a hick-up. > >=20 > > So, what ever is going on, is inbetween the optimization -O0 and -O2. >=20 > Hmm, I recompiled Mesa with gcc-3.4 and all your options above (except > -mftpmath is really -mfpmath (no ftp ;-)). sorry, its a type-o from my behalf, not improper opt. flags :-) > I still can't reproduce the=20 > segfault. Debian's version of gcc-3.4 is a CVS snapshot from 20041218 so > there might be a bug in your version that's been fixed after the > upstream 3.4.3 release. we'll see when 3.4 comes out, won't we :-) /* i only update (my notebook) with the distro, to keep things 'clean' */ > If there is an upgraded package available for your distribution, try it. noope, there isn't, I'm runnig the latest stuff. > Otherwise, if you're still interested in this problem, you can try to > track down which option enabled by -O2 is causing trouble.=20 *jippi* great, 28 opts to plow thru ...*that like, 2^28* 268.435.456 diff. = possible combinations=20 one could try *woho..NoNo* =3D) if there was a tool to automate the compile & test for 268.435.456 diff. co= mbination, I'm game, but manually. Q3a isn't that important for me to run on my notebook :) > See the gcc manpage for the list of options.=20 /* or for better formating: http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Optimize-Options.html#Optimize-= Options */ but, they don't *really* list every-little-opt :-), why I touch dummy.cpp g++ -O3 -S -fverbose-asm dummy.cpp cat dummy.s (replace "-O3" with whatever carte blanche optimization setting you are int= erested in.) is your true Opt friend :-) > I suspect that -funit-at-a-time might be responsible, but that's just a g= uess.=20 he shoots and, *drum-rollz*, misses the whole target :-) I couldn't even start quake without it crashing. (which I btw, also got when compiled it with '-Os -g') /* which gave me a little thing to ponder upon, "how to debug, if one can'= t switch=20 between crashed-quake3-stopped-by-gdb and gdb (running in xterm) to typ= e 'bt', as=20 there isn't any chance of starting quake3 directly from a remote konsol= e". Is there, now?!=20 but after a bit of head-scratching I found the magical procedure: [(ssh) remote log-in, and run: ] clear ; sleep 100000000000 #to 'clear' & free up the konsole from = grabbing (ones) stdin-input [in X/xterm, cd to quake3-path, and do:] gdb -e quake3.x86 < /dev/pts/0 2>&1 | tee quake3.dump > /dev/pts/0 and, finally I could 'remotely' execute (all) the commands in gdb (whil= e getting all the=20 feedback/output in my remote konsole. BTW, this also seems like a (much) easier way to debug, then the previo= us with mkfifo ... etc. Or is it? :) =2D-- /dev/pts/0 - might be diff. for you, run 'tty' [in remote log-in] to find= out what it is... */ > Report a bug in your distribution's bug tracking system. well, my distro, Archlinux, only runs the latest stuff that is available, v= anilla, no tweaking. so, report it to gcc.gnu.org, you mean *does a obi-wan kenobi handwave* :-) > If you want to workaround the problem for now, you can disable the > texture normalization stage. It's not essential. Edit the pipeline > definition near the top of savage_xmesa.c. Comment out the line " > &_savage_texnorm_stage,". or why not, keep the 'texture normalization' stage, but -O0 optimize ... th= at worked. =2D-=20 // with regards // UID :: dri-users :: <${gofigurewhatmyemailis}@datormaffian.com> =2D - - /\/\ (^.^) (")") *This is the cute kitty virus, please copy this into your sig so it can sp= read |
From: Felix <fx...@gm...> - 2005-02-24 22:36:11
|
Am Donnerstag, den 24.02.2005, 18:25 +0100 schrieb danalien: > wopsi, had this in my 'drafts' a little to long :) [snip] > > Otherwise, if you're still interested in this problem, you can try to > > track down which option enabled by -O2 is causing trouble.=20 >=20 > *jippi* great, 28 opts to plow thru ...*that like, 2^28* 268.435.456 diff= . possible combinations=20 > one could try *woho..NoNo* =3D) It's unlikely that it's an arbitrary combination of options causing trouble. I'd try removing one option at a time from the full set of -O2 options until the problem goes away. Or try each of the -O2 options alone without any other optimizations until you find the option that triggers the problem. That would make 56 combinations, which sounds more manageable. [snip] > /* > which gave me a little thing to ponder upon, "how to debug, if one ca= n't switch=20 > between crashed-quake3-stopped-by-gdb and gdb (running in xterm) to t= ype 'bt', as=20 > there isn't any chance of starting quake3 directly from a remote kons= ole". Is there, now?!=20 >=20 > but after a bit of head-scratching I found the magical procedure: >=20 > [(ssh) remote log-in, and run: ] > clear ; sleep 100000000000 #to 'clear' & free up the konsole fro= m grabbing (ones) stdin-input > [in X/xterm, cd to quake3-path, and do:] > gdb -e quake3.x86 < /dev/pts/0 2>&1 | tee quake3.dump > /dev/pts/0 >=20 > and, finally I could 'remotely' execute (all) the commands in gdb (wh= ile getting all the=20 > feedback/output in my remote konsole. >=20 > BTW, this also seems like a (much) easier way to debug, then the prev= ious with mkfifo ... etc. Or is it? :) It's still a bit awkward. I just log in remotely and run everything from the remote shell: DISPLAY=3D:0.0 gdb quake3.x86 ... gdb greeting you ... (gdb) run ... crash ... (gdb) bt ... inspect variables, registers, whatever ... > > If you want to workaround the problem for now, you can disable the > > texture normalization stage. It's not essential. Edit the pipeline > > definition near the top of savage_xmesa.c. Comment out the line " > > &_savage_texnorm_stage,". >=20 > or why not, keep the 'texture normalization' stage, but -O0 optimize ... = that worked. Whatever suits you best. --=20 | Felix K=FChling <fx...@gm...> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |