On Wed, 5 Jun 2002, Tim Smith wrote:
> 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...
Can you try modifing wait_for_fifo function in the driver and drm module
to *not* reinitialize display hardware if lockup is detected ?
The reason is that I seen something similar while doing v4l driver for
radeons. In my driver wait_for_fifo does not reinit anything (it does not
know what to do) but simply prints a message.
It turns out that (sometimes, when, for example you are moving a window
around) there are enough commands to be processed by radeon engine that it
takes longer than the loop in wait_for_idle/fifo.
I don't know of any "right" way to detect whether the engine has indeed
locked up.
Vladimir Dergachev
>
>
> --
> 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
>
_______________________________________________________________
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
