With drm/mesa/ati from previous Monday and X server from xorg 7.1 or from Saturday dri does no longer work when I log out of gnome and start another session. I have to kill the X server to use dri again. I observed this with a radeon 9250 card. I will try to test a different type of card.
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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.