On Tuesday 24 May 2005 22:54, Jerome Glisse wrote: > On 5/24/05, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > > Unfortunately, I don't think so. The thing is, all those OUT_RING and > > ADVANCE_RING commands do not really call into the hardware immediately; all > > they do is write stuff to the ring buffer, but the ring buffer is just some > > memory area without any magic of its own. > > > > Only a call to COMMIT_RING will tell the hardware that new commands are > > waiting in the ring buffer, and the only thing we do know is that > > *something* in the ring buffer before the last COMMIT_RING causes the chip > > to hang. > > > > So another possible way to investigate this could be: > > - Call radeon_do_wait_for_idle() at the end of the COMMIT_RING macro, and > > define RADEON_FIFO_DEBUG (this will print out additional information when > > wait_for_idle fails) > > - Increasingly add COMMIT_RING macros into r300_cmdbuf.c to pinpoint the > > exact location of the problem, if at all possible. > > > > It would be very helpful if you could single out one command we send using > > this procedure. > > > > Note that in the worst case (depending on the actual nature of the lockup in > > hardware), those debugging changes could actually *remove* the lockup (e.g. > > because they remove a race condition that caused the lockup in the first > > place). > > > > Below a sample of what i get when a lockup occur. There is something > that seems strange to me, i saw CP_RB_RTPR change while i am in a > lockup and CP_RB_WTPR increase 6 by 6, I haven't let the things live > for too much time (about 2mins before reboot) but i looks like it > still process ring buffer but slowly.
The increases of the write pointer is easily by 6 dwords is easily explained by radeon_do_cp_idle: This function always emits a series of 6 dwords (cache flushes and stuff) before calling wait_for_idle. My understanding is that these commands make sure the chip is in a completely clean state. Are you sure the read pointer is still moving 2mins after the lockup? That would be rather surprising, to say the least. > Anyway i must misunderstood this > i have to dig up more this drm code to understand it a little more. > > By the way why radeon_cp_flush is disactivated ? The only thing that calls radeon_cp_flush is radeon_cp_stop, which is never called during normal 3D operation and COMMIT_RING should take care of posting the write pointer. I don't know the meaning of bit 31 of WPTR. cu, Nicolai > May 24 21:33:25 localhost kernel: [drm:radeon_do_wait_for_idle] *ERROR* failed! > May 24 21:33:25 localhost kernel: radeon_status: > May 24 21:33:25 localhost kernel: RBBM_STATUS = 0x80010140 > May 24 21:33:25 localhost kernel: CP_RB_RTPR = 0x0003fdf0 > May 24 21:33:25 localhost kernel: CP_RB_WTPR = 0x00000d95 > May 24 21:33:25 localhost kernel: AIC_CNTL = 0x00000000 > May 24 21:33:25 localhost kernel: AIC_STAT = 0x00000004 > May 24 21:33:25 localhost kernel: AIC_PT_BASE = 0x00000000 > May 24 21:33:25 localhost kernel: TLB_ADDR = 0x00000000 > May 24 21:33:25 localhost kernel: TLB_DATA = 0x00000000 2
pgpt4F03RhI60.pgp
Description: PGP signature
