Re: [elrepo] RE driver update incompatibility issue
Le 28/01/2013 23:52, Nux! a écrit : On 28.01.2013 21:26, Lamar Owen wrote: The pipe-dream, and a 'better than Windows' experience, is a single package set that covers all legacy versions plus the current version and leverages udev to load the right bits at boot time. I have no clue how difficult that would be to implement, other than it's likely to be pretty hard. As I say, I'm not complaining about the status quo; I'm very grateful for all the work that you do and have done in just getting us the bits packaged, and packaged very well indeed, IMO. Lamar's idea is quite neat! +1 indeed that's a very cool idea. one downside though, it means release a new version of the unified nvidia package every time any one of the driver versions gets an update. So whatever version you actually use, if you stay up to date you'll download and install the new package every time. And that will be a massive download... not a problem if you have a fast network, but for some users this may be painful. Maybe also for the elrepo infrastructure (don't know how developed the mirror system is). Not saying it's a show stopper but it might be worth considering. Another thing: if all kmods are installed, can you make the kernel load the correct one? ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] RE driver update incompatibility issue
Phil Perry wrote: On 29/01/13 19:54, Nicolas Thierry-Mieg wrote: Le 28/01/2013 23:52, Nux! a écrit : On 28.01.2013 21:26, Lamar Owen wrote: The pipe-dream, and a 'better than Windows' experience, is a single package set that covers all legacy versions plus the current version and leverages udev to load the right bits at boot time. I have no clue how difficult that would be to implement, other than it's likely to be pretty hard. As I say, I'm not complaining about the status quo; I'm very grateful for all the work that you do and have done in just getting us the bits packaged, and packaged very well indeed, IMO. Lamar's idea is quite neat! +1 indeed that's a very cool idea. I'll reply to this email first as it's quicker to do than replying to Lamar's post (but I'll get to that!) one downside though, it means release a new version of the unified nvidia package every time any one of the driver versions gets an update. So whatever version you actually use, if you stay up to date you'll download and install the new package every time. And that will be a massive download... not a problem if you have a fast network, but for some users this may be painful. Maybe also for the elrepo infrastructure (don't know how developed the mirror system is). Not saying it's a show stopper but it might be worth considering. I don't actually think it would be too bad. Updates to legacy versions are not that frequent, and often the changelogs indicate the updates aren't relevant to RHEL users anyway. For example, nvidia may backport support for a newer version of Xorg into an old legacy driver, which may be useful for Fedora users but is often irrelevant for us if our version of Xorg is fixed or lagging behind. Thus there's often no need for us to roll out legacy updates. ok, so most of the package updates will happen when the current driver gets updated. This mitigates the (slight) issue, but only for people with modern hardware (who use and want the updated current driver anyway). Users who are on a legacy version will still uselessly download a new package each time current gets updated. Nux mentioned deltarpm, fine for rhel6 but not for rhel5 afaik? Don't get me wrong, I think this is an enticing idea, and there's no issue for me since most of my machines are on fast networks. I'm just trying to think this through and imagine the potential drawbacks before you commit your precious time and energy to it :-) Another thing: if all kmods are installed, can you make the kernel load the correct one? My initial thought would be to install all 4 modules in the form of nvidia-current.ko, nvidia-304.ko etc, and then to use a script to detect the current hardware, select the correct driver and copy that driver into place, and finally running depmod. The script could be run during package installation and then dropped in place (something like /usr/bin/nvidia-select.sh) so the user could manually run it at any time should they update their hardware etc. So to answer your question in the way it is worded, the kernel will always load the correct one as that will be the only one available - the trick is to ensure it is indeed the 'correct' one that is available. sounds great! ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kmod-nvidia-304xx
On 03/18/2015 07:06 PM, Tony Schreiner wrote: I updated a workstation with CentOS-CR and got the new kernel-3.10.0-229.el7.x86_64 I removed kmod-nvidia-304xx and nvidia-x11-drv-304xx, rebooted, and then reinstalled with the latest versions of those. But upon reboot the nvidia module is not installed. The installer did not put anything into /lib/modules/kernel-3.10.0-229.el7.x86_64/ $ rpm -qa *nvidia* nvidia-x11-drv-304xx-304.125-1.el7.elrepo.x86_64 kmod-nvidia-304xx-304.125-1.el7.elrepo.x86_64 nvidia-detect-346.47-1.el7.elrepo.x86_64 Did I miss something? this: http://lists.elrepo.org/pipermail/elrepo/2015-March/002579.html note the part that reads ...elrepo *testing* repository ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] Drivers
On 08/11/2015 02:12 AM, Prakhar Joshi wrote: I have a laptop which has Nvidia GeForce 820M graphics card and Realtek RTL8723BE wireless ethernet card. Both these devices are not detected in CentOS 7. I need drivers for these two devices. Please help. Start by reading these: for nvidia: http://elrepo.org/tiki/nvidia-detect for other drivers, FAQ 4: http://elrepo.org/tiki/FAQ ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] fglrx error - kernel module version does *not* match driver
On 03/22/2016 09:12 PM, Nicolas Thierry-Mieg wrote: On 03/22/2016 06:15 PM, Stephen Isard wrote: Could I be doing something wrong in my (re)installation? I am just using "yum upgrade" (or downgrade) with the elrepo repository enabled. you *are* rebooting after that, right? and what does "modinfo fglrx" say? ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] fglrx error - kernel module version does *not* match driver
On 03/22/2016 06:15 PM, Stephen Isard wrote: Could I be doing something wrong in my (re)installation? I am just using "yum upgrade" (or downgrade) with the elrepo repository enabled. you *are* rebooting after that, right? ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] nvidia-x11-drv and GLVND
On 08/23/2016 11:09 PM, Phil Perry wrote: On 23/08/16 18:28, Phil Perry wrote: So at this point I'd like to have a discussion around our options (maybe there are more that I haven't thought of). Option 1 is obviously the simplest but is difficult to evaluate without knowing the stability of the current drivers so I would propose that I start by releasing a GLVND enabled package set to the testing repo and lets see how we get on with those. If they cause issues with OpenGL applications then we can consider options 2 and/or 3 for providing legacy drivers. For now I've built a GLNVD enabled package set and uploaded them to their respective testing repositories. Packages are syncing to the mirrors. For example: nvidia-x11-drv-367.35-1.glvnd.el5.elrepo.x86_64.rpm nvidia-x11-drv-367.35-1.glvnd.el6.elrepo.x86_64.rpm nvidia-x11-drv-367.35-1.glvnd.el7.elrepo.x86_64.rpm As can be seen above, I've added .glvnd in the release string, which makes these packages a 'newer' version to yum/rpm. Thus, to test simply enable the testing repo and update: yum --enablerepo=elrepo-testing update nvidia-x11-drv\* and yum should pull in the updated GLNVD package(s). Then restart Xorg and test. Looking at the linked libs for any OpenGL application should now show it is linked against /usr/lib64/nvidia/libGLX.so.0 which is one of the new GLNVD libraries: [phil@rhel5 ~]$ ldd /usr/bin/glxgears linux-vdso.so.1 => (0x7fffcfbfd000) libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x2ad652ad) libc.so.6 => /lib64/libc.so.6 (0x00321540) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00321680) libm.so.6 => /lib64/libm.so.6 (0x003215c0) libdl.so.2 => /lib64/libdl.so.2 (0x00321580) libGLX.so.0 => /usr/lib64/nvidia/libGLX.so.0 (0x2ad652d6) libGLdispatch.so.0 => /usr/lib64/nvidia/libGLdispatch.so.0 (0x2ad652f91000) /lib64/ld-linux-x86-64.so.2 (0x00321500) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00321700) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x003216c0) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00321780) [phil@rhel5 ~]$ I've only tested using glxgears. Works as expected for me. If anyone is able to test these builds, please report which distro/arch and what OpenGL apps you've tested with. Assuming there are no major issues, we could consider switching to GLNVD enabled packages for the next major Long-Lived release. Hello, I just tested the dota2 game on centos6 x86_64. This game is run via steam. All seems good: the game starts and runs, the fps seems normal and I didn't notice any visual glitches or problems. This is with: NVIDIA Corporation GK106 [GeForce GTX 660]. I only tested a quick game vs bots but I'll likely do more extensive testing in the next few days and report back if I encounter any issues. $ rpm -qa | grep nvidia yum-plugin-nvidia-1.0.2-1.el6.elrepo.noarch nvidia-x11-drv-32bit-367.35-1.glvnd.el6.elrepo.x86_64 nvidia-detect-367.27-1.el6.elrepo.x86_64 kmod-nvidia-367.35-1.el6.elrepo.x86_64 nvidia-x11-drv-367.35-1.glvnd.el6.elrepo.x86_64 Regards, Nicolas ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
[elrepo] skylake, nvidia, bumblebee
Hello, as mentioned a few weeks ago I am trying to get C7 fully functional on a new Acer Aspire E5-575G-55DE laptop, which has an intel i5-6200U with integrated HD Graphics 520 as well as a nvidia GeForce GTX 950M. Thanks to advice from this list I got the intel graphics to work with the standard EL7 kernel by adding i915.preliminary_hw_support=1 to the kernel options. I then followed the instructions from http://elrepo.org/tiki/bumblebee to install the nvidia kmod and driver, as well as bumblebee. After rebooting I get a "Oh no! Something has gone wrong" screen. I managed to fix this by sudo mv /usr/lib64/xorg/modules/extensions/nvidia/ /usr/lib64/xorg/ and modifying XorgModulePath accordingly in bumblebee.conf . Everything now works: I can now boot in X mode (using the intel gpu) and start applications using the nvidia gpu with optirun. Comparing the Xorg.0.log files between initial (broken) install and after my fix, the main difference is (removing timestamps for readability): BROKEN: (II) LoadModule: "glx" (II) Loading /usr/lib64/xorg/modules/extensions/nvidia/libglx.so (EE) Failed to load /usr/lib64/xorg/modules/extensions/nvidia/libglx.so: libnvidia-tls.so.367.44: cannot open shared object file: No such file or directory (II) UnloadModule: "glx" (II) Unloading glx (EE) Failed to load module "glx" (loader failed, 7) FIXED: (II) LoadModule: "glx" (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.17.2, module version = 1.0.0 ABI class: X.Org Server Extension, version 9.0 (==) AIGLX enabled So it seems that when the nvidia libglx is in /usr/lib64/modules/extensions/nvidia/libglx.so , X tries to load that instead of the correct /usr/lib64/xorg/modules/extensions/libglx.so . This is surprising because in both cases I have: (==) ModulePath set to "/usr/lib64/xorg/modules" The elrepo instructions worked for me on another laptop with intel+nvidia, so I don't understand. I had to fiddle with a bunch of things on this laptop, both for this nvidia problem and to try to get the wifi working, so it's possible I screwed up something. But I've double-checked everything I could think of without finding the culprit. So, does anyone have any ideas why X is picking up the wrong libglx.so here? I'm willing to check any files and test things, I just don't know where to look or what to try now. Thanks, Nicolas ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] skylake and nvidia
On 09/20/2016 04:56 PM, Trevor Hemsley wrote: There was a post made on the forums just recently that said that using |i915.preliminary_hw_support=1 | on the kernel command lijne makes it work for at least some Skylake chips with the standard CentOS kernel. Skylake support is *meant* to be in 7.2 onwards. Beautiful! Thanks Trevor, this works for me with the standard kernel. bumblebee+nvidia doesn't work yet, but at least I can work with the regular kernel and elrepo goodies. I'll investigate bb+nvidia and may get back to the list if I find a solution. | |On 20/09/16 15:46, Nicolas Thierry-Mieg wrote: Hi again, as posted a short while ago, I have a new Acer Aspire E5-575G-55DE laptop and am trying to get C7 running on it. This laptop has an intel i5-6200U with integrated HD Graphics 520. It also has an nvidia GeForce GTX 950M. Installing kmod-nvidia and bumblebee as explained [1] results in the "Oh no! Something has gone wrong" screen. I suspect that's because the regular C7 kernel and xorg-x11-drv-intel don't support the intel 520. Booting into kernel-lt, it seems the intel 520 works...? This is surprising because Farkas Levente's recent post to this list suggested that a newer xorg-x11-drv-intel should be needed, in addition to the newer kernel. But I have a bunch of OK-looking intel messages in /var/log/Xorg.0.log , and glxinfo says: OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Skylake ULT GT2 Question 1: does this mean the intel 520 works fully under kernel-lt? If not, what should I look at? Assuming the intel GPU works under kernel-lt, I could then hope to get nvidia and bumblebee working. I've been using the elrepo nvidia drivers for ages, but I could use the nvidia-provided installer and hope it doesn't clobber anything (which I doubt...). Question 2: any caveats here? Finally I would need to get bumblebee working, otherwise the nvidia stuff is useless. However, bumblebee requires kmod-bbswitch... Question 3: I guess I would have to rebuild bbswitch [2] for kernel-lt, but could I still use the elrepo-provided bumblebee ? Thanks for any advice anyone can provide. Regards, Nicolas [1] http://elrepo.org/tiki/bumblebee [2] https://github.com/Bumblebee-Project/bbswitch ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo -- -------- Nicolas Thierry-Mieg Laboratoire TIMC-IMAG/BCM, CNRS UMR 5525 Pavillon Taillefer, Faculte de Medecine 38706 La Tronche cedex, France tel: (+33)456.520.067, fax: (+33)456.520.055 ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] ath10k
On 09/20/2016 05:29 PM, Phil Perry wrote: On 20/09/16 14:29, Nicolas Thierry-Mieg wrote: Hi, I bought a new laptop for my son, an Acer Aspire E5-575G-55DE, and installed Centos 7 on it. The wireless is: $ lspci -nn | grep Network 03:00.0 Network controller [0280]: Qualcomm Atheros Device [168c:0042] (rev 31) The driver for this is ath10k, so I tried installing kmod-ath10k and ath10k-firmware from elrepo, but no joy: both of these are too old. > Hi Nicolas, Many thanks for the feedback. The wireless stack in RHEL7.2 is backported from kernel-4.1. As such we are pretty much bound to backporting wireless drivers to match the wireless stack, so the current kmod-ath10k driver is backported from kernel-4.1.x. If this driver doesn't support your device, we could look at backporting support for that device to the 4.1.x tree driver. Firmwares can be tricky as they can be version specific, and thus dependant on the driver version. If we know what files are needed then we aim to package them. But at this point it all may be a little academic as I note RHEL7.3 will contain the ath10k driver backported from kernel-4.7 so we will be deprecating our kmod-ath10k package in favour of the distro kernel driver: [phil@Quad RHEL7.3beta]$ rpm -qlp kernel-3.10.0-493.el7.x86_64.rpm | grep ath10 /lib/modules/3.10.0-493.el7.x86_64/kernel/drivers/net/wireless/ath/ath10k /lib/modules/3.10.0-493.el7.x86_64/kernel/drivers/net/wireless/ath/ath10k/ath10k_core.ko /lib/modules/3.10.0-493.el7.x86_64/kernel/drivers/net/wireless/ath/ath10k/ath10k_pci.ko So at this point I'd say if you can carry on using kernel-lt until 7.3 is released, your device should then be natively supported. Thanks for your quick reply. That's great news! I'll just wait for 7.3. ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
[elrepo] ath10k
Hi, I bought a new laptop for my son, an Acer Aspire E5-575G-55DE, and installed Centos 7 on it. The wireless is: $ lspci -nn | grep Network 03:00.0 Network controller [0280]: Qualcomm Atheros Device [168c:0042] (rev 31) The driver for this is ath10k, so I tried installing kmod-ath10k and ath10k-firmware from elrepo, but no joy: both of these are too old. I then installed kernel-lt-4.4.21-1.el7.elrepo.x86_64.rpm . I also copied the 4 files from [1] into /lib/firmware/ath10k/QCA9377/hw1.0/ (creating this subdir), and copying firmware-5.bin_WLAN.TF.1.0-00267-1 as firmware-5.bin : $ pwd /lib/firmware/ath10k/QCA9377/hw1.0 $ ll total 1660 -rw-r--r--. 1 root root 427668 Sep 20 12:24 board-2.bin -rw-r--r--. 1 root root 8124 Sep 20 12:24 board.bin -rw-r--r--. 1 root root 605908 Sep 20 12:24 firmware-5.bin -rw-r--r--. 1 root root 605908 Sep 20 12:24 firmware-5.bin_WLAN.TF.1.0-00267-1 -rw-r--r--. 1 root root 46142 Sep 20 12:24 notice.txt_WLAN.TF.1.0-00267-1 $ I also had to yum install NetworkManager-wifi, I guess it hadn't been installed by C7 because it could not detect any wireless interfaces. Now, booting into kernel-lt 4.4.21-1.el7.elrepo.x86_64 , the wifi works! I am posting this to help others who may have similar hardware, but also as a question / request: could kmod-ath10k and ath10k-firmware from elrepo be updated in order to support these newer wifi chips? Thanks! Regards, Nicolas [1] https://github.com/kvalo/ath10k-firmware/tree/master/QCA9377/hw1.0 ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
[elrepo] skylake and nvidia
Hi again, as posted a short while ago, I have a new Acer Aspire E5-575G-55DE laptop and am trying to get C7 running on it. This laptop has an intel i5-6200U with integrated HD Graphics 520. It also has an nvidia GeForce GTX 950M. Installing kmod-nvidia and bumblebee as explained [1] results in the "Oh no! Something has gone wrong" screen. I suspect that's because the regular C7 kernel and xorg-x11-drv-intel don't support the intel 520. Booting into kernel-lt, it seems the intel 520 works...? This is surprising because Farkas Levente's recent post to this list suggested that a newer xorg-x11-drv-intel should be needed, in addition to the newer kernel. But I have a bunch of OK-looking intel messages in /var/log/Xorg.0.log , and glxinfo says: OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Skylake ULT GT2 Question 1: does this mean the intel 520 works fully under kernel-lt? If not, what should I look at? Assuming the intel GPU works under kernel-lt, I could then hope to get nvidia and bumblebee working. I've been using the elrepo nvidia drivers for ages, but I could use the nvidia-provided installer and hope it doesn't clobber anything (which I doubt...). Question 2: any caveats here? Finally I would need to get bumblebee working, otherwise the nvidia stuff is useless. However, bumblebee requires kmod-bbswitch... Question 3: I guess I would have to rebuild bbswitch [2] for kernel-lt, but could I still use the elrepo-provided bumblebee ? Thanks for any advice anyone can provide. Regards, Nicolas [1] http://elrepo.org/tiki/bumblebee [2] https://github.com/Bumblebee-Project/bbswitch ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] Dual boot rhel 7.5 - gui not starting
On 06/01/2018 02:57 PM, Nicolas Thierry-Mieg wrote: For some reason you keep top-posting on this thread, but whatever. Thanks for forwarding my previous message Akemi, my email address changed and I hadn't updated it. This one should go through. John: that is the same issue I was having. From notes I took at the time: nvidia-x11-drv includes the subdir: /usr/lib64/xorg/modules/extensions/nvidia X.org should not be picking it up for the intel gpu given the bumblebee config, but for some reason it seems it tries to. This leads to a failure to start X. I solved this by: sudo mv /usr/lib64/xorg/modules/extensions/nvidia /usr/lib64/xorg and editing /etc/bumblebee/bumblebee.conf so that XorgModulePath (in the driver-nvidia section) points to the new /usr/lib64/xorg/nvidia/ instead of the old /usr/lib64/xorg/modules/extensions/nvidia/ subdir. I'm sure there's a more elegant solution, but this worked for me. It does require doing the move again each time there's an nvidia driver update... Note that /var/log/Xorg.0.log should have stuff for your primary (intel) gpu, while /var/log/Xorg.8.log should have the nvidia stuff. HTH Over the week-end I took some more time to reinvestigate the issue, in case we actually want to fix it. Note that I have set up bumblebee on two different laptops, both with an intel integrated GPU and a discrete nvidia GPU, both running Centos 7 and installed similarly (nvidia and bumblebee from elrepo). One works fine with the default configuration, the other doesn't and results in the error that the OP ran into. IOW the issue only occurs on some systems... Maybe due to the order in which the 2 GPUs are found by the kernel or by X.org. I don't know. On the broken laptop, with the default configuration, Xorg.0.log has: (==) ModulePath set to "/usr/lib64/xorg/modules" (II) xfree86: Adding drm device (/dev/dri/card1) (EE) /dev/dri/card1: failed to set DRM interface version 1.4: Permission denied (II) xfree86: Adding drm device (/dev/dri/card0) (--) PCI:*(0:0:2:0) 8086:1916:1025:1094 rev 7, Mem @ 0x9200/16777216, 0xa000/268435456, I/O @ 0x5000/64, BIOS @ 0x/131072 (--) PCI: (0:1:0:0) 10de:139a:1025:1094 rev 162, Mem @ 0x9300/16777216, 0x8000/268435456, 0x9000/33554432, I/O @ 0x4000/128, BIOS @ 0x/65536 (II) LoadModule: "glx" (II) Loading /usr/lib64/xorg/modules/extensions/nvidia/libglx.so (EE) Failed to load /usr/lib64/xorg/modules/extensions/nvidia/libglx.so: libnvidia-tls.so.390.59: cannot open shared object file: No such file or directory (II) UnloadModule: "glx" (II) Unloading glx (EE) Failed to load module "glx" (loader failed, 7) Notice that ModulePath doesn't have /usr/lib64/xorg/modules/extensions/nvidia , but X is still trying to load /usr/lib64/xorg/modules/extensions/nvidia/libglx.so . This fails because it doesn't find libnvidia-tls.so.390.59 , but even if it found it (eg if you symlink that lib somewhere) it wouldn't work, because at this point we want X to load the default /usr/lib64/xorg/modules/extensions/libglx.so . There is also the error: /dev/dri/card1: failed to set DRM interface version 1.4: Permission denied I don't know what that means or what role it plays here. But in a working configuration (see below) I also get this error in Xorg.8.log, and it doesn't seem to cause any issues. My kludgy solution to the issue is to move the nvidia libglx.so out of the way: sudo mv /usr/lib64/xorg/modules/extensions/nvidia /usr/lib64/xorg and tell bumblebee where it is now, by setting XorgModulePath in /etc/bumblebee/bumblebee.conf so it now has /usr/lib64/xorg/nvidia/ instead of /usr/lib64/xorg/modules/extensions/nvidia/ . The system then boots succesfully, glxspheres and "optirun glxspheres" work and use the correct GPUs, and Xorg.0.log now has the following instead of the previous lines: (==) ModulePath set to "/usr/lib64/xorg/modules" (II) xfree86: Adding drm device (/dev/dri/card1) (II) xfree86: Adding drm device (/dev/dri/card0) (--) PCI:*(0:0:2:0) 8086:1916:1025:1094 rev 7, Mem @ 0x9200/16777216, 0xa000/268435456, I/O @ 0x5000/64, BIOS @ 0x/131072 (--) PCI: (0:1:0:0) 10de:139a:1025:1094 rev 162, Mem @ 0x9300/16777216, 0x8000/268435456, 0x9000/33554432, I/O @ 0x4000/128, BIOS @ 0x/65536 (II) LoadModule: "glx" (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.19.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 10.0 As you can see, X is now loading /usr/lib64/xorg/modules/extensions/libglx.so , as it should. We also don't have the "failed to set DRM interface". Xorg.8.log shows: (++) ModulePath set to "/usr/lib64/xorg/nvidia,/usr/lib64/xorg/modules/drivers,/usr/lib64/xorg/modules" (II) xfree86: Adding
Re: [elrepo] Dual boot rhel 7.5 - gui not starting
> >>> > uname -a: >>> > 3.10.0-862.3.2.el7.x86_64 >>> > >>> > Thanks in advance >>> > >>> > J >>> >>> You seem to have two graphics devices, an integrated graphics (Intel) >>> and an Nvidia card. Can you disable the former in the BIOS? If this is >>> not possible, you need to make use of the Nvidia Optimus technology. >>> For detailed instructions, please see the bumblebee wiki page at: >>> >>> http://elrepo.org/tiki/bumblebee >>> >>> Akemi > >> Thanks for the tip. >> >> I installed and configured bumblebee (using primus as an alternative to >> optirun). I followed the instructions and machine now hangs when I get to: >> [OK] Started GNOME display Manager. >> [OK] Started Virtualization daemon. > > Did you see any error message while installing the required packages? > No steps missed when configuring it? > > Not using it myself, I cannot provide better support than referring > you to what has already been written. There is an instruction note > given by a CentOS user: > > https://www.centos.org/forums/viewtopic.php?f=49=61162=10#p266381 > > It's basically the same except the addition of the last step (10). > > Akemi I'm copying a message from Nicolas Thierry-Mieg below. Hope this helps you figure out why things are not working. Akemi "you might have some useful info in /var/log/Xorg.* I had set up bumblebee on my son's laptop in the past and had to move some things around, because [some reason, can't remember the details but it was something like X not looking in the correct folders for the 2 cards]. Carefully reading through the Xorg.* logfiles had allowed me to find the source problem. I can look it up one of these evenings if needed." ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
