Re: Lockups with Googleearth
Adam K Kirchhoff wrote: On Mon, 2007-03-05 at 14:13 -0500, Adam K Kirchhoff wrote: On Mon, 2007-03-05 at 20:03 +0100, Michel Dänzer wrote: On Sun, 2007-03-04 at 11:16 -0500, Adam K Kirchhoff wrote: I've been trying to track down this problem I've been having with the r300 driver and Googleearth. Sometime, since 6.5.2 was released. It's an odd problem as I've only see it on my PCIe x800, but not my AGP x700. In addition, it only seems to happen when I'm using MergedFB. If I set MergedFB to '0', I don't have this problem. Basically, what's happening is that my system completely locks up usually after just a few seconds (the earth starts to zoom in). Sometimes it doesn't lockup till I manually grab and move the earth, or actually type in an address. I can't ping the machine and the serial console is unresponsive. Does it lock up if you don't move the mouse? Does it happen with SW cursor or no silken mouse? I believe it does lock up even if I don't move the mouse, though I'll want to confirm that when I get home in a bit. I can also try with SW cursor and/or no silken mouse later today. And I was wrong. I was able to browse the world, as long as I only typed in the places I wanted to visit. Hit three or four different cities without any problems, but just a second or two after I started moving the globe with my mouse, it locked up. And, I'm happy to report, disabling silken mouse gets it working again. I'll see if I can wrangle git into giving me a version of the drivers right before the vbo merge and right after it, though I may not get those results till tomorrow. Adam So this is what I'm seeing commit 09e4df2c65c1bca0d04c6ffd076ea7808e61c4ae causes the lockup.. If I'm reading the git log properly this is right after the merge from vbo-0.2. However, commit 47d463e954efcd15d20ab2c96a455aa16ddffdcc also causes the lockup, and this is right before the merge from vbo-0.2. I continued with the git-bisect from there last night, but still ended up at the same point: I kept getting versions that I couldn't compile, and using git reset --hard HEAD~10 ends up getting me stuck in a circle. I'll see if I can narrow it down further this afternoon. Adam - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockups with Googleearth
On Tue, 2007-03-06 at 04:32 -0500, Adam K Kirchhoff wrote: commit 09e4df2c65c1bca0d04c6ffd076ea7808e61c4ae causes the lockup.. If I'm reading the git log properly this is right after the merge from vbo-0.2. However, commit 47d463e954efcd15d20ab2c96a455aa16ddffdcc also causes the lockup, and this is right before the merge from vbo-0.2. No, that's still on vbo-0.2. The last commit on master before the merge is 325196f548f8e46aa8fcc7b030e81ba939e7f6b7. I really recommend gitk. :) -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockups with Googleearth
Michel Dänzer wrote: On Tue, 2007-03-06 at 04:32 -0500, Adam K Kirchhoff wrote: commit 09e4df2c65c1bca0d04c6ffd076ea7808e61c4ae causes the lockup.. If I'm reading the git log properly this is right after the merge from vbo-0.2. However, commit 47d463e954efcd15d20ab2c96a455aa16ddffdcc also causes the lockup, and this is right before the merge from vbo-0.2. No, that's still on vbo-0.2. The last commit on master before the merge is 325196f548f8e46aa8fcc7b030e81ba939e7f6b7. I really recommend gitk. :) Sorry about that. I turned back to the log after browsing through gitk last night well past after I should have been asleep :-) Anyway, you're suspicion was correct, this problem did not exist prior to the merge of the vbo-0.2 branch, but did start immediately after the merge. Does this need to be narrowed down further on the vbo-0.2 branch? Adam - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockups with Googleearth
Adam K Kirchhoff wrote: Michel Dänzer wrote: On Tue, 2007-03-06 at 04:32 -0500, Adam K Kirchhoff wrote: commit 09e4df2c65c1bca0d04c6ffd076ea7808e61c4ae causes the lockup.. If I'm reading the git log properly this is right after the merge from vbo-0.2. However, commit 47d463e954efcd15d20ab2c96a455aa16ddffdcc also causes the lockup, and this is right before the merge from vbo-0.2. No, that's still on vbo-0.2. The last commit on master before the merge is 325196f548f8e46aa8fcc7b030e81ba939e7f6b7. I really recommend gitk. :) Sorry about that. I turned back to the log after browsing through gitk last night well past after I should have been asleep :-) Anyway, you're suspicion was correct, this problem did not exist prior to the merge of the vbo-0.2 branch, but did start immediately after the merge. Does this need to be narrowed down further on the vbo-0.2 branch? You can try, but that branch was a wholesale replacement of some existing functionality, so you may just end up at the commit where things switched over. It may be better than that, so possibly worth trying. It may make sense to try and narrow things down in the driver to a certain operation or set of operations, ie the commit history may be too coarse and you just have to attack the bug from first principles. Keith - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockups with Googleearth
On Sun, 2007-03-04 at 11:16 -0500, Adam K Kirchhoff wrote: I've been trying to track down this problem I've been having with the r300 driver and Googleearth. Sometime, since 6.5.2 was released. It's an odd problem as I've only see it on my PCIe x800, but not my AGP x700. In addition, it only seems to happen when I'm using MergedFB. If I set MergedFB to '0', I don't have this problem. Basically, what's happening is that my system completely locks up usually after just a few seconds (the earth starts to zoom in). Sometimes it doesn't lockup till I manually grab and move the earth, or actually type in an address. I can't ping the machine and the serial console is unresponsive. Does it lock up if you don't move the mouse? Does it happen with SW cursor or no silken mouse? Bisecting: 14 revisions left to test after this [70dd0126bd25f2cc2fedae60281ab5c256cb8664] pickup structs from vbo.h Unfortunately, at that point I end up with the same build problems (t_draw.c missing). So, any tips on where I go from here? I suspect the problem is that this is on the vbo-0.2 branch. Can you try a commit from before or after its merge? Use git-reset --hard commit hash with the bisect branch checked out. gitk is nice for finding a suitable commit. With one of the bad drivers (not the one from current git) I get the following message logged before locking up: Uhhuh. NMI received. Dazed and confused, but trying to continue You probably have a hardware problem with your RAM chips. I've run memtest for about 45 minutes now, completed one pass (it's about half way through a second pass) without any errors, so I'm disinclined to believe this is a RAM issue. I guess this could also be a symptom of the lockup. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockups with Googleearth
On Mon, 2007-03-05 at 20:03 +0100, Michel Dänzer wrote: On Sun, 2007-03-04 at 11:16 -0500, Adam K Kirchhoff wrote: I've been trying to track down this problem I've been having with the r300 driver and Googleearth. Sometime, since 6.5.2 was released. It's an odd problem as I've only see it on my PCIe x800, but not my AGP x700. In addition, it only seems to happen when I'm using MergedFB. If I set MergedFB to '0', I don't have this problem. Basically, what's happening is that my system completely locks up usually after just a few seconds (the earth starts to zoom in). Sometimes it doesn't lockup till I manually grab and move the earth, or actually type in an address. I can't ping the machine and the serial console is unresponsive. Does it lock up if you don't move the mouse? Does it happen with SW cursor or no silken mouse? I believe it does lock up even if I don't move the mouse, though I'll want to confirm that when I get home in a bit. I can also try with SW cursor and/or no silken mouse later today. I suspect the problem is that this is on the vbo-0.2 branch. Can you try a commit from before or after its merge? Use git-reset --hard commit hash with the bisect branch checked out. gitk is nice for finding a suitable commit. I'll give that a shot. With one of the bad drivers (not the one from current git) I get the following message logged before locking up: Uhhuh. NMI received. Dazed and confused, but trying to continue You probably have a hardware problem with your RAM chips. I've run memtest for about 45 minutes now, completed one pass (it's about half way through a second pass) without any errors, so I'm disinclined to believe this is a RAM issue. I guess this could also be a symptom of the lockup. Well, I let it run for two hours, four total passes. No errors, so I'm definitely more inclined to believe that the impending lockup was causing the NMI error, rather than the other way around :-) Adam - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockups with Googleearth
On Mon, 2007-03-05 at 14:13 -0500, Adam K Kirchhoff wrote: On Mon, 2007-03-05 at 20:03 +0100, Michel Dänzer wrote: On Sun, 2007-03-04 at 11:16 -0500, Adam K Kirchhoff wrote: I've been trying to track down this problem I've been having with the r300 driver and Googleearth. Sometime, since 6.5.2 was released. It's an odd problem as I've only see it on my PCIe x800, but not my AGP x700. In addition, it only seems to happen when I'm using MergedFB. If I set MergedFB to '0', I don't have this problem. Basically, what's happening is that my system completely locks up usually after just a few seconds (the earth starts to zoom in). Sometimes it doesn't lockup till I manually grab and move the earth, or actually type in an address. I can't ping the machine and the serial console is unresponsive. Does it lock up if you don't move the mouse? Does it happen with SW cursor or no silken mouse? I believe it does lock up even if I don't move the mouse, though I'll want to confirm that when I get home in a bit. I can also try with SW cursor and/or no silken mouse later today. And I was wrong. I was able to browse the world, as long as I only typed in the places I wanted to visit. Hit three or four different cities without any problems, but just a second or two after I started moving the globe with my mouse, it locked up. And, I'm happy to report, disabling silken mouse gets it working again. I'll see if I can wrangle git into giving me a version of the drivers right before the vbo merge and right after it, though I may not get those results till tomorrow. Adam - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Lockups with Googleearth
Sorry, I just realized I sent two e-mails about this problem to [EMAIL PROTECTED] Not even sure how that address got into my address book in the first place, or where that mail actually goes... But, onto my problems: I've been trying to track down this problem I've been having with the r300 driver and Googleearth. Sometime, since 6.5.2 was released. It's an odd problem as I've only see it on my PCIe x800, but not my AGP x700. In addition, it only seems to happen when I'm using MergedFB. If I set MergedFB to '0', I don't have this problem. Basically, what's happening is that my system completely locks up usually after just a few seconds (the earth starts to zoom in). Sometimes it doesn't lockup till I manually grab and move the earth, or actually type in an address. I can't ping the machine and the serial console is unresponsive. Thanks to help from Michel Dänzer on IRC, I was started using git-bisect to track down this problem, using 6.5.2 as a known good, and current Mesa from git as bad. It went well at first, but proceeded down hill :-) Here's the bisect log: git-bisect start # good: [76b1b692688a75986ac7ff2e96d5803a6f154715] remove directfbgl.h file git-bisect good 76b1b692688a75986ac7ff2e96d5803a6f154715 # bad: [95577064040ceeaaf7b0a460f91eac951cf8af18] r300: Use register name add a register about shading. git-bisect bad 95577064040ceeaaf7b0a460f91eac951cf8af18 # good: [89f91d1804c0c4919c25d6b9931973733db1e664] nouveau: Implement much of the fog handling. git-bisect good 89f91d1804c0c4919c25d6b9931973733db1e664 # bad: [b59657ad965f9471574e914b861bb1d2a17d772e] Merge branch 'vbo-0.2' git-bisect bad b59657ad965f9471574e914b861bb1d2a17d772e # good: [876e372567ad44c03b9d9db6e57d3a06b684f6e1] regenerated git-bisect good 876e372567ad44c03b9d9db6e57d3a06b684f6e1 # good: [876e372567ad44c03b9d9db6e57d3a06b684f6e1] regenerated git-bisect good 876e372567ad44c03b9d9db6e57d3a06b684f6e1 # bad: [25b2e50229592ecd4cc3d058471bdee1cb8a0c55] remove remaining traces of r200FlushVertices... git-bisect bad 25b2e50229592ecd4cc3d058471bdee1cb8a0c55 # bad: [25b2e50229592ecd4cc3d058471bdee1cb8a0c55] remove remaining traces of r200FlushVertices... git-bisect bad 25b2e50229592ecd4cc3d058471bdee1cb8a0c55 # good: [8ed319796f35ccd82863a270704752555706f1e2] special case END in _mesa_print_instruction() git-bisect good 8ed319796f35ccd82863a270704752555706f1e2 I'm now getting a problem building the drivers: mklib: Making Linux shared library: libGL.so.1.2 mklib: Installing libGL.so.1.2 libGL.so.1 libGL.so in ../../../lib make[3]: Leaving directory `/home/adamk/workarea/git/mesa/src/glx/x11' make[3]: Entering directory `/home/adamk/workarea/git/mesa/src/mesa' Makefile:186: depend: No such file or directory make[3]: *** No rule to make target `tnl/t_draw.c', needed by `depend'. Stop. make[3]: Leaving directory `/home/adamk/workarea/git/mesa/src/mesa' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/home/adamk/workarea/git/mesa/src' make[1]: *** [default] Error 1 If I do a 'git reset --hard HEAD~5', and then try to build them again, it dies at the same place. So I did a 'git reset --hard HEAD~10', completed a build, did a test run, passed without any problems, and I marked it good. After running git-bisect, I get: Bisecting: 14 revisions left to test after this [70dd0126bd25f2cc2fedae60281ab5c256cb8664] pickup structs from vbo.h Unfortunately, at that point I end up with the same build problems (t_draw.c missing). So, any tips on where I go from here? Has this actually narrowed down the problem to one of a handful of commits? With one of the bad drivers (not the one from current git) I get the following message logged before locking up: Uhhuh. NMI received. Dazed and confused, but trying to continue You probably have a hardware problem with your RAM chips. I've run memtest for about 45 minutes now, completed one pass (it's about half way through a second pass) without any errors, so I'm disinclined to believe this is a RAM issue. Adam - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
