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? > 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).
Forgot to attach the xorg log to illustrate what happened: (**) RADEON(0): FIFO timed out: 0 entries, stat=0x83f96100 (II) RADEON(0): waited for 0 seconds 702523 usecs (EE) RADEON(0): engine still busy not locked up (**) RADEON(0): FIFO timed out: 0 entries, stat=0x83f96100 (II) RADEON(0): waited for 1 seconds -297609 usecs (EE) RADEON(0): engine still busy not locked up Roland -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel