Upgrade Laptop to Opensuse 42.3, Probleme mit Bumblebee und VMware WS 12.5, Workarounds

Gestern war ein Upgrade meines nun schon in die Jahre gekommenen Laptops von Opensuse Leap 42.2 auf Leap 42.3 fälllig.
Ich bin dabei gem. der schönen Anleitung in
https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/
vorgegangen. Zu der Anleitung gibt es nichts weiter zu sagen; die ist perfekt. Im Upgrade hatte ich nur die Standardrepositories (inkl. Update-Repository) für Leap 42.3 benutzt.

Mein Laptop hat eine Nvidia-Karte (Optimus-System). Das ursprüngliche Leap 42.2 lief auf dem Laptop deshalb mit einer Bumblebee-Installation; das funktionierte einwandfrei. Zudem nutzte ich auf dem Laptop VMware WS 12.5. Nach dem Leap-Upgrade hatte ich jedoch sowohl mit Bumblebee als auch VMware-Workstation Probleme - obwohl auch Leap 42.3 nur einen Kernel der nun doch schon recht alten Version 4.4 aufweist! nach dem Ugrade war bei mir 4.4.92-31 aktiv; bei der Leap_42.3 war dagegen der Kernel 4.4.76 der Default-Kernel.

Nebenbei: Bzgl. der Kernelversionen hat der SLES-Unterbau von Opensuse Leap plötzlich den unangenehmen Nebeneffekt, dass man an älteren Kernelversionen kleben bleibt ... Von SUSEs Seite müssen ggf. Back-Portierungen aus neuen Kernelversionen zu älteren Versionen vorgenommen werden. Das kann Nebeneffekte zeitigen (s.u.). Bin mal gespannt wie Opensuse mit diesem Thema in Zukunft umgehen will ...

Wiederholte Modul-Einträge in der Datei "/etc/sysconfig/kernel"

Das erste Problem war, dass die Datei "/etc/sysconfig/kernel" nach dem Neustart mehrfache Einträge zum Laden von nvidia-Modulen enthielt. Woher immer das stammte; vielleicht hatte ich das ja schon früher von Experimenten mit Bumblebee drin. Vielleicht wurden die Einträge aber auch im Upgrade hinzugefügt. Jedenfalls mal checken, dass in dieser Datei nach dem Upgrade kein überflüssiger Unsinn drinsteht.

Bumblebee-Installation wieder zum Laufen bringen

Bumblebee lief nach dem Upgrade nicht mehr. Ok, dachte ich, also die für Leap 42.3 passenden Repositories aktivieren und diverse Bumblebee-Pakete aktualisieren. Es gibt jedoch mehrere Repositories mit Bumblebee-Paketen für Opensuse Leap, u.a.
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/nvidia:/3xx.xx/OpenSUSE_Leap_42.3.
Unter Leap 42.1/42.2 hatte ich etliche Pakete aus diesen Repositories benutzt.

Für Leap 42.3 gilt (nach meiner Erfahrung): Zu nutzen ist
http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_Leap_42.3
und sonst gar nichts! Auch nicht das Nvidia-Community-Repository!

Die im "X11:Bumblebee"-Repository vorhandenen Pakete - inklusive der Pakete mit dem proprietären Nvidia-Treiber - kann und sollte man dagegen (bis auf eines) installieren; das Paket "primus" habe ich mir allerdings aus dem 42.3-Update-Repository geholt.

Ergänzung 02.12.2017: Wichtige Ausnahme:
bbswitch sollte man nicht installieren. Es reicht bbswitch-kmp-default! Und nur letzteres hat bei mir funktioniert - und zwar ohne dkms-Service.

Die Installation von bbswitch aktiviert den "dkms"-Service; waren sowohl "bbswitch-kmp-default" und "bbswitch" installiert, so führte dies bei mir anhand von Statusanzeigen erkennbar zu einem wechselseitigen An- und Abschalten der Graka im Bootprozess; sie wird danach von den Treibern nicht mehr erkannt.

(Auf die anderen Repositories zu unterschiedlichen Nvidia-Treibern sollte man wirklich nur im Notfall zurückgreifen, und zwar dann, wenn ihr für eure Graka zwingend einen älteren Nvidia-Treiber benötigt; aber auch dann nur x11-video-nvidia installieren. Nicht dagegen das Paket "dkms-nvidia"!)

Zu beachten ist also auch folgender Hinweis: Falls ihr früher einen laufenden dkms-Service hattet: Unbedingt deaktivieren! Und zwar nach der Installation der Pakete, aber schon vor einem anschließenden Neustart des Systems.

systemctl disable dkms

Das steht im Gegensatz zu den Anweisungen in der Anleitung
https://de.opensuse.org/SDB:NVIDIA_Bumblebee
absolut notwendig! Zumindest auf meinem Laptop ... Fragt mich bitte nicht, warum der dkms-Service zu Problemen führt.

Der Bumblebee-Dämon "bumblebeed" dagegen muss über den zuständigen Service aktiviert werden

systemctl enable bumblebeed

Zudem checken, dass der User, unter dem ihr mit einer grafischen Oberfläche arbeitet, Mitglied der Gruppen "video" und "bumblebee" ist. Ggf. mittels "usermod -G video,bumblebee USERNAME" korrigieren.

Dann Neustart des Systems. Die Kommandos

optirun glxspheres
vblank_mode=0 primusrun glxspheres
optirun -b none nvidia-settings -c :8

sollten danach alle einwandfrei funktionieren.

Sollte das nicht der Fall sein und immer noch eine Meldung kommen, dass die Graka nicht vorhanden sei und der "nvidia"-Treiber nicht geladen werden könne:

Alle Pakete aus dem Nvidia-(Community)-Repository (Treiber nvidia-gfx-GL04 und ähnliche), aus dem Nvidia-Bumblebee-Repository und dem oben angegebenen Standard-Bumblebee-Repository löschen. Danach nur die Pakete aus dem oben angegebenen Standard-Repository http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_Leap_42.3
mit Ausnahme von bbswitch (!) installieren. Den dkms-Service dann prophylaktisch deaktivieren! Neustart.

Ein probeweiser Start des dkms-Service führt nach einem vorhergehenden Erfolg mit "primusrun" in jedem Fall wieder in die Katastrophe:

Danach kommen in Logfiles Fehlermeldungen, dass es kein passendes Grafik Device gäbe. Am Terminal erscheint: "Cannot access secondary GPU ...". Das ließ sich durch ein anschließendes normales Stoppen des dkms-Service nicht mehr beheben. Bumblebee funktionierte auch nach dem Stoppen des dkms-Service nicht mehr ordnungsgemäß; nvidia Module ließen sich selbst manuell nicht mehr laden. Da half nur ein Reboot - natürlich bei deaktiviertem dkms-Service.

Ich habe leider keine Zeit, der genauen Ursache auf den Grund zu gehen. Bei künftigen Änderungen des Kernels muss man ohne korrekt funktionierendes dkms ggf. halt ein Update für die nvidia- und bbswitch-Module aus dem Bumblebee-Repository erzwingen und damit (zumindest bzgl. nvidia) eine Neukompilation durchführen lassen. Interessant ist, dass für den bei mir nach dem Leap-Upgrade aktiven Kernel 4.4.92-31 ein Link von
/lib/modules/4.4.92-31-default/weak-updates/updatesbbswitch.ko -> /lib/modules/4.4.676-1-default/updates/bbswitch.ko
angelegt wurde. Der funktioniert offenbar. Irgendwas am Kernel 4.4.92 missfällt womöglich dkms beim Versuch, für den neueren Kernel das passende Modul zu definieren. Der 4.4.92-Kernel führt aufgrund von Rückportierungen, die die SuSE-Leute wohl vorgenommen haben, auch noch in anderem Kontext - nämlich bzgl. der VMware WS - zu Schwierigkeiten.

Probleme mit der VMware Workstation 12.5. unter Leap 42.3 beheben

Meine unter Leap 42.2 installierte VM WS 12.5.1 lief nach dem Leap-Upgrade nicht mehr. Auch ein Upgrade der Workstation-SW auf die aktuelle Version 12.5.8 endete beim ersten Startversuch mit Kompilierungsfehlern. Die konnte ich mir im Detail zwar ansehen; wie man aber die problematischen Stellen im Quellcode der VMware-Module beheben hätte müssen, lag jenseits meiner Kenntnisse und Fähigkeiten.

Hier half aber der Beitrag eines offenbar Kernel-Kundigen im VMware Community Forum:
https://communities.vmware.com/message/2693257#2693257
Dort suche man nach dem Beitrag von "hendrikw84"! Herzlichen Dank an diesen Herrn! Seine Vorgaben zur Korrektur diverser Codezeilen funktionieren nämlich einwandfrei. (Ursache der Probleme sind offenbar Rückwärtsportierungen von Features des Kernels 4.10 in den Code des Kernels 4.4. Was immer die SuSE-Leute dabei gedacht haben ...)

