Comment 77 for bug 43154

Good question. ;-) I have no answers to that one.

But notice that the bug is not at all random. The bug is fully reproducible each and everytime it happens, and in exactly the same way. Therefore, I can only speculate that in all the offending code, some action is being done in the code that causes a large number of VBLANK's. One operation would be a glFlush I think(which, incidently, seems to be the trigger for the small test case you have written in c). AFAIK it seems to me that a combination of calls that force a lot of VBLANK's seems to be the immediate trigger.

Maybe the way the game uses and clears the texture memory or the way drawing is done on screen is responsible for this. In that case, this speculation makes some sense. Each application has different methods of drawing, texture manipulation etc. So a combination of different methods of calling the DRM handler may be the trigger to this.

But again, your statement is very logical. If the IRQ ACK is not accurate, the interrupts should fire continuously, but it happens under only certain conditions.

Again, note the critical change in behavior. No longer hard lock, but barely responsive. That means something is eating the processor cycles, maybe a sleeping spinlock in a thread or something similar.

We have some work to do! ;-)