On Tue, 2006-05-30 at 14:33 +0200, Roland Scheidegger wrote: > Michel Dänzer wrote: > > On Tue, 2006-05-30 at 02:42 +0200, Roland Scheidegger wrote: > >> Looks like quite some more work is needed to detect real lockups but not > >> just randomly reseting the chip when there is none (which can itself > >> lead to lockups IME). > > > > Maybe, or maybe it's just a matter of sticking RADEONCP_STOP()s in the > > right places, ala https://bugs.freedesktop.org/show_bug.cgi?id=1889 . > Since the box is down, I assume this only refers to the lockups which > can be caused by reseting the engine?
Yes. I think resetting the engine without at least trying to properly stop the CP is hazardous at any rate. > In any case, I can't see a good reason why you'd want to reset the chip > when it has, in fact, not locked up. > I've done some quick test hack (attached) which did fix the problem with > gltestperf for me (system was really unresponsive during the benchmark, > though), together with that EBUSY fix. > Apparently, on my box, the FIFO wait time is probably a bit short > (roughly 0.7 seconds), maybe something with a real timebase should be > used rather than just 2 million INREGS? Indeed. The X server's GetTimeInMillis() might be more convenient than gettimeofday() (and would also work with an elfloader X server ;). > For determining if the chip has locked up I just used the ZPASS_DATA reg > (assuming that as long as the chip outputs fragments it has not locked > up - of course you could hack up some gl test program where all > fragments fail the z test, Will this still increase if the depth buffer/test is disabled? > but I'm not sure there's a better reg to monitor activity - ring ptr might > be another possibility, but I think this can point at the same location for > a long time too (for instance when drawing using the idx buf command). One of the performance counters might be better. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
