From: F. <j_r...@ya...> - 2002-07-14 14:57:06
|
On Thu, Jul 04, 2002 at 06:49:32PM +0100, José Fonseca wrote: > On Thu, Jul 04, 2002 at 12:58:13PM -0500, David Willmore wrote: > > > >I had a lockup on an older version of the mach64 DRI driver, so > >I thought I'd retest with a newer one. gltestperf locks up (no > >response to keyboard, but mouse still moves--it locked up as well > >in the older version) on the ZSmooth Triangles size:480 test. > >Not immediately, but it locks up after the second set of triangles > >and maybe early into the third. > > > > Thanks for the report. > > >Here's the relivant stuff from the kernel messages: > [...] > > > >There may have been more, but it didn't make it to the log. > > > >Any more logging/system configuration info needed? > > > > I'm going to see if I can reproduce it when I finish the current round > of changes. > Ok. I've determined the cause of this one: gltestperf floods with DMA buffers enough to keep the chip busy for more than 1sec (the current timeout) so the DRM thinks the chip locked..! For instance changing the following line of mach64_ring_idle in mach64_dma.c for ( i = 0 ; i < dev_priv->usec_timeout; i++ ) { to for ( i = 0 ; i < dev_priv->usec_timeout << 4; i++ ) { does the trick. But we need a more robust implementation of mach64_ring_idle. Since we probably want to keep the timeout small my suggestion is to count the time that takes for the ring head pointer to advance instead of counting the time it takes to finish processing all ring entries. Any other ideas? Have other driver ever faced problems like this one? José Fonseca |