On Friday 31 May 2002 4:54 pm, Tim Smith scribed numinously:" > On Friday 31 May 2002 4:12 pm, Keith Whitwell scribed numinously:" > > > Tim Smith wrote: > > > Me too. Could this be a locking problem? There seem to be two > > > contexts owned by the same PID in this case, and the > > > LOCK_TEST_WITH_RETURN() macro only tests that the PID is the same as > > > the currently holding PID, not the context. > > > > Oh, that's interesting... > > I'm going to add a trace to that macro tonight and see if anything bad is > actually happening of that nature.
OK, I did this, and I can't see anything bad happening there. I see ioctl calls to get the lock for a pid and context and then that same pid and context until the next lock. I've also traced out the CP_RB_RPTR and CP_RB_WTPR values and the write pointer never seems to get more than a 25-30 kbytes (max < 7000 words) ahead of the read pointer, which in a 1MB buffer doesn't seem like a problem. So the question I have to ask myself is, why on earth does adding what should be basically nothing but a delay (an extra wait_for_fifo) in the code that merely happens to be used in big chunks of commands (emit_packet3_cliprect) cause the problem to go away? I am confused... -- Tim Smith ([EMAIL PROTECTED]) Palpatine's left leg seen in love tryst with Imperial Advisor Ars Dangor. _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
