On Wed, 25 May 2005, Nicolai Haehnle wrote:
On Wednesday 25 May 2005 17:01, Vladimir Dergachev wrote:
Are you sure the read pointer is still moving 2mins after the lockup?
That
would be rather surprising, to say the least.
I think I can imagine how this might be happenning. You see a lockup from
the driver point of view is when the 3d engine busy bit is constantly on.
The read pointer is updated by the CP engine, not the 3d engine. It could
be that something would cause the CP engine to loop around sending
commands to 3d engine forever. This would keep the 3d engine bit on,
update the read pointer and appear to be a lockup to the driver.
What you're saying is, some command that we sent could be misinterpreted by
the 3D engine (or we sent something that we didn't intend to send,
considering lack of docs etc.) as a command that takes insanely long to
complete.
No - because then the read pointer would be stationary. The CP engine
should not submit commands until the 3d engine busy is 0. (but it reacts
faster than we can catch this).
My interpretation was that CP engine just keeps submitting the same
command to 3d engine, without fetching it and just increases the read
pointer all the time.
It might help to dump not only read pointer but also the register showing
the last command executed.
One way to try to make sure this does not happen is to put code in the DRM
driver to control the active size of the ring buffer.
That could be useful for debugging, but that's about it. The thing is, we
*want* to have the ring buffer full. If we didn't want that, we could just
make the ring buffer smaller. But that doesn't really *solve* the problem
either because even very small commands can take an insane amount of time
to finish.
I am thinking that there might be a bug where CP engine does something
funny when the ring buffer is completely full. Maybe we need to keep a
small chunk of space open so that start and end pointers are different.
In any case, it would be interesting to know how fast the RPTR still moves
and if it becomes unstuck at some point. You also need to watch out for
when the X server finally decides to reset the CP. I believe there's a bug
where the X server waits much longer than intended to do this, but the
reset could still mess with results if you're waiting for too long.
Yep.
best
Vladimir Dergachev
-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
