From: Leif D. <lde...@re...> - 2002-04-29 00:22:20
|
On Sun, 28 Apr 2002, Leif Delgass wrote: > On Mon, 29 Apr 2002, Jos=E9 Fonseca wrote: >=20 > > On 2002.04.29 00:33 Peter Andersson wrote: > > >>=20 > > >>=20 > > >> hmmm.. OK, here are some questions for you: Did you actually see = the > > >> gears being drawn, or just the window with a black background? > > > I saw the gears. Previously when it crashed to xmon i only saw the=20 > > > window with the black background. So this is the first time for me = when=20 > > > the gears actually get drawn. > > >=20 > > >> If you saw them being drawn, did you see them moving before the lo= ckup? > > > No motion the system hung as soon as it drew the first frame. > >=20 > > This is strange. It seams that it drawed a full frame and copied the = back=20 > > to the front buffer. It's not clear where the fault happened, as it s= hould=20 > > be able to repeat this cicle over and over. > >=20 > > >=20 > > >> When the lockup happened, did the screen blank or did it just free= ze? > > >>=20 > > > It just froze. > >=20 > > I said that u had to make ctrl-alt-del. This in PowerPC means what? C= an u=20 > > still ssh? If yes a backtrace from glxgears would be great. If not ru= nning > >=20 > > DRI_MACH64_DEBUG=3Dall glxgears > dump.txt 2>&1 > >=20 > > would have to do. > > >=20 > Actually turning on all the debugging options when you're not stepping > through in a debugger will probably __cause__ a lockup. Setting a > breakpoint at the SwapBuffers would let you get a frame of output at a > time, but you'd need to compile gears from the Mesa source with debuggi= ng=20 > symbols. OK, scratch that. I forgot that all implies sync, which will wait for=20 idle after each frame, so you should be OK. You probably don't need all=20 the output for primitives though, so I'd use: DRI_MACH64_DEBUG=3Dsync,api,msg,ioctl glxgears > dump.txt 2>&1 --=20 Leif Delgass=20 http://www.retinalburn.net |