On Fri, Mar 26, 2010 at 08:49:21PM +0100, Rafał Miłecki wrote: > Is this possible reclocking memory in wrong moment (so missing VBLANK > probably) cause lock up? I experienced few already, when I forced > myself to use this code ignoring corruptions. Any other idea what can > cause lock up? I'm 100% sure it's memory reclocking code related.
The first thing is that memory reclocking is definitely missing vblank occasionally - but sometimes that's because the interrupt fires before we get there, and sometimes it's because we're scheduled later. I have some fixes for that. Other corruption is likely to be due to the engine reclocking, which seems to also need to be done in vblank. As far as the lockups go, I think this is due to memory access during reclock. Nothing should be coming from the cp, but we may be getting accesses from the crtc if we miss vblank (there's a bit in the crtc control that can deal with this), but more importantly we're doing nothing to prevent unaccelerated fallbacks touching vram during reclock. I can provoke lockups more easily using x11perf which probably triggers several of those, so I lean towards that being something we need to fix before looking for other potential issues. -- Matthew Garrett | mj...@srcf.ucam.org ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