[ Warum allerdings die eine vorgeschlagene Korrektur-Zeile

retval = retval = get_user_pages((unsigned long)uvAddr, numPages, 0, ppages, NULL);

nicht gleich zu

retval = get_user_pages((unsigned long)uvAddr, numPages, 0, ppages, NULL);

verkürzt werden kann, ist mir etwas schleierhaft. Typo? Die letzte Zeile für retval klappt für den Code von hostif.c unter vmmon-only/linux nämlich auch.]

Nach Durchführung der Korrekturen ließen sich die VMware-Codes jedenfalls anstandslos für Kernel "4.4.9-31-default" kompilieren - und die nötigen Kernelmodule wurden fehlerfrei erzeugt. Meine zwei lokalen (non shared) virtuellen Maschinen für Windows-Installationen liefen damit bislang einwandfrei.

Ob es - wie in der Diskussion im VMware Community Forum angedeutet, Probleme mit "shared VMs" auf Servern gibt, habe ich nicht getestet. Auf Servern verwende ich KVM-Installaionen mit spice oder X2GO.

Viel Spaß denn mit Opensuse 42.3 auf dem Laptop!

Bumblebee auf Optimus-Notebooks und Laptops mit Opensuse 13.1 / 13.2 / Leap 42.1

Da mein früherer Artikel zu diesem Thema
http://linux-blog.anracom.com/2015/06/11/bumblebee-auf-laptops-mit-opensuse-13-1-13-2/
etwas veraltet ist und zu einer nicht mehr funktionierenden Schalterfunktion für die Nvidia-Karte führt, hier eine neue Zusammenstellung der Schritte, mit denen ich Bumblebee auf Optimus-Systemen zum Laufen gebracht habe. Getestet habe ich das auf einem Laptop mit "i7-3632QM" Prozessor mit integrierter Intel HD 4000 Grafikkarte; ferner existiert eine zusätzliche Nvidia GT 645M. Ich erläutere die Installation für Opensuse 13.1; für 13.2 und Leap 42.1 geht alles ganz analog (und funktioniert auch) - nur sind andere Repositories zu wählen.

Installation und Einrichtung von Bumblebee

Folgende RPM-Repositories sollte man der SW-Verwaltung unter YaST für Opensuse 13.1 Installationen verfügbar machen:
http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_13.1/
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/Bumblebee/openSUSE_13.1/
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/Bumblebee3/openSUSE_13.1/
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/nVidia:/364.19/openSUSE_13.1/

Unter Opensuse 13.2 bzw. Leap 42.1 ist "13.1" in den Adressen natürlich jeweils durch "13.2" bzw. "LEAP_42.1" zu ersetzen.

Will man eine neueren Nvidia-Treiber nutzen, findet man eine Auswahl an entsprechenden Repositories unter
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/nVidia:/

In meinem Fall habe ich einen Mix aus verschiedenen Versionen der notwendigen Pakete aus den oben genannten Repositories verwendet. Vorsichtigere Menschen sollten sich aber konsequent für konsistente Pakete aus dem Bumblebee3 Repository entscheiden. Das dkms-Paket nehme ich allerdings immer aus dem Repository für den Nvidia-Treiber.

Man muss halt schauen, ob es Probleme gibt. U.U. funktioniert z.B. das Schließen von Anwendungen nicht ganz richtig, etc..
Interessant ist es nach einer Installation auch immer, komplexere 3D- Anwendungen wie z.B. Alienarena mal mit

primusrun alienarena

und danach mit dem Aufruf

optirun alienarena

zu starten. Beides sollte funktionieren; tut es aber bei manchen Kombinationen der Paketversionen nicht. (Off Topic: Alienarena nimmt ungefragt Verbindungen zu einem Server im Internet auf, auch beim Single Player Modus; wer das nicht mag, kann es über Nutzen von "Host Server" im Menü unterbinden, eine Firewall nutzen oder schlicht das Netzwerk deaktivieren.)
Es bleibt einem halt leider nur auszuprobieren, welche Zusammenstellung von Paketversionen auf seinem eigenen System korrekt läuft.

Bei mir ist mit den Paketen aus dem Bumblebee3-Repo alles in Ordnung; folgende Versionen habe ich konkret installiert:
bumblebee1
bumblebee2

