[ I assume you meant to follow up to the list as well ]
On Sam, 2002-01-26 at 19:15, Peter Surda wrote: > > > So I looked at the code: pid 0 doesn't exist, and r128 driver seems to be > > > using it for optimizing searches for free buffer. So I added a > > > "buf->pid > 0 &&" > [cut] > > > > Further investigations showed r128 and radeon where the only driver that > > > actually did a buf->pending = 1, so I changed it to 0 and now the symptoms > > > aren't ocurring anymore. > > > Your changes sound dangerous. :) You're basically removing the tests for > > the errors, or am I missing something? > The first one definitely wasn't correct. A process of pid 0 doesn't exist, but > it has been handled as if it existed. The test ( buf->pid != current->pid ) isn't there for fun. The pid field of the buffer must contain the current process' pid. Looking at r128_freelist_get(), ( buf->pid == 0 ) means the buffer is free, i.e. not supposed to be in use by any process. > As for the second one, I too am not sure I'm not breaking something, but it > fixed the problem and as I said, r128 and radeon are the only drivers > that actually set buf->pending to 1, no other drivers EVER do that. So > I'm assuming r128 and radeon were trying to implement something new, > but it hasn't been completed and is broken. Obviously _something_ related to it is broken, but does that mean the pending field shouldn't be used at all (which is the effect of your changes AFAICS)? Again looking at r128_freelist_get(), the pending field means that the buffer is currently processed by the hardware. After digging around the code a bit, my current theory is that the indirect buffer is incorrectly reused after the start of a new server generation. The only difference I see in the radeon driver (which I assume doesn't have the same problem?) is in the LeaveServer() function, where it releases the indirect buffer. Can you try if that fixes the problem? Another idea is to set info->indirectBuffer to NULL in R128CCEAccelInit(). Please test these ideas, hope one of them works. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
