On Monday 28 November 2005 02:55 pm, Benjamin Herrenschmidt wrote: > On Mon, 2005-11-28 at 02:18 -0800, vehemens wrote: > > I've been looking at my remaining lockups, and find that I keep coming > > back to the use of scratch registers in the driver for one of them. > > > > If I'm reading the code correctly, the scratch registers are per device, > > not per client. This would mean that you can't run more then one client > > without the potential of one stepping on the other. > > > > My read of the MESA code suggests that a stepped on client could then > > stall out waiting for a condition that would probably never happen > > (non-deterministic anyway). > > > > Does this sound correct, or am I missing something? > > The DRM lock should protect that ... note that I just spotted a DRM fix > "drm: fix quiescent locking" going into the linux kernel that may > explain races with the DRM lock. > > Also, there has been historical issues with the scratch register > writeback. Have you tried disabling writeback via AGP ? > > Ben.
Thanks for the pointers. It helped. What I did find is that I have random lockups during texture updates, and that it's easy to trigger. Still looking into the root cause. Noticed that the surface ioctl's do not have locking yet touch the ring via radeon_apply_surface_regs. Didn't seem to be a problem in my case. Don't all ioctl's that touch the ring need to be locked?? ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