Entscheidend ist die Installation des Nvidia-Kernel-Modules "nvidia" über das Paket "X11-video-nvidia" aus dem 4-ten Repository. Während der Installation wird die erforderliche Kompilation für den aktuellen Kernel vorgenommen.

Blacklisten des nouveau-Treibers

Nach einer Neuinstallation von Opensuse auf einem Laptop mag es sein, dass der Nouveau-Treiber installiert ist. Ich habe Bumblebee bislang nicht mit dem Nouveau-Treiber ausprobiert, sondern aus verschiedenen Gründen immer den proprietären Nvidia-Treiber (erfolgreich) genutzt. Damit dies möglich wird, muss der Nouveau-Treiber, soweit auf dem Laptop-System vorhanden, deaktiviert werden. Ich habe ihn deshalb zur Sicherheit in eine Blacklist für Kernelmodule aufgenommen. Die Dateien "/etc/modprobe.d/50-blacklist-nouveau.conf" und auch "/etc/modprobe.d/50-blacklist.conf" enthalten somit folgende Statements:

blacklist nouveau
options nouveau modeset=0

Keine Installation des proprietären Nvidia-Treibers über das Linux-Installationsprogramm von der Nvidia-Web-Seite!

Versucht weder während der Opensuse-Erstinstallation noch später den proprietären Treiber von Nvidia mit den Installationsroutinen von der Nvidia Webseite zu installieren! Das wird in einer Optimus-Konfiguration zu keinem Erfolg führen! Der proprietäre Nvidia-Treiber sollte auf Optimus Laptops statt dessen immer aus dem oben genannten "Bumblebee-Project:/nVidia"-Repository geladen werden.

KMS nicht abschalten!

