When nvidia-drivers is compiled without uvm, Gimp doesn't start: $ gimp This is a development version of GIMP. Debug messages may appear here. modprobe: FATAL: Module nvidia-uvm not found in directory /lib/modules/4.3.2-gentoo-dtop-v1 modprobe: FATAL: Module nvidia-uvm not found in directory /lib/modules/4.3.2-gentoo-dtop-v1 modprobe: FATAL: Module nvidia-uvm not found in directory /lib/modules/4.3.2-gentoo-dtop-v1 gimp: fatal error: Naruszenie ochrony pamięci gimp (pid:22354): [E]xit, [H]alt, show [S]tack trace or [P]roceed: e Reproducible: Always Steps to Reproduce: 1. USE=-uvm emerge -1 nvidia-drivers 2. gimp
Hi! I find no traces of calls to modprobe or NVidia specific code in Gimp or Gegl. I guess it's a different package then. Please provide further information. I should mention I do not have an NVidia card myself.
> Please provide further information. What info. do you need?
Ideally, which library is calling modprobe. Maybe dev-util/ltrace can help. Thinking of bug #569738, my guess would be near virtual/opencl.
How about this built-in stack? $ gimp This is a development version of GIMP. Debug messages may appear here. modprobe: ERROR: could not insert 'nvidia_uvm': Unknown symbol in module, or unknown parameter (see dmesg) modprobe: ERROR: could not insert 'nvidia_uvm': Unknown symbol in module, or unknown parameter (see dmesg) modprobe: ERROR: could not insert 'nvidia_uvm': Unknown symbol in module, or unknown parameter (see dmesg) gimp: fatal error: Naruszenie ochrony pamięci gimp (pid:5461): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s #0 0x00007fa8dee41a3b in waitpid () from /lib64/libpthread.so.0 #1 0x00007fa8df7db8f3 in g_on_error_stack_trace () #2 0x00007fa8df7dba4d in g_on_error_query () from /usr/lib64/libglib-2.0.so.0 #3 0x00000000004896ae in ?? () #4 0x00000000004898c6 in gimp_fatal_error () #5 0x0000000000489f48 in ?? () #6 <signal handler called> #7 0x0000000000000000 in ?? () #8 0x00007fa8acd65148 in ?? () from /usr/lib64/libnvidia-opencl.so.1 #9 0x00007fa8acd652a3 in ?? () from /usr/lib64/libnvidia-opencl.so.1 #10 0x00007fa8acd4a277 in ?? () from /usr/lib64/libnvidia-opencl.so.1 #11 0x00007fa8acaa821d in ?? () from /usr/lib64/libnvidia-opencl.so.1 #12 0x00007fa8acaa81b8 in ?? () from /usr/lib64/libnvidia-opencl.so.1 #13 0x00007fa8adbaf1f2 in ?? () from /usr/lib64/libOpenCL.so #14 0x00007fa8adbb0e82 in ?? () from /usr/lib64/libOpenCL.so #15 0x00007fa8adbaf6c1 in clGetPlatformIDs () from /usr/lib64/libOpenCL.so #16 0x00007fa8e07a9fc3 in ?? () from /usr/lib64/libgegl-0.3.so.0 #17 0x00007fa8e07aab9b in ?? () from /usr/lib64/libgegl-0.3.so.0 #18 0x00007fa8e0762de7 in ?? () from /usr/lib64/libgegl-0.3.so.0 #19 0x00007fa8dfb04f75 in g_closure_invoke () #20 0x00007fa8dfb17301 in ?? () from /usr/lib64/libgobject-2.0.so.0 #21 0x00007fa8dfb1fd99 in g_signal_emit_valist () #22 0x00007fa8dfb1ffff in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #23 0x00007fa8dfb09654 in ?? () from /usr/lib64/libgobject-2.0.so.0 #24 0x00007fa8dfb08ebe in ?? () from /usr/lib64/libgobject-2.0.so.0 #25 0x00007fa8dfb0c8fd in g_object_set_valist () #26 0x00007fa8dfb0d13c in g_object_set () from /usr/lib64/libgobject-2.0.so.0 #27 0x00000000007ae446 in gimp_gegl_init () #28 0x0000000000489347 in app_run () #29 0x0000000000488e31 in main ()
/usr/lib64/libOpenCL.so is a symlink to /usr/lib64/OpenCL/vendors/nvidia/libOpenCL.so.1.0.0 probably because I have `eselect opengl set nvidia`.
Grepping for uvm in gegl does not yield any matches. Maybe virtual/opencl needs to depend on x11-drivers/nvidia-drivers[uvm] rather than just x11-drivers/nvidia-drivers? x11, jer -- can you help?
I can confirm this. I use both, gimp-2.9.2 and nvidia-drivers-361.18. When starting gimp via terminal, I get the same error as the OP.
I'm unsure how to continue. Would a runtime blocker like DEPEND="!x11-drivers/nvidia-drivers[-uvm]" help? Would a check pkg_setup help?
gimp runs modprobe?
(In reply to Jeroen Roovers from comment #9) > gimp runs modprobe? Not by itself, no. Not sure yet who does.
OK, then it's the userland libraries that invoke that, and that means there is a direct dependency you must resolve.
Could that mean that the virtual/opencl RDEPEND on >=x11-drivers/nvidia-drivers-290.10-r2 needs to be updated?
As far as I can tell, this is the summary: (1) gegl since version 0.3.0 uses OpenCL (see http://www.gegl.org/NEWS.html "OpenCL support now enabled by default when detected.") (2) media-libs/gegl has no dependency on virtual/opencl (3) nvidia-drivers internally modprobe nvidia-uvm when some OpenCL functionality is needed (functionality that happens to be needed by gegl) So (1) >=media-libs/gegl-0.3.0 maybe needs to depend on virtual/opencl? (2) virtual/opencl should be updated to require uvm support is enabled in versions of nvidia-drivers where required Neither of these should require anything from x11@, so dropping us from Cc.
(In reply to Matt Turner from comment #13) > (1) >=media-libs/gegl-0.3.0 maybe needs to depend on virtual/opencl? > (2) virtual/opencl should be updated to require uvm support is enabled in > versions of nvidia-drivers where required Yes?
*** Bug 591214 has been marked as a duplicate of this bug. ***
(In reply to Matt Turner from comment #13) [...] > (2) virtual/opencl should be updated to require uvm support is enabled in > versions of nvidia-drivers where required > > Neither of these should require anything from x11@, so dropping us from Cc. Well, virtual/opencl is maintained by x11@ :)
(In reply to Jeroen Roovers from comment #14) > (In reply to Matt Turner from comment #13) > > (1) >=media-libs/gegl-0.3.0 maybe needs to depend on virtual/opencl? it seems opencl is not keyworded on alpha and ~amd64-fbsd, hence, gegl would lose the keyword there
(In reply to Pacho Ramos from comment #17) > (In reply to Jeroen Roovers from comment #14) > > (In reply to Matt Turner from comment #13) > > > (1) >=media-libs/gegl-0.3.0 maybe needs to depend on virtual/opencl? > > it seems opencl is not keyworded on alpha and ~amd64-fbsd, hence, gegl would > lose the keyword there Looking at the code in gegl (gegl_cl_init_load_functions) it seems that OpenCL is dlopened if available. So gegl works without opencl, and thus it should not have a dependency on virtual/opencl. Feel free to bump virtual/opencl with a dependency on nvidia-drivers[uvm].
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7e09af1d59223fb58ebdada71cbea9d7f9dce8ca commit 7e09af1d59223fb58ebdada71cbea9d7f9dce8ca Author: Pacho Ramos <pacho@gentoo.org> AuthorDate: 2019-04-19 22:39:17 +0000 Commit: Pacho Ramos <pacho@gentoo.org> CommitDate: 2019-04-19 22:39:50 +0000 virtual/opencl: nvidia-drivers[uvm] is needed (#572496) Bug: https://bugs.gentoo.org/572496 Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Pacho Ramos <pacho@gentoo.org> virtual/opencl/opencl-0-r6.ebuild | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
ok, when do you think that would be possible to stabilize the newer virtual? (to stabilize gimp-2.10 with it) Thanks
(In reply to Pacho Ramos from comment #20) > ok, when do you think that would be possible to stabilize the newer virtual? > (to stabilize gimp-2.10 with it) > > Thanks Yep, feel free! (Maybe do it as a part of gimp-2.10 stabilization?)
Sure, thanks! :D
