Bumblebee stopped working after upgrade to Slackware 14.2: card0: failed to set DRM interface version 1.4: Permission denied

[zapot]

Hi,

Bumblebee worked well for me with Slackware 14.0, but after upgrading to a new Slackware 14.2, while everything seems to be installed properly I get the following error:

$ optirun glxgears
[ 3202.482729] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
[ 3202.482794] [ERROR]Aborting because fallback start is disabled.

Using default packages for kernel and Xorg:
vmlinuz-huge-4.4.14
xorg-server-1.18.3-x86_64-2

The laptop has card0 -> Intel 915 card1 -> NVIDIA Geforce GT 650M

I have looked at other issues in this tracker and found other people with the "failed to set DRM interface version 1.4: Permission denied", but none of the proposed changes to configuration files work for me.

Can someone help?

Thanks!

[jmfernandez]

Maybe is unrelated. I'm using a completely different system, Gentoo, but I ran in the same issue when I upgraded Xorg server. After some debugging, I tried running secondary Xorg server by hand, and I found secondary Xorg was unsuccessfully loading kbd module (which was not recompiled in the upgrade):

Xorg: symbol lookup error: /usr/lib64/xorg/modules/input/kbd_drv.so: undefined symbol: AddEnabledDevice

This error line is not caught by Xorg.8.log or bumblebee (it is emitted by the dynamic linker), so it does not appear on logs

[hlolli]

Isn't kbd_drv = keyboard module, can't see that this could be related, only based on common sense (which doesn't always hold true of course). But I'd like to hear what some bumblebee contibutor says about this.

[jmfernandez]

Sorry, I did not explain the whole scenario. Just after the symbol lookup error is emitted, Xorg server dies with exit code 127.

So, the problem was not in bumblebee, but affects it due the way bumblebee works: it spawns the secondary Xorg server instance, and it complains when the server unexpectedly dies (as it has to).

[ghost]

Confirmed in fedora 25

[gsgatlin]

@YappyYellowYak Can you open a new issue about the problems you are having in fedora 25? Thanks. Once a new issue is opened maybe we can figure out what has gone wrong on your machine.

[Kinkypeter]

Who supplies your nvidia driver?

…

On 03/06/2017 08:49 AM, gsgatlin wrote: @YappyYellowYak <https://github.com/YappyYellowYak> Can you open a new issue about the problems you are having in fedora 25? Thanks. Once a new issue is opened maybe we can figure out what has gone wrong on your machine. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#841 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAo4FnQF_stFx8acPtariApQ2Mt02EV2ks5rjCshgaJpZM4L3Bnm>.

[zapot]

Hi, original poster here.

I solved the problem on my side. The issue was with an incompatible mix of versions of the various packages. After a lot of fiddling I found a combination of versions which work.

To note is that I followed some of the (general) instructions provided, and that combination of package versions did not work. I looked for a combination of versions released roughly in the same timeframe, and that got me to where I wanted to be.

Note: I am using VirtualGL only (set in bumblebee.conf) , and optirun!

For me the winners were:

nvidia-bumblebee-375.26-x86_64-1_bbsb
nvidia-kernel-375.26_4.4.14-x86_64-1_bbsb
VirtualGL-2.3.3-x86_64-1_bbsb
libvdpau-1.1.1-x86_64-1_bbsb
xf86-video-nouveau-blacklist-noarch-1
primus-0.1.7-x86_64-1_bbsb
bbswitch-0.8_4.4.14-x86_64-1_bbsb
bumblebee-3.2.1-x86_64-1_bbsb
libbsd-0.7.0-x86_64-1_bbsb

I think that one problem with this error is that it seems to capture a wide variety of different situations.
Maybe something could be improved on the error handling side to provide more usable information as part of the error message.

Thanks!