Bug 21509 - libdrm's drmOpenOnce() fd cache stale on X server restart
Summary: libdrm's drmOpenOnce() fd cache stale on X server restart
Status: RESOLVED WONTFIX
Alias: None
Product: DRI
Classification: Unclassified
Component: libdrm (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: low normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-01 10:03 UTC by Chris Fester
Modified: 2019-05-29 17:23 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
patch to xf86drm.c for drmOpenOnce() (866 bytes, patch)
2009-05-01 10:03 UTC, Chris Fester
no flags Details | Splinter Review

Description Chris Fester 2009-05-01 10:03:58 UTC
Created attachment 25341 [details] [review]
patch to xf86drm.c for drmOpenOnce()

Xorg version - custom compiled Xorg 7.4
libdrm version - 2.4.5 (although the problem looks like it's in 2.4.9)

The company I work for runs Xorg in a rather non-standard fashion in that we don't run a window manager.  Recently I was testing a version of Xorg 7.4 that I have compiled.  I was noticing that I could run fgl_glxgears just fine with one invocation.  But every subsequent invocation failed with the X server printing out:
(EE) AIGLX error: drmGetMagic failed
(EE) AIGLX: reverting to software rendering

fgl_glxgears was the only process that I was running under the X server.

After strace-ing the X server, I found that the drmGetMagic ioctl was complaining abut an invalid file descriptor.

Looking deeper I found that the drmOpenOnce function was "re-cycling" file descriptors from the previous server initialization.  After applying the attached patch, things work much better.

I'm not convinced this patch is a good solution.  It would probably be better to have some sort of callback to libdrm for when the server is about to re-load.  When the server does reload it can then purge libdrm's fd cache.  How one would do that I'm not sure.  :)

It is completely possible that since I'm using the ATI provided libraries that they're really the problem here, and they should be cleaning up their used file descriptors on server exit.  My setup would be difficult to convert back to the mesa provided libraries, I can't test that theory.  I'm using the ATI 9.3 driver and libs(can't use 9.4, they deprecated X600 support!).

If anyone needs more information on this report I'm happy to provide it.  I'm not a subscriber to the dri-devel list, so please email me directly - camaronut at gmail.

Thanks!
Chris Fester
Comment 1 Michel Dänzer 2009-05-09 11:27:14 UTC
> It is completely possible that since I'm using the ATI provided libraries that
> they're really the problem here, and they should be cleaning up their used file
> descriptors on server exit.

I suspect that's indeed the case; drmCloseOnce() will only close the file descriptor if it's been called as many times as drmOpenOnce() before, after which drmOpenOnce() wouldn't try to use that file descriptor anymore. So most likely a file descriptor obtained from drmOpenOnce() is incorrectly closed with drmClose() directly.
Comment 2 Adam Jackson 2019-05-29 17:23:54 UTC
drmOpenOnce is now only ever called from the DRI1 loader in Mesa's libGL, which is essentially unsupported since there haven't been DRI1 drivers in 7+ years.


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.