On Sun, 9 Jun 2002, José Fonseca wrote: > Leif, > > I have had some problems with the DMA code (not just now but since the > beginning of the week). Sometimes get lockups and some crashes quite > easily, others I get bored of jumping around in UT waiting for something > bad to happen.
Anything reproducible, or is it at different places every time? > But finally I got something - please look at the attached dump - it shows > the ring contents. There are two things strange in that picture: > > 1- In the BM_COMMAND value specified in the table head is 0x400001a0 > while the register says 0x40000038 I think this is because the card is decrementing the byte count as it processes the buffer. You'll notice that BM_SYSTEM_MEM_ADDR also looks like it's being incremented as the buffer is processed. I don't think this indicates a problem. The register state looks like the engine locked while processing the buffer at 0x00534000. > 2- The value of BM_SYSTEM_MEM_ADDR in the table head and tail is both > 0x00534000. Although this doesn't mean much since the information pointed > by the tail is garbage left from the previous pass, I have trouble in > believing in coincidences. > > The feeling I get from this is that we are writing to pending buffers > causing the engine to lock. But I don't see how... This only happened in > my testbox (which is rather slow). Have you experienced anything like this? I haven't had any lockups since your changes, apart from once when I was working on the BM_HOSTDATA blit changes, and I haven't had any since I committed my changes. I've done quite a bit of "testing" with various games lately, too. ;) But, as you say, there could be bugs that only crop up on a slower system (I test on a Dell Inspiron 7k laptop w/ PII 400 and a Rage LT Pro 8M AGP 2x). I should mention that I have _EXTRA_CHECKING disabled. I suppose it's possible that the checking code causes a problem, but I'm assuming that you had lockups before adding it. One thing to be aware of is that do_release_used_buffers unconditionally frees all pending buffers, so it should only be called when the card is known to be idle and finished with all pending buffers on the ring. But I think the current code is safe in that respect. Maybe it would help in debugging if you also dump the contents of the buffer pointed to by the head (and maybe the tail if you think there might be a problem there). BTW, did anything come before the ring dump in the log? Do you know where it was triggered from? > I really wanted to get this straight to make a call for testers. Although > on my laptop (Pentium III 700 + Mach64 4MB AGP 2x) glxgears just rised a > single fps with the new DMA, on my testbox (AMD K6 350 + Mach64 8MB AGP > 2x) they've increased from 144 to 235. Tuxracer is about twice the fps > too. UT not really because the CPU has trouble coping with it, but e.g. on > my laptop UT is much smoother. The improvements have just begun and we > really gonna need extensive testing to avoid accumulate bugs and to know > the impact of the improvements on the performance. > > José Fonseca > -- Leif Delgass http://www.retinalburn.net _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
