Concerning "X freezing occasionally", I can confirm, somewhat

[Marty Jack]

I found the, or at least one cause of the, problem.

It is an unhandled select on the DRM FD, causing a loop around the select.  It is stuck because the RegisterBlockAndWakeupHandler that was established in drmmode_pre_init of the Intel driver was lost.  Under normal circumstances this will handle the ready DRM FD.  I guess because of KMS, this is done early now.  It is never redone.  One would assume that the other drivers that are exhibiting the problem might have similar logic.

If there is a server reset, InitBlockAndWakeupHandlers is called inside the loop in server main, which will reinitialize the handler vector and loses the DRM handler.

As a temporary expedient I moved the InitBlockAndWakeupHandlers outside the loop.  This makes the cases that were failing work.  But this might cause the handler array to fill with handler descriptors for the same handler that is being reinstalled over and over, if such a thing were to happen.

It's really up to the server architects to decide how to fix this "properly".  I might suggest that the Init stay outside the loop, and then Register be changed so that if the handler is already registered, it is a no-op.  That seems like it would be the least fragile solution.

On 08/08/2010 07:53 PM, Sergio Monteiro Basto wrote:
> On Sun, 2010-08-08 at 19:09 -0400, Marty Jack wrote: 
>> I am finding that under as yet undiagnosed conditions starting an OpenGL program will cause the server to go into a loop around WaitForSomething.  This happens running Compiz and glxgears and fullscreen Flash video.  If I ssh in at runlevel 3 and run X from one terminal and glxgears twice from another, it works once and then will go into the loop.  Maybe this will help someone who understands server internals better than I do at this point to be able to zero in on what it is.  Once again, Intel 2.12.0, server 1.8.2, Mesa 7.8.2, kernel 2.6.35.
> 
> and if you use Intel 2.11 ? any better ?