[opensuse] graphics problems with intel (single windows flickering) - still no solution for optimus?
Hello,
I still suffer from my expensive useless laptop. Besides that the nvidia card is not running no way, even the intel graphics makes problems:
sometimes (often!) one window or one message (like the alert when mails arrive) flickers.
In text windows like this email or in kwrite or in console sometimes the text hops up and down some lines, sometimes freshly written text appears and disappears and the former text lines reformat. Sometimes a website in firefox (or any other browser) flickers, hops up and down for maybe 50 pixels, sometimes in digikam the album tree appears and disappears.
It happens always just in one window, sometimes one in the background (so the visible part flickers), sometimes the active one.
If text flickers (moves up and down etc.) sometimes I can solve it if I scroll a bit and it keeps quiet for a while...
All /really/ annoying.
So: still the question: is there any way to make the nvidia graphics run on Linux?
and: how can I accomplish that at least the weak intel graphics do the normal work? I already accepted that on this laptop I cannot view high res videos, but at least that flickering should go away, somehow...
This is opensuse 42.3, KDE on a Asus GL552V laptop, i7 6700, optimus graphics (intel graphics cannot be disabled in BIOS, I checked)
Any new ideas more than welcome!
Daniel
Le 13/07/2018 à 14:05, Daniel Bauer a écrit :
Any new ideas more than welcome!
what driver, proprietary or open?
I have an asus 550N that seems very similar to yours and that works on 42.3
my screen being only 1366x768, I even managed to have full HD 1080p working.
optimus seems to work, but not with visible better speed
nouveau driver
may be obsolete doc
http://dodin.org/wiki/pmwiki.php?n=Doc.OptimusVideo
jdd
Daniel Bauer wrote:
Hello,
I still suffer from my expensive useless laptop. Besides that the nvidia card is not running no way, even the intel graphics makes problems:
sometimes (often!) one window or one message (like the alert when mails arrive) flickers.
In text windows like this email or in kwrite or in console sometimes the text hops up and down some lines, sometimes freshly written text appears and disappears and the former text lines reformat. Sometimes a website in firefox (or any other browser) flickers, hops up and down for maybe 50 pixels, sometimes in digikam the album tree appears and disappears.
You are using the intel driver( xf86-video-intel). That one has the same issues on my laptop, it's hardly usable.
Likely mentioned before: Remove it (rpm -e xf86-video-intel). Then the default Mesa modesetting driver should be used. That one does run better. I'm on Tumbleweed, there the latest version of modesetting has issues with changing resolution (e.g., via xrandr) but 42.3 is likely not affected by that.
So: still the question: is there any way to make the nvidia graphics run on Linux?
Depends what you call 'make run'. I'm also having an optimus (HD530/940MX) on my Lenovo T460p. I only use it for some programs. For that I use bumblebee, from the X11:Bumblebee repository. IIRC there's a portal page somewhere. basically you need bumblebee, primus, bbswitch, nvidia-bumblebee (and their dependencies). I can nicely run stuff on my nvidia card using optirun application
e.g.,
woodstock:~% optirun glxspheres Polygons in scene: 62464 (61 spheres * 1024 polys/spheres) Visual ID of window: 0x13c Context is Direct OpenGL Renderer: GeForce 940MX/PCIe/SSE2 62.371853 frames/sec - 69.606987 Mpixels/sec
On 13.07.2018 14:20, Peter Suetterlin wrote:
Daniel Bauer wrote:
sometimes (often!) one window or one message (like the alert when mails arrive) flickers.
In text windows like this email or in kwrite or in console sometimes the text hops up and down some lines, sometimes freshly written text appears and disappears and the former text lines reformat. Sometimes a website in firefox (or any other browser) flickers, hops up and down for maybe 50 pixels, sometimes in digikam the album tree appears and disappears.
You are using the intel driver( xf86-video-intel). That one has the same issues on my laptop, it's hardly usable.
Likely mentioned before: Remove it (rpm -e xf86-video-intel). Then the default Mesa modesetting driver should be used. That one does run better. I'm on Tumbleweed, there the latest version of modesetting has issues with changing resolution (e.g., via xrandr) but 42.3 is likely not affected by that.
I entered this "rpm -e xf86-video-intel" as root. There was no feedback from the system, simply the command prompt appeared on the next line. I checked in Yast and searching for xf86-video-intel shows to packages, none installed.
So: still the question: is there any way to make the nvidia graphics run on Linux?
Depends what you call 'make run'.
Most beautiful was suse-prime when it still worked: I could simply switch between both graphics cards.
As this is not available anymore (or does not work) I'd prefer to have simply using the nvidia card all the time (I mostly use the laptop plugged to electricity so I don't care too much about battery life)
I'm also having an optimus (HD530/940MX) on
my Lenovo T460p. I only use it for some programs. For that I use bumblebee, from the X11:Bumblebee repository. IIRC there's a portal page somewhere. basically you need bumblebee, primus, bbswitch, nvidia-bumblebee (and their dependencies). I can nicely run stuff on my nvidia card using optirun application
e.g.,
woodstock:~% optirun glxspheres Polygons in scene: 62464 (61 spheres * 1024 polys/spheres) Visual ID of window: 0x13c Context is Direct OpenGL Renderer: GeForce 940MX/PCIe/SSE2 62.371853 frames/sec - 69.606987 Mpixels/sec
I always refrained from using bumblebee, because
- I'd have to start programs from command line, but most of my work is using "open with" in digikam to open kuickshow and gimp, or clicking in dolphin with the same goal. Often several images at a time. Opening the images from command line or again selecting file-open within GIMP etc. would make impossible my work flow and cause /much/ more time and effort plus source of errors
- how could I enable nvidia this way for a windows session in Virtualbox? There I process the huge (50MB) photo files from my camera and a strong graphics card would be so very much appreciated - the reason I bought this laptop...
Do I se this wrong. If so, correct me please.
On 07/13/2018 08:38 AM, Daniel Bauer wrote:
- how could I enable nvidia this way for a windows session in Virtualbox?
There I process the huge (50MB) photo files from my camera and a strong graphics card would be so very much appreciated - the reason I bought this laptop...
Do I se this wrong. If so, correct me please.
Daniel,
For Virtualbox Win7, there is nothing you enable for nvidia. Virtualbox provides the virtualbox-guest-additions driver for Win7 that will use 2D hardware acceleration by default if present on your Host. So other than configuring your normal openSuSE display with whatever driver you are using and then loading the virtualbox-guest-additions in Win7, there isn't anything to do.
I would avoid tweaking the virtualbox-guest-addition to use 3D hardware acceleration unless you absolutely have to. (there is a procedure that will enable Aero to run in Win7 -- but it is labeled (and is) experimental, and is hit or miss. (not to mention makes the guest prone to the behavior you are trying to avoid)
As for the odd disappearing and reappearing text (in just one window?), I have seen driver oddness on some of my older boxes where the screen with flicker (and in some cases flash one/off momentarily ever couple of seconds), but have not had problems of that kind Leap 42 came out.
(side-note: your `rpm -e name.rpm` will not provide any output unless you also give the `-v` option -- it just does the removal without any feedback unless there is an error)
I have had very good luck with both nouveau and nvidia drivers on Leap 42. No issues at all with either. (the nouveau driver performs on-par with nvidia in all but the high-motion full-screen use, like desktop-cube in plasma or full-screen video). If you just use your box for normal coding or word processing, etc.. you won't notice any difference (but your graphics card will run cooler with nouveau).
That said, the nvidia install is a simple install. Just add the nvidia repo and use yast to select the driver you need based on your card. E.g., just add:
https://download.nvidia.com/opensuse/leap/42.3/
(adjust for your Leap version)
and fire up yast software management and select your driver. If you use yast, the drm_ issues are handled properly without you having to remove the drm_ for the kernel, etc..
The only other thought I had was to make sure you do not have other xf86 drivers installed. It would be odd that there was a conflict, but if you have multiple drivers installed and nothing black-listed, I can see issues there. It also sounds like you have multiple cards in your laptop -- I don't know if you can select/disable one in the BIOS, but that would be something else to investigate.
On 13.07.2018 19:28, David C. Rankin wrote:
On 07/13/2018 08:38 AM, Daniel Bauer wrote:
- how could I enable nvidia this way for a windows session in Virtualbox?
There I process the huge (50MB) photo files from my camera and a strong graphics card would be so very much appreciated - the reason I bought this laptop...
Do I se this wrong. If so, correct me please.
Daniel,
For Virtualbox Win7, there is nothing you enable for nvidia. Virtualbox provides the virtualbox-guest-additions driver for Win7 that will use 2D hardware acceleration by default if present on your Host. So other than configuring your normal openSuSE display with whatever driver you are using and then loading the virtualbox-guest-additions in Win7, there isn't anything to do.
I have a win XP and a Win 10 guest. I guess they run with the graphics provide by the host (my leap 42.3). So I think (maybe I am wrong?) that when my leap 42.3 runs intel graphics, the guests will run on itle graphics too, and if 42.3 runs on nvidia, the guest will use that, too.
... As for the odd disappearing and reappearing text (in just one window?), I have seen driver oddness on some of my older boxes where the screen with flicker (and in some cases flash one/off momentarily ever couple of seconds), but have not had problems of that kind Leap 42 came out.
(side-note: your `rpm -e name.rpm` will not provide any output unless you also give the `-v` option -- it just does the removal without any feedback unless there is an error)
I removed xf86-video-intel and logged out/in and some flickering still occurs :-(
I have had very good luck with both nouveau and nvidia drivers on Leap 42. No issues at all with either. (the nouveau driver performs on-par with nvidia in all but the high-motion full-screen use, like desktop-cube in plasma or full-screen video). If you just use your box for normal coding or word processing, etc.. you won't notice any difference (but your graphics card will run cooler with nouveau).
I exactly would like to use it to edit 4k- and HD-videos. I mostly use it to edit huge photo files.
That said, the nvidia install is a simple install. Just add the nvidia repo and use yast to select the driver you need based on your card. E.g., just add:
https://download.nvidia.com/opensuse/leap/42.3/
(adjust for your Leap version)
I have this repo and there are nvidia drivers installed. Recently I removed them with Yast but then automagically new, other, nvidia packets were installed.
and fire up yast software management and select your driver. If you use yast, the drm_ issues are handled properly without you having to remove the drm_ for the kernel, etc..
Due to the many tests it is quite possible that there is kind of a mess in my installation, but I don't know how to clean it up and get it into a virgin state...
The only other thought I had was to make sure you do not have other xf86 drivers installed. It would be odd that there was a conflict, but if you have multiple drivers installed and nothing black-listed, I can see issues there.
There's a lot of xf86 installed here:
S | Name | Zusammenfassung | Typ ---+----------------------+-------------------------------------------------------+------ i+ | libXxf86misc1 | XFree86-Misc X extension library | Paket i+ | libXxf86vm1 | XFree86-VidMode X extension library | Paket i+ | libXxf86vm1-32bit | XFree86-VidMode X extension library | Paket i+ | xf86-input-evdev | Generic Linux input driver for the Xorg X server | Paket i+ | xf86-input-joystick | Joystick input driver for the Xorg X server | Paket i+ | xf86-input-keyboard | Keyboard input driver for the Xorg X server | Paket i+ | xf86-input-libinput | Libinput driver for the Xorg X server | Paket i+ | xf86-input-mouse | Mouse input driver for the Xorg X server | Paket i+ | xf86-input-synaptics | Synaptics touchpad input driver for the Xorg X server | Paket i+ | xf86-input-vmmouse | VMware Mouse input driver for the Xorg X server | Paket i+ | xf86-input-void | Null input driver for the Xorg X server | Paket i+ | xf86-input-wacom | Wacom input driver for the Xorg X server | Paket i+ | xf86-video-amdgpu | AMDGPU video driver for the Xorg X server | Paket i+ | xf86-video-fbdev | Framebuffer video driver for the Xorg X server | Paket i+ | xf86-video-vesa | Generic VESA video driver for the Xorg X server | Paket
I think the mouse, touchpad etc. things are needed, no?
It also sounds like you have multiple cards in your laptop -- I don't know if you can select/disable one in the BIOS, but that would be something else to investigate.
There is no option in the BIOS to disable or select one of the cards. As much as I know there'sthe onboard intel graphics and an extra nvidia geforce GTX 960 M.
Op vrijdag 13 juli 2018 21:09:42 CEST schreef Daniel Bauer:
On 13.07.2018 19:28, David C. Rankin wrote:
On 07/13/2018 08:38 AM, Daniel Bauer wrote:
- how could I enable nvidia this way for a windows session in Virtualbox?
There I process the huge (50MB) photo files from my camera and a strong graphics card would be so very much appreciated - the reason I bought this laptop...
Do I se this wrong. If so, correct me please.
Daniel,
For Virtualbox Win7, there is nothing you enable for nvidia. Virtualbox
provides the virtualbox-guest-additions driver for Win7 that will use 2D hardware acceleration by default if present on your Host. So other than configuring your normal openSuSE display with whatever driver you are using and then loading the virtualbox-guest-additions in Win7, there isn't anything to do.
I have a win XP and a Win 10 guest. I guess they run with the graphics provide by the host (my leap 42.3). So I think (maybe I am wrong?) that when my leap 42.3 runs intel graphics, the guests will run on itle graphics too, and if 42.3 runs on nvidia, the guest will use that, too.
...
As for the odd disappearing and reappearing text (in just one window?), I
have seen driver oddness on some of my older boxes where the screen with flicker (and in some cases flash one/off momentarily ever couple of seconds), but have not had problems of that kind Leap 42 came out.
(side-note: your `rpm -e name.rpm` will not provide any output unless you
also give the `-v` option -- it just does the removal without any feedback unless there is an error)
I removed xf86-video-intel and logged out/in and some flickering still occurs :-(
I have had very good luck with both nouveau and nvidia drivers on Leap 42.
No issues at all with either. (the nouveau driver performs on-par with nvidia in all but the high-motion full-screen use, like desktop-cube in plasma or full-screen video). If you just use your box for normal coding or word processing, etc.. you won't notice any difference (but your graphics card will run cooler with nouveau).
I exactly would like to use it to edit 4k- and HD-videos. I mostly use it to edit huge photo files.
That said, the nvidia install is a simple install. Just add the nvidia repo
and use yast to select the driver you need based on your card. E.g., just
add:
https://download.nvidia.com/opensuse/leap/42.3/
(adjust for your Leap version)
I have this repo and there are nvidia drivers installed. Recently I removed them with Yast but then automagically new, other, nvidia packets were installed.
and fire up yast software management and select your driver. If you use yast, the drm_ issues are handled properly without you having to remove the drm_ for the kernel, etc..
Due to the many tests it is quite possible that there is kind of a mess in my installation, but I don't know how to clean it up and get it into a virgin state...
The only other thought I had was to make sure you do not have other xf86
drivers installed. It would be odd that there was a conflict, but if you have multiple drivers installed and nothing black-listed, I can see issues there.
There's a lot of xf86 installed here:
S | Name | Zusammenfassung | Typ ---+----------------------+---------------------------------------------- ---------+------ i+ | libXxf86misc1 | XFree86-Misc X extension library | Paket i+ | libXxf86vm1 | XFree86-VidMode X extension library | Paket i+ | libXxf86vm1-32bit | XFree86-VidMode X extension library | Paket i+ | xf86-input-evdev | Generic Linux input driver for the Xorg X server | Paket i+ | xf86-input-joystick | Joystick input driver for the Xorg X server | Paket i+ | xf86-input-keyboard | Keyboard input driver for the Xorg X server | Paket i+ | xf86-input-libinput | Libinput driver for the Xorg X server | Paket i+ | xf86-input-mouse | Mouse input driver for the Xorg X server | Paket i+ | xf86-input-synaptics | Synaptics touchpad input driver for the Xorg X server | Paket i+ | xf86-input-vmmouse | VMware Mouse input driver for the Xorg X server | Paket i+ | xf86-input-void | Null input driver for the Xorg X server | Paket i+ | xf86-input-wacom | Wacom input driver for the Xorg X server | Paket i+ | xf86-video-amdgpu | AMDGPU video driver for the Xorg X server | Paket i+ | xf86-video-fbdev | Framebuffer video driver for the Xorg X server | Paket i+ | xf86-video-vesa | Generic VESA video driver for the Xorg X server | Paket
I think the mouse, touchpad etc. things are needed, no?
It also sounds like you have multiple cards in your laptop -- I don't know if you can select/disable one in the BIOS, but that would be something else to investigate.
There is no option in the BIOS to disable or select one of the cards. As much as I know there'sthe onboard intel graphics and an extra nvidia geforce GTX 960 M.
In Vbox, a virtual graphics adapter is used, not the Intel or NVIDIA, at least not for the guests, AFAIK
On 2018-07-14 01:33, Knurpht-openSUSE wrote:
Op vrijdag 13 juli 2018 21:09:42 CEST schreef Daniel Bauer:
In Vbox, a virtual graphics adapter is used, not the Intel or NVIDIA, at least not for the guests, AFAIK
The problem is that in Linux (as host) the graphics on his laptop behaves badly, and as a side effect, it also behaves badly in the Windows guest. His idea is to reverse the installs; to have a Windows host, which would behave perfectly, and then use Linux as a guest which then at least performs. Maybe even with virtualized 3D acceleration.
A sad situation, but better than the current one.
On 13/07/18 21:09, Daniel Bauer wrote:
I have a win XP and a Win 10 guest. I guess they run with the graphics provide by the host (my leap 42.3). So I think (maybe I am wrong?) that when my leap 42.3 runs intel graphics, the guests will run on itle graphics too, and if 42.3 runs on nvidia, the guest will use that, too.
No. This is not how VMs work.
VirtualBox provides an emulated software GPU to the guests. This has no hardware acceleration at all by default.
*If* you have the guest additions installed and working in the guest OSes:
- *If* your guest is Windows, you can install a driver, enable 2D acceleration in Vbox settings, and the guest will have 2D acceleration
- For all OSes with installed and working guest additions, and working accelerated OpenGL via working hardware drivers on the host, you can enable 3D passthrough in VBox settings, and then the guest will get an emulated OpenGL card whose operations are hardware-accelerated by the host's OpenGL card.
Note, you need 4 things for #2 to work: [1] The host must have hardware OpenGL with working drivers [2] The guest must be able to run the VBox guest additions. The FOSS ones might be enough, or you might have to install the VBox additions and update them yourself every time VBox is updated. [3] The setting must be enabled in VBox and the VM given enough VRAM [4] The stars must be right, the omens in your favour, a suitable wind blowing, the host's 3D hardware _AND_ the guest's 3D software needs to play nice with 3D passthrough, it *might* only work in fullscreen, you *might* have to tolerate display glitches such as incorrect textures, you *might* have to force screen redraws occasionally.
I blogged about how to get it working on Ubuntu some years ago: https://liam-on-linux.livejournal.com/33987.html
At that time, with Ubuntu guests, the FOSS guest additions worked better. I am not sure that this is the case any more.
I have had the setup working fine with:
- GNOME 3 - Cinnamon - Unity - XFCE with window composition enabled (if disabled, it's irrelevant) - LXDE with window composition enabled (ditto)
I have _never_ got it to work correctly with:
- KDE 4 or 5 - Deepin
Oh, and if your guest uses Wayland, all bets are off and almost certainly nothing will work.
On 2018-07-13 19:28, David C. Rankin wrote:
The only other thought I had was to make sure you do not have other xf86 drivers installed. It would be odd that there was a conflict, but if you have multiple drivers installed and nothing black-listed, I can see issues there. It also sounds like you have multiple cards in your laptop -- I don't know if you can select/disable one in the BIOS, but that would be something else to investigate.
He has Optimus, so dual video hardware. One Intel, another Nvidia. On Windows this works (they say) perfect: on battery it uses Intel, and when the wall power is connected it switches automatically to Nvidia. Or switch when you want high performance.
This combination works one year yes, another no on Linux. With different levels of "working".
On 07/13/2018 02:34 PM, Carlos E. R. wrote:
On 2018-07-13 19:28, David C. Rankin wrote:
The only other thought I had was to make sure you do not have other xf86 drivers installed. It would be odd that there was a conflict, but if you have multiple drivers installed and nothing black-listed, I can see issues there. It also sounds like you have multiple cards in your laptop -- I don't know if you can select/disable one in the BIOS, but that would be something else to investigate.
He has Optimus, so dual video hardware. One Intel, another Nvidia. On Windows this works (they say) perfect: on battery it uses Intel, and when the wall power is connected it switches automatically to Nvidia. Or switch when you want high performance.
This combination works one year yes, another no on Linux. With different levels of "working".
Ah!
So this is a case where Linux has a good Intel Driver, and a good Nvidia driver, but only windows has a good Optimus driver that makes use of both depending on laptop power.
Why couldn't he just configure systemd somewhere to only publish "plugged-in" and exclusively use Nvidia, or the other way around and only use Intel? Is there a kernel parameter or systemd or sysfs entry that can control this?
Le 14/07/2018 à 05:45, David C. Rankin a écrit :
Why couldn't he just configure systemd somewhere to only publish "plugged-in" and exclusively use Nvidia, or the other way around and only use Intel? Is there a kernel parameter or systemd or sysfs entry that can control this?
dunno for the OP, but for me nvidia is only for calculation, intel is always necessary for the display
jdd
On 14.07.2018 05:45, David C. Rankin wrote:
On 07/13/2018 02:34 PM, Carlos E. R. wrote:
On 2018-07-13 19:28, David C. Rankin wrote:
The only other thought I had was to make sure you do not have other xf86 drivers installed. It would be odd that there was a conflict, but if you have multiple drivers installed and nothing black-listed, I can see issues there. It also sounds like you have multiple cards in your laptop -- I don't know if you can select/disable one in the BIOS, but that would be something else to investigate.
He has Optimus, so dual video hardware. One Intel, another Nvidia. On Windows this works (they say) perfect: on battery it uses Intel, and when the wall power is connected it switches automatically to Nvidia. Or switch when you want high performance.
This combination works one year yes, another no on Linux. With different levels of "working".
Ah!
So this is a case where Linux has a good Intel Driver, and a good Nvidia driver, but only windows has a good Optimus driver that makes use of both depending on laptop power.
Why couldn't he just configure systemd somewhere to only publish "plugged-in" and exclusively use Nvidia, or the other way around and only use Intel? Is there a kernel parameter or systemd or sysfs entry that can control this?
This is how it works on WIndows, but not on Linux. Here the Nvidia doesn't work at all.
It /did/ work perfectly on 13.x!
I could use suse-prime and switch between intel and nvidia. So to my eyes it's not that Linux can't (because it could, I worked a lot with it on this laptop), but it doesn't want. Don't know why.
My bug report https://bugzilla.suse.com/show_bug.cgi?id=1088287 is still "new"...
14.07.2018 11:00, Daniel Bauer пишет:
On 14.07.2018 05:45, David C. Rankin wrote:
On 07/13/2018 02:34 PM, Carlos E. R. wrote:
On 2018-07-13 19:28, David C. Rankin wrote:
The only other thought I had was to make sure you do not have other xf86 drivers installed. It would be odd that there was a conflict, but if you have multiple drivers installed and nothing black-listed, I can see issues there. It also sounds like you have multiple cards in your laptop -- I don't know if you can select/disable one in the BIOS, but that would be something else to investigate.
He has Optimus, so dual video hardware. One Intel, another Nvidia. On Windows this works (they say) perfect: on battery it uses Intel, and when the wall power is connected it switches automatically to Nvidia. Or switch when you want high performance.
This combination works one year yes, another no on Linux. With different levels of "working".
Ah!
So this is a case where Linux has a good Intel Driver, and a good Nvidia driver, but only windows has a good Optimus driver that makes use of both depending on laptop power.
Why couldn't he just configure systemd somewhere to only publish "plugged-in" and exclusively use Nvidia, or the other way around and only use Intel? Is there a kernel parameter or systemd or sysfs entry that can control this?
This is how it works on WIndows, but not on Linux. Here the Nvidia doesn't work at all.
All your logs attached to mentioned bug report show that nVidia *does* work (i.e. Xserver is started and is using nVidia driver) but SDDM crashes.
It /did/ work perfectly on 13.x!
13.x did not even have SDDM, did it?
I could use suse-prime and switch between intel and nvidia. So to my eyes it's not that Linux can't (because it could, I worked a lot with it on this laptop), but it doesn't want. Don't know why.
My bug report https://bugzilla.suse.com/show_bug.cgi?id=1088287 is still "new"...
Quoting comment on this bug:
Both the Xorg.0.log and Xorg.0.log.old show situation when nvidia is the primary GPU and intel is secondary. It seems that intel gets correctly configured as output source because it sets up the eDP1 output. But shortly after the X server is cleanly terminated. My guess is that the display manager fails. You could try if switching to some other display manager helps (KDM, GDM, SDDM, ...).
This reply was added on the same day you submitted bug report. Did you try different DM in three months that passed since then?
On 14.07.2018 11:47, Andrei Borzenkov wrote:
Quoting comment on this bug:
Both the Xorg.0.log and Xorg.0.log.old show situation when nvidia is the primary GPU and intel is secondary. It seems that intel gets correctly configured as output source because it sets up the eDP1 output. But shortly after the X server is cleanly terminated. My guess is that the display manager fails. You could try if switching to some other display manager helps (KDM, GDM, SDDM, ...).
This reply was added on the same day you submitted bug report. Did you try different DM in three months that passed since then?
I once gave it a try using KDM. As id didn't change anything went back to original.
Today again I changed to KDM.
But somehow again I am in the situation that the nvidia kernel modules are not loaded (nothing about nvidia in xorg logs).
modprobe nvidia_drm modprobe: ERROR: could not insert 'nvidia_drm': Unknown symbol in module, or unknown parameter (see dmesg)
I guess that's what I should see in dmesg: [ 2373.615609] nvidia_modeset: Unknown symbol nv_kthread_q_flush (err 0) [ 2373.615728] nvidia_modeset: Unknown symbol nvidia_register_module (err 0) [ 2373.615850] nvidia_modeset: Unknown symbol nv_kthread_q_schedule_q_item (err 0) [ 2373.615969] nvidia_modeset: Unknown symbol nvidia_get_rm_ops (err 0) [ 2373.616018] nvidia_modeset: Unknown symbol nv_kthread_q_item_init (err 0) [ 2373.616056] nvidia_modeset: Unknown symbol nv_kthread_q_stop (err 0) [ 2373.616093] nvidia_modeset: Unknown symbol nvidia_unregister_module (err 0) [ 2373.616139] nvidia_modeset: Unknown symbol nv_kthread_q_init (err 0)
How do I make those nvidia modules load at boot?
On 2018-07-14 14:36, Daniel Bauer wrote:
But somehow again I am in the situation that the nvidia kernel modules are not loaded (nothing about nvidia in xorg logs).
On a desktop machine with Nvidia proprietary drivers loaded, I see (lsmod):
nvidia_uvm 40960 0 nvidia 10575872 130 nvidia_uvm drm 397312 3 nvidia
I don't have a module named nvidia-drm, must be new.
Telcontar:~ # locate nvidia?drm.ko Telcontar:~ #
In any case, the main module is "nvidia".
On 14.07.2018 15:08, Carlos E. R. wrote:
On 2018-07-14 14:36, Daniel Bauer wrote:
But somehow again I am in the situation that the nvidia kernel modules are not loaded (nothing about nvidia in xorg logs).
On a desktop machine with Nvidia proprietary drivers loaded, I see (lsmod):
nvidia_uvm 40960 0 nvidia 10575872 130 nvidia_uvm drm 397312 3 nvidia
I don't have a module named nvidia-drm, must be new.
Telcontar:~ # locate nvidia?drm.ko Telcontar:~ #
In any case, the main module is "nvidia".
I used this because of this outout of hwinfo --gfxcard:
23: PCI 100.0: 0302 3D controller [Created at pci.378] Unique ID: VCu0.hDjcjYACgT6 Parent ID: vSkL.fWlq6741dtC SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0 SysFS BusID: 0000:01:00.0 Hardware Class: graphics card Model: "nVidia GM107M [GeForce GTX 960M]" Vendor: pci 0x10de "nVidia Corporation"
Device: pci 0x139b "GM107M [GeForce GTX 960M]"
SubVendor: pci 0x1043 "ASUSTeK Computer Inc."
SubDevice: pci 0x1c5d
Revision: 0xa2
Memory Range: 0xde000000-0xdeffffff (rw,non-prefetchable)
Memory Range: 0xc0000000-0xcfffffff (ro,non-prefetchable)
Memory Range: 0xd0000000-0xd1ffffff (ro,non-prefetchable)
I/O Ports: 0xe000-0xefff (rw)
Memory Range: 0xdf000000-0xdf07ffff (ro,non-prefetchable,disabled)
IRQ: 255 (no events)
Module Alias: "pci:v000010DEd0000139Bsv00001043sd00001C5Dbc03sc02i00" Driver Info #0: Driver Status: nouveau is not active Driver Activation Cmd: "modprobe nouveau" Driver Info #1: Driver Status: nvidia_drm is not active Driver Activation Cmd: "modprobe nvidia_drm" Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #8 (PCI bridge)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2018-07-14 a las 15:35 +0200, Daniel Bauer escribió:
On 14.07.2018 15:08, Carlos E. R. wrote:
On 2018-07-14 14:36, Daniel Bauer wrote:
But somehow again I am in the situation that the nvidia kernel modules are not loaded (nothing about nvidia in xorg logs).
On a desktop machine with Nvidia proprietary drivers loaded, I see (lsmod):
nvidia_uvm 40960 0 nvidia 10575872 130 nvidia_uvm drm 397312 3 nvidia
I don't have a module named nvidia-drm, must be new.
Telcontar:~ # locate nvidia?drm.ko Telcontar:~ #
In any case, the main module is "nvidia".
I used this because of this outout of hwinfo --gfxcard:
23: PCI 100.0: 0302 3D controller
...
Hardware Class: graphics card Model: "nVidia GM107M [GeForce GTX 960M]" Vendor: pci 0x10de "nVidia Corporation"
...
Module Alias: "pci:v000010DEd0000139Bsv00001043sd00001C5Dbc03sc02i00" Driver Info #0: Driver Status: nouveau is not active Driver Activation Cmd: "modprobe nouveau"
. . . . . . . . . . . . . . . . . . . .^^^^^^^
This is the important item of information. You are using nouveau, the free driver, not the proprietary one. In this context drm is the lesser of your problems.
You need to activate the proprietary driver first, which is probably incorrectly installed.
- -- Cheers Carlos E. R.
(from openSUSE 42.3 x86_64 "Malachite" (Minas Tirith))
14.07.2018 15:36, Daniel Bauer пишет:
On 14.07.2018 11:47, Andrei Borzenkov wrote:
Quoting comment on this bug:
Both the Xorg.0.log and Xorg.0.log.old show situation when nvidia is the primary GPU and intel is secondary. It seems that intel gets correctly configured as output source because it sets up the eDP1 output. But shortly after the X server is cleanly terminated. My guess is that the display manager fails. You could try if switching to some other display manager helps (KDM, GDM, SDDM, ...).
This reply was added on the same day you submitted bug report. Did you try different DM in three months that passed since then?
I once gave it a try using KDM. As id didn't change anything went back to original.
Today again I changed to KDM.
But somehow again I am in the situation that the nvidia kernel modules are not loaded (nothing about nvidia in xorg logs).
modprobe nvidia_drm modprobe: ERROR: could not insert 'nvidia_drm': Unknown symbol in module, or unknown parameter (see dmesg)
I guess that's what I should see in dmesg: [ 2373.615609] nvidia_modeset: Unknown symbol nv_kthread_q_flush (err 0) [ 2373.615728] nvidia_modeset: Unknown symbol nvidia_register_module (err 0) [ 2373.615850] nvidia_modeset: Unknown symbol nv_kthread_q_schedule_q_item (err 0) [ 2373.615969] nvidia_modeset: Unknown symbol nvidia_get_rm_ops (err 0) [ 2373.616018] nvidia_modeset: Unknown symbol nv_kthread_q_item_init (err 0) [ 2373.616056] nvidia_modeset: Unknown symbol nv_kthread_q_stop (err 0) [ 2373.616093] nvidia_modeset: Unknown symbol nvidia_unregister_module (err 0) [ 2373.616139] nvidia_modeset: Unknown symbol nv_kthread_q_init (err 0)
How do I make those nvidia modules load at boot?
This should happen automatically, at least after installation of openSUSE RPMs. And it did work for you in the past as your logs confirm. So the obvious question - what did you change since then.
On 14.07.2018 16:59, Andrei Borzenkov wrote:
14.07.2018 15:36, Daniel Bauer пишет:
On 14.07.2018 11:47, Andrei Borzenkov wrote:
Quoting comment on this bug:
Both the Xorg.0.log and Xorg.0.log.old show situation when nvidia is the primary GPU and intel is secondary. It seems that intel gets correctly configured as output source because it sets up the eDP1 output. But shortly after the X server is cleanly terminated. My guess is that the display manager fails. You could try if switching to some other display manager helps (KDM, GDM, SDDM, ...).
This reply was added on the same day you submitted bug report. Did you try different DM in three months that passed since then?
I once gave it a try using KDM. As id didn't change anything went back to original.
Today again I changed to KDM.
But somehow again I am in the situation that the nvidia kernel modules are not loaded (nothing about nvidia in xorg logs).
modprobe nvidia_drm modprobe: ERROR: could not insert 'nvidia_drm': Unknown symbol in module, or unknown parameter (see dmesg)
I guess that's what I should see in dmesg: [ 2373.615609] nvidia_modeset: Unknown symbol nv_kthread_q_flush (err 0) [ 2373.615728] nvidia_modeset: Unknown symbol nvidia_register_module (err 0) [ 2373.615850] nvidia_modeset: Unknown symbol nv_kthread_q_schedule_q_item (err 0) [ 2373.615969] nvidia_modeset: Unknown symbol nvidia_get_rm_ops (err 0) [ 2373.616018] nvidia_modeset: Unknown symbol nv_kthread_q_item_init (err 0) [ 2373.616056] nvidia_modeset: Unknown symbol nv_kthread_q_stop (err 0) [ 2373.616093] nvidia_modeset: Unknown symbol nvidia_unregister_module (err 0) [ 2373.616139] nvidia_modeset: Unknown symbol nv_kthread_q_init (err 0)
How do I make those nvidia modules load at boot?
This should happen automatically, at least after installation of openSUSE RPMs. And it did work for you in the past as your logs confirm. So the obvious question - what did you change since then.
Well, there were many updates with zypper up during this time, several new kernels...
Manually I have changed today /etc/sysconfig/displaymanager from sddm to kdm
and, since the modules were not loaded, I reinstalled the nvidia drivers with yast (this helped last time...). I was wondering that mkinitrd was not running after that install, at least I haven't seen it.
On 14.07.2018 18:46, Daniel Bauer wrote:
On 14.07.2018 16:59, Andrei Borzenkov wrote:
14.07.2018 15:36, Daniel Bauer пишет:
This should happen automatically, at least after installation of openSUSE RPMs. And it did work for you in the past as your logs confirm. So the obvious question - what did you change since then.
Well, there were many updates with zypper up during this time, several new kernels...
Manually I have changed today /etc/sysconfig/displaymanager from sddm to kdm
and, since the modules were not loaded, I reinstalled the nvidia drivers with yast (this helped last time...). I was wondering that mkinitrd was not running after that install, at least I haven't seen it.
There are errors in /var/log/messages:
Jul 14 19:04:11 meitli kernel: nvidia_modeset: loading out-of-tree module taints kernel. Jul 14 19:04:11 meitli kernel: nvidia_modeset: module license 'NVIDIA' taints kernel. Jul 14 19:04:11 meitli kernel: Disabling lock debugging due to kernel taint Jul 14 19:04:11 meitli kernel: nvidia_modeset: Unknown symbol nv_kthread_q_flush (err 0) Jul 14 19:04:11 meitli kernel: nvidia_modeset: Unknown symbol nvidia_register_module (err 0) Jul 14 19:04:11 meitli kernel: nvidia_modeset: Unknown symbol nv_kthread_q_schedule_q_item (err 0) Jul 14 19:04:11 meitli kernel: nvidia_modeset: Unknown symbol nvidia_get_rm_ops (err 0) Jul 14 19:04:11 meitli kernel: nvidia_modeset: Unknown symbol nv_kthread_q_item_init (err 0) Jul 14 19:04:11 meitli kernel: nvidia_modeset: Unknown symbol nv_kthread_q_stop (err 0) Jul 14 19:04:11 meitli kernel: nvidia_modeset: Unknown symbol nvidia_unregister_module (err 0) Jul 14 19:04:11 meitli kernel: nvidia_modeset: Unknown symbol nv_kthread_q_init (err 0)
while, if I read it correctly, on July 12 the modules still loaded:
Jul 12 15:58:41 meitli kernel: nvidia: loading out-of-tree module taints kernel. Jul 12 15:58:41 meitli kernel: nvidia: module license 'NVIDIA' taints kernel. Jul 12 15:58:41 meitli kernel: Disabling lock debugging due to kernel taint Jul 12 15:58:41 meitli kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 248 Jul 12 15:58:41 meitli kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 390.67 Fri Jun 1 04:04:27 PDT 2018 (using threaded interrupts) Jul 12 15:58:41 meitli kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Jul 12 15:58:41 meitli kernel: [drm] Driver supports precise vblank timestamp query. Jul 12 15:58:41 meitli kernel: nvidia-uvm: Loaded the UVM driver in 8 mode, major device number 247 Jul 12 15:58:41 meitli kernel: ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) Jul 12 15:58:41 meitli kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4 Jul 12 15:58:41 meitli kernel: ACPI: Video Device [PEGP] (multi-head: no rom: yes post: no) Jul 12 15:58:41 meitli kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:12/LNXVIDEO:01/input/input5 Jul 12 15:58:41 meitli kernel: [drm] Initialized i915 1.6.0 20151010 for 0000:00:02.0 on minor 0 Jul 12 15:58:41 meitli systemd[1]: Reloading. Jul 12 15:58:41 meitli kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 390.67 Fri Jun 1 03:15:43 PDT 2018 Jul 12 15:58:41 meitli kernel: [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
I have not the slightest idea why they don't load anymore now...
On 07/14/2018 09:46 AM, Daniel Bauer wrote:
Manually I have changed today /etc/sysconfig/displaymanager from sddm to kdm
As Carlos taught me a month or so ago, changing displaymanager doesn't work anymore. Try using update-alternatives, as referenced in the release notes:
(I hope this pastes okay)
5.2Use|update-alternatives|to Set Login Manager and Desktop SessionREPORT BUG https://bugzilla.opensuse.org/enter_bug.cgi?&product=openSUSE%20Distribution&component=Release%20Notes&short_desc=[doc]+&comment=5.2%20%20Use%20%3Ccode%20class%3D%22command%22%3Eupdate-alternatives%3C%2Fcode%3E%20to%20Set%20Login%20Manager%20and%20Desktop%20Session%0A%0Ahttps%3A%2F%2Fdoc.opensuse.org%2Frelease-notes%2Fx86_64%2FopenSUSE%2FLeap%2F15.0%2F%23sec.desktop.set-login-manager-session&assigned_to=sknorr%40suse.com# https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.0/#sec.desktop.set-login-manager-session
In the past, you could use|/etc/sysconfig|or the YaST module/etc/sysconfig Editorto define the login manager and desktop session. Starting with openSUSE Leap 15.0, the values are not defined using|/etc/sysconfig|anymore but with the alternatives system.
To change the defaults, use the following alternatives:
*
Login manager:|default-displaymanager|
*
Wayland session:|default-waylandsession.desktop|
*
X desktop session:|default-xsession.desktop|
For example, to check the value of|default-displaymanager|, use:
sudo update-alternatives --display default-displaymanager
To switch the|default-displaymanager|to|xdm|, use:
sudo update-alternatives --set default-displaymanager \ /usr/lib/X11/displaymanagers/xdm
To enable graphical management of alternatives, use the YaST moduleAlternativesthat can be installed from the packageyast2-alternatives.
and, since the modules were not loaded, I reinstalled the nvidia drivers with yast (this helped last time...). I was wondering that mkinitrd was not running after that install, at least I haven't seen it.
I haven't been following this thread too closely, but have you tried installing the Nvidia binary blob from the Nvidia support site?
Regards, Lew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Content-ID: alpine.LSU.2.21.1807150022131.15806@minas-tirith.valinor
El 2018-07-14 a las 11:47 -0700, Lew Wolfgang escribió:
On 07/14/2018 09:46 AM, Daniel Bauer wrote:
Manually I have changed today /etc/sysconfig/displaymanager from sddm to kdm
As Carlos taught me a month or so ago, changing displaymanager doesn't work anymore. Try using update-alternatives, as referenced in the release notes:
Wait. openSUSE Leap 42.X use the old method of changing displaymanager, while Leap 15.0 uses the new one, via update-alternatives.
To complicate things further, there are some "minor" display manager that still don't support the new method, so go figure how to use them now...
At this point, I don't remember what Leap version is Daniel using.
I haven't been following this thread too closely, but have you tried installing the Nvidia binary blob from the Nvidia support site?
I would try that. But I don't have Optimus, so I do not know...
- -- Cheers Carlos E. R.
(from openSUSE 42.3 x86_64 "Malachite" (Minas Tirith))
-
Andrei Borzenkov -
Carlos E. R. -
Daniel Bauer -
David C. Rankin -
jdd＠dodin.org -
Knurpht-openSUSE -
Lew Wolfgang -
Liam Proven -
Peter Suetterlin