Bug 9275

Please attach a full log file that shows the DRI being disabled in the second
generation.

Created attachment 8005 [details]
log of running x server when dri is already unavailable

Does this also happen if you start a 'naked' X server and just run a non-GL
client on it that exits immediately, e.g. xdpyinfo?

If yes, does it also happen if you disable AIGLX?

if I run 
X&
DISPLAY=:0 xdpyinfo
DISPLAY=:0 xdpyinfo

I get the crash in bug 9212, and (most likely) no direct rendering.

Without AIGLX it appears to work correctly. Dri is available after reset, and I
can reset the X server several times.

*** Bug 9212 has been marked as a duplicate of this bug. ***

(In reply to comment #4)
> Without AIGLX it appears to work correctly. Dri is available after reset, and I
> can reset the X server several times.

Sounds like we have a suspect, changing title accordingly.

Out of curiosity, does this also happen with r200_dri.so from Mesa 6.5.1, or
from a git snapshot from before the texmem-0-3-branch merge?

With r200_dri.so from Mesa 6.5.1 it works.

(In reply to comment #7)
> With r200_dri.so from Mesa 6.5.1 it works.

Thanks, my next suspect is drmCloseOnce... would be nice if you could confirm
that with git-bisect in the Mesa tree.

I am not very familiar with git, and I guess I won't have the time to get
familiar  in the near future, sorry.

Created attachment 8168 [details] [review]
Make sure the DRM device is closed in DestroyScreen().

Does this patch help with current Mesa and AIGLX?

*** Bug 8999 has been marked as a duplicate of this bug. ***

Yes, the patch solves the problem with current mesa git.

Without the patch I do net get DRI in second session, with the patch I still get
dri in third session. Tried only glxinfo.

I can also confirm the patch from comment 10 fixes the same DRIScreenInit failed
problem such that DRI is disabled on the second GDM login session problem
running with Xorg 7.2-RC3, libdrm 2.3 and mesa 6.5.2.

Additionally for me, but now fixed with the patch, when logging out of the
second GDM login session with DRI disabled there is fatal error on signal 11, X
exits and is restarted by GDM and hence DRI is working again so perhaps why this
issue has not been noticed earlier.

Keith, what was the rationale for changing this drmClose() to drmCloseOnce()?

The rationale for openOnce/closeOnce was to avoid changing the semantics of the
existing open/close entrypoints, but to provide a mechanism by which I could
ensure shared contexts in a single program, ie multiple contexts on different
threads, would all share the same drm file descriptor and hence all be talking
about ttm allocations in the same way.  (It's getting a bit vague now, but that
was the rough idea).  

I thought that moving the entrypoints into libdrm fixed these problems?  Is
there a need to pull the newest git or upstream libdrm?

I think the problem here is that drmCloseOnce doesn't get called the same number
of times as drmOpenOnce until and including driDestroyScreen. That may be a bug
of itself elsewhere (probably because __glXDRIscreenProbe in glxdri.c calls
drmOpen instead of drmOpenOnce?), but I think driDestroyScreen needs to make
sure the file descriptor is actually closed regardless. This may also require
drmClose/Open to update the bookkeeping used by drmClose/OpenOnce.

Created attachment 8438 [details] [review]
glxdri-aiglx-drmopenonce.patch

Reverting the patch to Mesa from comment 10 and applying the attached patch to
Xserver which changes drmOpen to drmOpenOnce (and also drmClose to
drmCloseOnce) in glxdri.c resolves the problem.

Per comment 16 we may still need to force closure in driDestroyScreen?

(In reply to comment #17)

Thanks, I pushed a slightly extended fix which also uses the third argument to
drmOpenOnce in the same way CallCreateNewScreen() does in libGL.

> Per comment 16 we may still need to force closure in driDestroyScreen?

My gut feeling is yes, but then it should only matter with bugs like this.

The patch in #10 does not work with mga.

However, I haven't tried the later fix yet.

With server 1.2.0, Mesa 6.5.2, and latest mga this still does not work.

Shoul I file a separate bug about mga (it looks like it is broken although ati was fixed)?

Mass version move, cvs -> git