Am Dienstag, 30. Mai 2006 14:33 schrieb Roland Scheidegger: > 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? > 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? > 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, 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).
Progress? -Dieter -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
