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. > 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. 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. > Also, there might be an issue where the CP engine expects the ring buffer > to be padded with NOPs in a certain way (say to have pointers always on > 256 bit boundaries) - I don't think we are doing this. Yes, that's what I mentioned in an earlier mail. cu, Nicolai
pgpIU9yrssrmU.pgp
Description: PGP signature
