On Sat, 31 May 2003, Paul Mackerras wrote: > José Fonseca writes: > > > On Wed, May 21, 2003 at 10:38:45PM +1000, Paul Mackerras wrote: > > > * The hang always occurs within a mach64_dma_dispatch_vertex call for > > > primitive 8 (MACH64_PRIM_QUAD_STRIP), at least with glxgears. > > > > glxgears only uses quads primitives, so the primitive is not relevant > > here. > > Hmmm, I am _definitely_ observing calls to mach64_dma_dispatch_vertex > with prim = 8 while running glxgears. And it is the one that seems to > cause the trouble.
You're talking about sync/async DMA mode here, right? Have you tried some of the other Mesa demos? It would be useful to see what other apps do or don't cause a lockup, if it is always in dispatching vertex buffers, and if the type of primitive is the same or not. I'm inclined to agree with Jose that the primitive type shouldn't matter, but it's worth looking into. > > > * I can get it to hang in mmio mode running glxgears if I make > > > mach64_dispatch_pseudo_dma() just wait for space in the FIFO (or even > > > for the FIFO to be empty) rather than waiting for the engine to be > > > idle every 16 words. > > > > Was this using direct MMIO or HOST_TO_DATA? > > MMIO. Here's some more info on HOSTDATA: In MMIO/pseudo-DMA mode, when we see a descriptor with BM_HOSTDATA as the GUI master target register (rather than BM_ADDR), we feed the blit data to the card through the HOST_DATA[0-15] registers, so it's still MMIO. The thing we have to be careful of is that you can't wait for idle between writes that set up the blit and the writes of the blit data to the HOST_DATA registers, or else the engine will lock up. That's what the "no_idle_wait" flag is for in the pseudo-DMA dispatch code. The docs say that full FIFO discliple must be maintined when writing to the HOST_DATA registers, which means checking for enough FIFO entries. The registers are sequential, so you can do an assembly optimized memcpy of 16 32-bit words at a time, checking the fifo between copies. When doing DMA to BM_HOSTDATA, the assumption is that the engine takes care of FIFO discipline (BM_HOSTDATA isn't really documented well). At any rate, this doesn't apply to gears since it doesn't use textures. > > > Can anyone give me any pointers about how to get this chip going > > > properly? > > > > From what you describe here I see three explanations: > > - there is some kind of caching corrupting the data from/to the > > hardware, which is specific to some of the PPC architectures > > That would not explain how I can get the chip to hang when I am > feeding it with MMIO. > > > - the driver is emitting bad 3D data - this is IMHO unlike since some > > other people have no problems with PPC and > > I also think this is unlikely, given that it works fine in MMIO mode > (as long as I use the normal code which waits for the engine to be > idle every 16 words). > > > - your hardware is buggy - I had problems in the past with an AGP > > controller, but AFAIK the AGP isn't used in PPC, so I don't know what > > could be in fault. > > Later powerbooks (PPC laptops) have AGP, but not this one. I have AGP > on my titanium G4 powerbook, which has a Rage 128 chip, for instance. > > This chip (3D Rage LT Pro, code 'LI') does have some bugs; for > instance, 2D diagonal lines sometimes get drawn incorrectly (most > noticeable with xpilot). So it is quite possible that there is a > hardware bug. This is the same chip I have (also rev. dc) on x86, but mine is AGP. The lockups you are describing sound identical to previous reports on PPC, iirc. MMIO works, but sync and async DMA cause lockups. Also, we originally tried waiting for 16 FIFO entries instead of waiting for idle in the "pseudo-DMA" path. It works for me on x86, but it caused lockups for ppc users. For DMA, the condition where the FIFO is empty, but GUI_ACTIVE is set in GUI_STAT is a symptom of an engine lock-up, which could be caused by a number of things. I've definitely seen that state many times before, so I don't think it necessarily indicates a hardware bug. I remember other reports on ppc where the engine would lock in this state at the last descriptor in the ring. You should be able to get a (partial) dump of the ring contents by loading the kernel module with "drm_opts=debug". -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