KMS (Kernel mode setting; s. http://de.wikipedia.org/wiki/Mode-Setting) wird für das "i915"-Modul (also den Treiber für die Intel Graka) zwingend benötigt - DKMS sollte man also (im Gegensatz zu früheren Desktop-Installationen mit Nvidia-Karten) nicht über Kernelparameter wie "nomodeset" beim Starten des Systems deaktivieren.

Ferner gilt: Das Opensuse Community Repository für Nvidia Treiber sollte deaktiviert sein; keines der Nvidia RPMs - sprich kein Nvidia-Treiber-Paket - aus diesem Community Repository sollte installiert sein oder werden.

Welche Services sind zu aktivieren?

Folgende Services müssen für den Systemstart unter systemd ggf. noch explizit aktiviert werden:

systemctl enable bumblebeed.service
systemctl enable dkms.service

Desktop-User als Mitglied der Gruppe "bumblebee" einrichten

Zudem muss der User, unter dem man den Desktop nutzt, Mitglied der ggf. neu anzulegenden Gruppe "bumblebee" werden.

xorg.conf-Datei

Es lohnt sich ein Blick in das Verzeichnis /etc/bumblebee": Dort befindet sich eine spezielle Datei "xorg.conf.nvidia", die von Bumblebee genutzt wird. Eine evtl. vorhandene "/etc/X11/xorg.conf" im Verzeichnis "/etc/X11" sollte man entfernen !

Neustart des Systems - KDE Desktop mit 3D Effekten über den Intel Grafikkartentreiber

Sind alle Voraussetzungen geschaffen, startet man das System am besten neu. Man sollte dann auf der gewohnten Desktop-Oberfläche landen. Diese wird vom Intel Treiber - in meinem Fall vom kernel-Modul "i915" - gesteuert. KDE-3D-Effekte lassen sich auch über die Intel-Grafikkarte nutzen; dafür reicht deren Performance allemal.

"lsmod" sollte folgende Module anzeigen, die im Zusammenhang mit Grafik von Bedeutung sind:

i915 710403 8
bbswitch 13943 0
drm 313440 11 i915,drm_kms_helper
drm_kms_helper 56806 1 i915
video 19507 1 i915
button 13952 1 i915
thermal_sys 36646 5 x86_pkg_temp_thermal,intel_powerclamp,thermal,video,processor
 
videobuf2_core 44595 1 uvcvideo
videodev 141701 2 uvcvideo,videobuf2_core
videobuf2_vmalloc 13216 1 uvcvideo
videobuf2_memops 13362 1 videobuf2_vmalloc

Start von 3D-Anwendungen

Spezielle 3d-Applikationen, wie etwa Spiele (z.B. "alienarena")oder OpenGL-Anwendungsprogramme, die mehr Rechenpower erfordern, kann man dann als Desktop-User über

optirun alienarena

oder

primusrun alienarena

starten.

bumblebee4

"primusrun" reduziert die Framerate der Graka auf die Schirmrate, wenn keine weiteren Parameter angegeben werden. Frame- und vertikale Bildschirmfrequenz werden also synchronisiert. Für volle Performance muss man

vblank_mode=0 primusrun alienarena

benutzen.

Folgender Artikel liefert ein paar Hinweise zum ursprünglichen Unterschied zwischen "primusrun" und "optirun": http://www.webupd8.org/2012/11/primus-better-performance-and-less.html
Faktisch sind die aktuellen Performance-Unterschiede zwischen "primusrun" und "optirun" auf meinem System jedoch minimal.

"lsmod" zeigt nach dem Starten einer 3d-Applikation dann folgende zusätzlichen Module an:

nvidia 8370147 37
drm 313440 11 nvidia,i915,drm_kms_helper

Aufruf des Tools nvidia-settings

Übrigens: Das Tool "nvidia-settings" ruft man wie folgt auf:

optirun -b none nvidia-settings -c :8

Ab- und An-Schalten der Nvidia-Karte im normalen Desktop-Betrieb

"optirun" und "primusrun" aktivieren die Nividia-Karte bei Bedarf selbständig und deaktivieren sie auch wieder - wenn die geladenen Pakete richtig zusammenarbeiten. Zum gezielten Abschalten der Nvidia-Karte im normalen Desktop-Betrieb benutzt man als root-User dagegen folgendes Kommando:

tee /proc/acpi/bbswitch <<< OFF

Anschalten geht über

tee /proc/acpi/bbswitch <<< ON

Der Laptop zeigt die Aktivität der Nvidia-Graka i.d.R. über eine LED an. Ein gezieltes Anschalten im normalen Desktop-Betrieb kann dann nützlich sein, wenn man - wie in meinem Fall - durch ein erratisches Anspringen des Laptop-Lüfters gerade bei zu kühlem Zustand des Laptops genervt wird. Manchmal hilft die zusätzliche Abwärme der Nvidia-Graka im Leerlauf, einen kontinuierlichen Lüfterbetrieb zu erzwingen.

Startbedingungen zum An- und Abschalten der Nvidia Graka legt man über entsprechende Parameter in der Datei "/etc/modprobe.de/50-bbswitch.conf" fest:

options bbswitch load_state=0 unload_state=1

Was ist nach einem Kernelupdate und Neustart des Systems zu tun ?

Nach einem Kernelupdate läuft der "intel915" Treiber ja typischerweise noch. Man gelangt dadurch auf die grafische Oberfläche. Am einfachsten ist dann eine Deinstallation und anschließende Neuinstallation der oben dargestellten Pakete aus den Bumblebee Repositories - u.a. dkms, dkms-nvidia, bbswitch, vor allem aber "X11-video-nvidia". Der Nvidia-Treiber wird dabei neu kompliert.

Opensuse Leap 42.1 – Nvidia – KDE 5 – unregelmäßiger Crash des Windowmanagers

Der KDE Plasma-Desktop von Opensuse Leap 42.1 macht mir immer wieder erhebliche Schwierigkeiten. Leider auch bzgl. elementarer Dinge wie etwa der Bedienbarkeit der Fenster. Ich habe zwar den neuesten proprietären Treiber von Nvidia installiert; der hilft aber ebensowenig wie ältere Treiber oder ein Wechsel von OpenGL 2.0 zu OpenGL 3.1:

Bei Drag- und Drop-Aktionen mit komplexeren Applikationen wie etwa "kontact" oder Eclipse auf dem Desktop zerreißt es manchmal den Windowmanager. Danach haben sämtliche Fenster keine Bedienleiste mehr.

Ähnliches passiert auch bei Änderungen der Fensterdekoration über die KDE-"Systemeinstellungen".

Es ist nun nicht notwendig, sich nach einem solchen desaströsen Vorfall ab- und wieder anzumelden. (Leider funktioniert nämlich auch das Abmelden nicht verlässlich ... ). Solange man noch ein Terminalfenster öffnen kann, kann man den Windowmanager erneut starten.

Man muss dazu jedoch wissen, das sich das Kommando geändert hat. Statt "kwin &" ist das jetzt zu verwendende Kommando:

ich@mytux:~> kwin_x11 &

Ich hoffe, dieser Tipp hilft dem einen oder anderen.