On Sun, Jan 27, 2002 at 06:03:42PM +0100, Michel Dänzer wrote: > [ I assume you meant to follow up to the list as well ] yes it is possible I failed to do so.
> > 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.
Yes, exactly. But this test fails if buf->pid == 0, which is wrong. Hence I
added this test. See "added", not "deleted" or "replaced"
> Looking at r128_freelist_get(), ( buf->pid == 0 ) means the buffer is
> free, i.e. not supposed to be in use by any process.
Yes thats exactly what I'm talking about, this isn't tested though in other
places.
> Obviously _something_ related to it is broken, but does that mean the
> pending field shouldn't be used at all
Definitely, that's why I said my patch is most probably incorrect, but it
solved my problems nevertheless (at least I think so). Basically I am too
stupid to fix it correctly so I'm just curing the symptoms.
> 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.
I too think this is the most probable cause.
> The only difference I see in the radeon driver (which I assume doesn't have
> the same problem?)
Well, noone reported it so no idea.
> 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().
Sounds reasonable, I'll try it. I hope I'll be around on tomorrows irc
meeting, we can try stuff in realtime then :-)
> Please test these ideas, hope one of them works.
Sure dude.
Bye,
Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023
--
0 and 1. Now what could be so hard about that?
msg02553/pgp00000.pgp
Description: PGP signature
