[XORG] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied #652
Labels
Comments
|
dmesg output can’t be the right one. It can’t have nothing after 21s if you let it run for 2 days… And dmesg output is the thing we need here. |
|
I am using Pisilinux with bumblebee-3.2.1 and Nvidia 349.16 , Nvidia gtx 970 card; [ 2886.728533] [ERROR]Aborting because fallback start is disabled. Help me please.. |
|
Sorry for delay, but I finally found out that there was isssue in my syslog-ng config. Now I can send you merged log. When I try to run: I'll get the same output as above. Here is merged.log: And here is Xorg.8.log Thanks in advance for any advice. |
|
Just to report the same issue. I'm using Gentoo Linux with Hardened Kernel 4.0.4-r3, nouveau driver 1.0.11, bumblebee 3.2.1 with nVidia GT640M/730M. syslog
lspci |
|
Hi, lspci Xorg.8.log |
|
same issue here with GF630m, with both nouveau and nvidia drivers, running Manjaro with kernel 4.0 and 3.16 i put all the information here: https://forum.manjaro.org/index.php?topic=22991.0 *This GPU is running well in Windows, is not a hardware issue. |
|
Got the same issue (probably, behaves the same at least). What's interesting though is the fact that if I attach an external monitor before trying any kinds of I'm running Debian Jessie on a Thinkpad W530.
Also: |
|
Here is my dmesg with the same issue mentioned above: |
|
Well time to time i try different things waiting for that works, i found a workaround. Is weird but, if i disable de wifi (software) and disconect wired cable, bumblebee and Nvidia GPU works, this is needed one time. The problem is when bumblebee need to switch from intel to nvidia, if program is currently running with nvidia gpu, all the program that run after that first program will work with all networks connected. If i close all programs that run nvidia gpu, and try to open again with primus or optirun, i need to disable networks again. Anyone with this werid behavior? Note: Im using Manjaro 64-bits. Thanks. |
|
I am having this issue, though I will spare you the Xorg output unless you ask. Xorg exits with a status of The following is the relevant kernel logging output: The only message that actually appears to be of concern here is that produced by |
|
I resolved the |
|
I added get this in |
|
I'm having the same issue Lenovo Y50-70 on Debian 8 Jessie with nVidia Geforce 960M GTX and intel card, nvidia driver. and |
|
More info on my case: I have Lenovo y50-70 laptop with nVidia GeForece 960M GTX and Debia Jessie here. I'm trying to get bumblebee to work and with no success. What is strange, after that, when i run cat /proc/acpi/bbswitch i get: the card seems to be ENABLED and there is no way to disable it. sudo tee /proc/acpi/bbswitch <<<OFF doesn't take effect. Here are my conf files (after changes found in tutorials and forums): /etc/bumblebee/bumblebee.conf /etc/bumblebee/xorg.conf.nvidia Here is my DKMS stsus: Log of sudo gedit /var/log/Xorg.8.log after running optirun: System details: This is what I found in dmesg: |
|
I have the same issue, but I wonder if this really is a problem. Adding PS: I also have the ACPI Warning issue, but I don't now if that is related to the drm stuff: |
|
@sherter whether or not it is a problem doesn't matter so much as getting it out of the way for troubleshooting. If we are all having this issue at the same time as having other issues with hybrid graphics (regardless of whether we use bumblebee or kernel-level support), it would be beneficial to get this out of the way, as we can then know whether it is simply an erroneous error or an actual critical issue. To date, there has unfortunately been no resolution. |
|
I guess at the very least a nicer error message would be good (if it is not a problem) - but which upstream project do we go to to ask for it ? |
|
@stuaxo This error appears to originate from the DRM subsystem of the Linux kernel. As such, this issue should be raised on the LKML. It's not immediately apparent what is causing the problem though, since the permission denied error is given regardless of the devices ( |
|
@stuaxo to follow up, a cursory search for similar errors on a wide base of source code would suggest that KMS drivers are given the responsibility of setting DRM interface version, and may produce an error like such when it fails. Knowing the file to which this error belongs would be helpful. |
|
Another update: Going out on a limb, I checked out the source for the version of xorg I am running from git and looked for the error message. This exact error is produced on line 61 of |
|
I've 0 experience on it, but it sounds like finding out the caller might be possible using systemtap ? |
|
@stuaxo quite possibly, but I am not well acquainted with |
|
@stuaxo a quicker (and dirtier) way around the problem to at least determine the next error could be to run the entire process tree as root which, since I assume that |
|
Running optirun as root should exclude any program not running as root. I also wonder, should /dev/dri/card0 be accessed in the first place. I suppose nvidia is at /dev/dri/card1. Looks to me that somehow it isn't getting the right card. /dev/dri/card0 is being used by xorg :0.0, therefore it sounds logical that you get a permission error. |
|
@markbaas well, the |
|
@markbaas also, |
|
So why would it be a fatal error anyway? The actual nvidia card is dri1 right? |
|
@markbaas Sure, but Xorg doesn't know that we don't need dri0 in this case. Unless we either submit a PR to the Xorg mailing list making cursory device probe failures nonfatal, or find a way to make it ignore dri0, it's going to fail out, unfortunately. |
|
Is there no solution to this? |
|
@ryanvade IMO it's not clear. Some research I have done would leads me to believe that this is due to a behaviour quirk in X.org as suggested in my previous comment. When X.org probes graphics devices, it attempts to set the DRM interface version. If this fails, X.org will not enumerate the device, output an error, and move the next device, despite the fact that such a failure does not necessarily indicate that the device is unusable, nor that X.org cannot use it. Though I'm no expert on the internals of X.org. One step to troubleshoot things and see if this is indeed to be-all end-all source of problems for the majority of the posters in this thread would be to apply a fix to X.org to make this failure nonfatal and test that change. Unfortunately, I don't have an environment set up to test X.org, nor would it be terribly convenient for me to set one up. |
|
I'll chime in here with some maybe helpful, maybe unrelated info. |
|
I got the same issue while simultaniously having issues connecting to the internet via a wireless connection. I asked a friend to tunnle me over ethernet and as I turned off my dhcpcd@wlp4s0 , the graphics card suddenly worked again. I have no idea why, but the arch-wiki also tells of this error being related to be unable to connect to localhost. |
|
@jontis Please post the kernel configuration for both kernel versions. The -300 and -301 suffixes are fedora-specific. |
|
I was a little uncertain what you asked for, but hope I got it right. |
|
The .conf files look to be the kernel configuration. I'll diff them and get right back. |
|
@jontis There is no difference between the two. My guess is that between 300 and 301 (I have no idea what git revision that refers to wrt git.kernel.org), the behaviour for |
|
@jontis I'm not terribly familiar with fedora, as such, I cannot (without mailing the devs about it) figure out what revisions 300-301 encompasses. I would appreciate it if you could find that out. Try asking on the issue you opened. |
|
I have listed a bug with them, and they say, just as you do that nothing related to that changed from 300 to 301. |
|
I want to mention that my issues are with the current LTS kernel on Manjaro: 4.1.13 |
|
There are tons of issues mixed here. :package: People with GK card (#652 (comment) for instance) not having nouveau working, this is an upstream bug fixed in kernel 4.4. For everyone having issue with nvidia, please open a new issue describing precisely your problem (this is also valid for you @HalisCz, this thread is too cluttered). I’m closing that mess. ;) |
|
Since this issue and #580 are some of the top Google hits (even the Arch Wiki links to #580 ) for the permission denied issues I'm going to write down my solution for Debian Jessie: downgrade to libdrm*_2.4.56 which can be gotten here http://snapshot.debian.org/archive/debian/20140810T163814Z/pool/main/libd/libdrm/ I downgraded all libdrm* packages I had installed which were, from memory: libdrm-intel1, libdrm-nouveau2, libdrm-radeon1 and libdrm2. |
|
Fixed for myself by applying Manjaro's fix. For a patch for current develop, see here (includes one more pending Manjaro fix). |
bluca
added a commit
to bluca/Bumblebee
that referenced
this issue
May 14, 2016
This always fail due to problems in libdrm, but does not affect Bumblebee's functionality. See Bumblebee-ProjectGH-652 for more details.
|
I have same problem on Lenovo Y50-70 update to kernel 4.5 fixed issue. I can reproduce this when i connect 2'nd monitor and lock screen -> resume -> dead (black screen) |
ArchangeGabriel
pushed a commit
that referenced
this issue
May 19, 2016
This always fail due to problems in libdrm, but does not affect Bumblebee's functionality. See GH-652 for more details.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am using Gentoo with bumblebee-3.2.1 and NVIDIA Corporation GF119M Quadro NVS 4200M
When I try to run:
I'll get:
Here is dmesg:
and here is Xorg.8.log:
Can you help me please?
The text was updated successfully, but these errors were encountered: