Beiträge von Eldrad Ulthran

    Mit Nouveau schieß ich mir doch nur selber ins Bein, oder?
    Klar, im normalen Betrieb läuft nur die Intel, aber ab und zu, wenn ich unterwegs bin, will ich abends mal was zocken.


    Ich habe gerade noch die ganzen anderen Vorschläge, die auf SDB:NVIDIA Bumblebee - openSUSE Wiki angegeben sind, mal durchprobiert, also zunächst die Grafikkarte und nvidia in die TLP-Blacklist gesetzt, ohne Effekt. Dann den Fix für GT600M/GT700M-Karten (Kepler) (obwohl ich eine 940MX (Maxwell) habe) angewandt, der darin besteht, dass bbswitch beim Laden nicht mehr die GPU ausschalten, sondern sie in ihrem Zustand belassen soll, indem ich in /etc/modprobe.d/50-bbswitch.conf den Eintrag "load-state=0" zu "load-state=-1" geändert habe. Eh voila, jetzt fällt die GPU beim Booten nicht mehr vom Bus, und optirun lässt sich ohne den im ersten Post erwähnten Workaround aufrufen.


    Aus unterschiedlichen Quellen habe ich noch ein paar empfohlene Änderungen für /etc/bumblebee/bumblebee.conf: Driver=nvidia (damit nicht mal die Versuchung entsteht, Nouveau zu laden), TurnCardOffAtExit=true (GPU soll nach Gebrauch ausgeschaltet werden) und KeepUnusedXServer=true (brauchte ich für das Spiel Stellaris, das über einen Launcher gestartet wird und sonst nicht mit optirun läuft).


    Dennoch habe ich nach Aufruf von optirun folgende Einträge in Xorg.8.log, sollte ich mir darüber Gedanken machen?

    Code
    egrep "EE|WW" /var/log/Xorg.8.log
    [  1271.719] (WW) The directory "/usr/share/fonts/misc/sgi" does not exist.
    [  1271.721] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
    [  1272.190] (WW) NVIDIA(0): Unable to get display device for DPI computation.
    [  1272.215] (WW) NVIDIA(0): Option "NoLogo" is not used
    [  1272.276] (WW) <default pointer>: No Device specified, looking for one...
    [  1272.676] (EE) kbd: <default keyboard>: failed to set us as foreground pgrp (Inappropriate ioctl for device)
    [  1272.694] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied

    @Berichtigung: Die relevanten Modulversionen müsste ich ja sowohl mit modinfo nvidia… als auch for nvm in /lib/modules/*/updates/nvidia*.ko; do echo $nvm \:; strings $nvm | grep -E \^version=; done kriegen, richtig? Jedenfalls haben nvidia, nvidia-modeset und nvidia-drm die Versionen 410.78, während für nvidia-uvm keine Version angezeigt wird.
    Die Versionen der anderen Module sind ja recht egal, oder? "drm" hat beispielsweise keine, bbswitch ist 0.8, ipmi_messagehandler ist 39.2… Jedenfalls trägt jedes Modul die gleiche Kernelversion im Dateipfad (aktuell 4.12.14-lp150.12.28-default).
    Oder muss ich noch was anderes überprüfen?


    @Sauerland: Diese Anleitungen kenne ich – nachdem ich die erste pflichtbewusst Zeile für Zeile abgearbeitet habe, kam das Installationschaos zustande. Da sind auch fiese Fehler in der Anleitung, beispielsweise soll man an einer Stelle das Nvidia-Repository einbinden und den Nvidia-Treiber installieren. Wenn man dann im nächsten Schritt nvidia-bumblebee installiert, wird ein Paketkonflikt gemeldet und der Nvidia-Treiber wieder deinstalliert. Du hattest weiter oben einen Bugreport verlinkt, in dem in einem der Beiträge empfohlen wurde, auf die meisten Schritte dieser Anleitung zu verzichten und nur die Punkte "Install Bumblebee" und "Tumbleweed" zu befolgen. Das habe ich jetzt auch gemacht, mit der kleinen Abweichung, dass ich das Leap15- statt Tumbleweed-Repo eingebunden habe.
    In der "alten" Anleitung steht noch, man soll das Paket-Schema devel-kernel installieren – explizit das Schema war bei mir nicht installiert, aber alle darin verknüpften Pakete, sodass nur das 58B "große" Pattern-Paket installiert wurde.
    Ansonsten habe ich alles wie in den Anleitungen beschrieben bereits gemacht.

    egrep "nou|nv|bum|bbs" zeigt alle Zeilen an, die eine dieser vier Buchstabenfolgen beinhalten (wortwörtlich "nou" oder "nv" oder "bum" oder "bbs"), also mehr als grep nvi. Alles, was "nvi" beinhaltet, muss auch "nv" beinhalten, daher verstehe ich deinen Einwand zugegeben nicht.
    Im Idle-Zustand ist das einzige geladene Modul "bbswitch". Läuft optirun glxspheres im Hintergrund, kommen folgende Einträge hinzu:

    Code
    lsmod | egrep "nou|nv|bum|bbs"
    nvidia_uvm            884736  0
    nvidia_drm             49152  3
    nvidia_modeset       1044480  3 nvidia_drm
    nvidia              16617472  156 nvidia_modeset,nvidia_uvm
    bbswitch               16384  0
    drm_kms_helper        200704  2 i915,nvidia_drm
    ipmi_msghandler        49152  2 nvidia,ipmi_devintf
    drm                   438272  13 i915,nvidia_drm,drm_kms_helper

    Meine Reinigungsschritte: systemctl disable dkms bumblebeed aufgerufen, alle Pakete aus dem X11:bumblebee-Repository gelöscht, dieses Repo deaktiviert, verwaiste und unbenötigte Pakete deinstalliert (über Yast), zypper dup hatte danach nichts mehr zu tun. Mittels find / -iname *nvidia* Bruchstücke gesucht und alle leeren Ordner, kaputte Links und Dateien, die zu keinem Paket gehören, gelöscht. Dann in /etc/modprobe.d/50-blacklist.conf "blacklist nouveau" eingefügt, damit es nicht geladen wird. depmod -a und mkinitrd aufgerufen und neu gestartet.
    Hiernach ist folgender Zustand: lsmod | egrep "nou|nv|bum|bbs" gibt gar nichts aus, Dateien mit nvidia im Namen sind nur folgende:

    Jetzt müsste das System also bereinigt sein.


    Also wieder das Bumblebee-Repo aktiviert, die Pakete bumblebee, bbswitch, primus-32bit, nvidia-bumblebee, nvidia-bumblebee-32bit installiert, systemctl enable bumblebeed dkms und mkinitrd aufgerufen, rebootet.


    Die Situation ist die gleiche: Beim Booten fällt die GPU vom Bus. Hier der vollständige Output von dmesg nach dem Ausführen des oben genannten Workarounds, nach dem optirun wieder läuft:dmesg_nach_workaround.txt
    Und noch ein paar Fehlermeldungen aus Xorg.8.log:

    Code
    egrep "EE|WW" /var/log/Xorg.8.log
            (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
    [   287.079] (WW) The directory "/usr/share/fonts/misc/sgi" does not exist.
    [   287.080] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
    [   287.782] (WW) NVIDIA(0): Unable to get display device for DPI computation.
    [   287.810] (WW) NVIDIA(0): Option "NoLogo" is not used
    [   287.974] (WW) <default pointer>: No Device specified, looking for one...
    [   288.373] (EE) kbd: <default keyboard>: failed to set us as foreground pgrp (Inappropriate ioctl for device)
    [   288.432] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied

    Zunächst ab ich wie im Bugreport beschrieben eine Neuinstallation versucht, die aber nichts geändert hat.
    Mithilfe des Befehls im vorletzten Beitrag for nvm in /lib/modules/*/updates/nvidia*.ko; do echo $nvm \:; strings $nvm | grep -E \^version=; done habe ich aber herausgefunden, dass von meinen ersten Bumblebee-Anläufen noch veralteter Krempel in besagtem Ordner übrig geblieben war, der bei der Paketdeinstallation nicht gelöscht wurde. Bei mir waren die Dateien nvidia-modeset.ko und nvidia-uvm.ko überflüssig (am alten Zeitstempel erkannt). Nach Löschen und mkinitrd ist der Version mismatch nun behoben.
    Am Rest hat sich aber nichts geändert: Beim Booten fälllt nvidia immer noch vom Bus, und ich muss den Workaround als root ausführen, bevor ich die GPU nutzen kann.

    Guten Tag,


    (nicht zum ersten Mal) habe ich gewisse Schwierigkeiten bei der Verwendung von bumblebee unter Leap 15.0 auf einem Lenovo E470 20H2-S00700 (i7 7500U mit integrierter Intel HD Graphics 620 sowie einer separaten GTX 940MX). Ich habe das Bumblebee-Repository eingebunden, die Pakete bbswitch, bumblebee, nvidia-bumblebee, dkms, primus installiert, systemctl enable bumblebeed und systemctl enable dkms mkinitrd ausgeführt. Nach dem Reboot kriege ich in dmesg lauter Einträge mit:


    Code
    NVRM: The NVIDIA GPU 0000:01:00.0
                   NVRM: (PCI ID: 10de:134d) installed in this system has
                   NVRM: fallen off the bus and is not responding to commands.
    [    2.292635] nvidia: probe of 0000:01:00.0 failed with error -1
    [    2.292647] NVRM: The NVIDIA probe routine failed for 1 device(s).
    [    2.292647] NVRM: None of the NVIDIA graphics adapters were initialized!

    Folglich läuft auch optirun nicht. Das Kompilieren mittels dkms läuft laut /var/lib/dkms/nvidia/410.73/4.12.14-lp150.12.28-default/x86_64/log/make.log jedoch ohne Probleme durch. Ich habe hier einen Workaround gefunden (als su ausgeführt), mit dem ich für die Dauer einer Session die GPU mittels optirun verwenden kann:



    Code
    systemctl stop bumblebeed
    rmmod nvidia
    rmmod bbswitch
    echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove
    echo 1 > /sys/bus/pci/devices/0000:00:02.0/rescan
    modprobe bbswitch
    systemctl start bumblebeed

    Das muss ich aber nach jedem Reboot erneut ausführen. Was das aber macht, verstehe ich nicht so richtig, und gibt es vielleicht die Möglichkeit, auf diesen Extraschritt zu verzichten, sodass optirun von Anfang an funktioniert?


    Noch ein paar Infos, die hoffentlich hilfreich sind:
    Nachdem ich den Workaround ausgeführt habe, erscheinen u.a. folgende Meldungen in dmesg: dmesg_nach_workaround.txt Gerade das Version mismatch irritiert mich sehr, woher kommt das?


    Falls noch weitere Infos gebraucht werden, gebe ich sie gerne an.


    Was ich noch nicht vestanden habe, ist, was du meinst mit dem "Umschalten auf mtp im Smartphone"?
    Wie geht das __genau__? Was tust du da __exakt__?

    Wenn ich das Handy per USB-Kabel anschließe, erscheint auf dem Handy ein Popup, das mich zu einem Menü führt, in dem ich auswählen kann, wie sich das Handy verhalten soll. Die Standardauswahl ist immer "Nur Laden" – solange das ausgewählt ist, hat der PC nur Zugriff auf die Pseudo-CD, aber nicht die eigentlichen Dateien aufm Handy. Wenn ich dann "Geräte-Dateimanager (MTP) – Dateien per Computer übertragen und verwalten" auswähle, wird die Verbindung zum PC unterbrochen und neu aufgebaut, wonach ich eben zwei Geräte sehe: Immer noch die Pseudo-CD und den eigentlichen Datenträger.
    Zusätzlich könnte ich aufm Handy noch auswählen:
    "Kamera (PTP) – Ermöglicht die Übertragung von Fotos mithilfe der Kamera-Software sowie die Übertragung von Dateien auf Computer, die MTP nicht unterstützen"
    "Umgekehrtes Laden – Das andere verbundene Gerät aufladen"
    "MIDI – Gerät für MIDI-Eingaben verwenden"


    Völlig richtig, ich habe mein Ziel erreicht, ich kann vom PC aus mithilfe von Dolphin auf die Fotos zugreifen. Dass ich das Gerät nicht mounten und damit keine Konsole öffnen kann, ist mir egal. Wenn ich das auch auf meinem Arbeitsplatzrechner reproduzieren kann, werde ich den Thread als erledigt markieren.


    Und dir natürlich ein Dankeschön für den historischen Exkurs :)

    Den live-Mitschnitt von journalctl hab ich zwar schon in gekürzter Form im ersten Post eingefügt, hier aber nochmal in voller Länge mit ganz viel Plasma-Krempel.
    Beim Einstecken:


    Nach Umschalten auf MTP aufm Handy (siehe Anhang, der Beitrag wurde zu lang)journal.txt




    Dann der Versuch zu mounten;

    Code
    mount /dev/sr0 /mnt/huawei/
    mount: /mnt/huawei: WARNING: device write-protected, mounted read-only.

    Und im logfile:

    Code
    Dec 25 00:25:07 linux-peha kernel: ISO 9660 Extensions: Microsoft Joliet Level 1
    Dec 25 00:25:07 linux-peha kernel: ISOFS: changing to secondary root
    Dec 25 00:25:07 linux-peha plasmashell[2252]: file:///usr/share/plasma/plasmoids/org.kde.plasma.devicenotifier/contents/ui/FullRepresentation.qml:136:25: Unable to assign [undefined] to QString
    Dec 25 00:25:07 linux-peha plasmashell[2252]: file:///usr/share/plasma/plasmoids/org.kde.plasma.devicenotifier/contents/ui/FullRepresentation.qml:136:25: Unable to assign [undefined] to QString

    Leider ist /dev/sr0 das falsche Gerät, es handelt sich dabei um eine Pseudo-CD, auf der für Windows ein Autostart-Setup für die Huawei HISuite.exe liegt. Im Ordner Document liegt noch eine pdf mit Notizen zum Copyright, sonst nichts.

    Code
    ll /mnt/huawei/
    total 1939
    -r-xr-xr-x 1 root root      73 Sep  2  2016 Autorun.inf
    dr-xr-xr-x 1 root root    2048 Oct 16  2015 Document
    -r-xr-xr-x 1 root root   25718 Oct 16  2015 HiSuite.ico
    -r-xr-xr-x 1 root root 1956552 Apr 19  2016 HiSuiteDownLoader.exe

    Das Handy gibt sich nämlich als zwei Geräte aus, die auch als zwei Einträge in der Plasma-Taskleiste angezeigt werden. Einer als optische Disk "My CDROM", den ich schon immer problemlos mit dem Filebrowser öffnen konnte und auf dem nur diese paar Dateien sind, und ein zweiter als tragbarer Medienspieler "EVA-L09", über den ich (seit kio_mtp) Zugriff auf die eigentlichen Dateien auf dem Handy kriege.

    Im Westen nichts Neues. Handy eingesteckt und auf MTP umgeschaltet, dann mtpfs als root aufgerufen und die gleiche Fehlermeldung wie sonst erhalten:

    Code
    mtpfs /mnt/huawei
    Listing raw device(s)
    Device 0 (VID=12d1 and PID=107e) is a Huawei P9 Plus.
       Found 1 device(s):
       Huawei: P9 Plus (12d1:107e) @ bus 1, dev 3
    Attempting to connect device 0
    Android device detected, assigning default bug flags
    Listing File Information on Device with name: HUAWEI P9


    Jedoch ohne Zugriff:

    Code
    ll /mnt/huawei
    ls: cannot access '/mnt/huawei': Transport endpoint is not connected

    journalctl | grep -i mtp liefert nach wie vor gar nichts, auch wenn nun die Aufzeichnungen nicht mehr überschrieben werden.
    Exakt das gleiche passiert, wenn ich aufm Handy in den Entwickleroptionen USB-Debugging aktiviere.
    Ausgabe von dmesg im betreffenden Zeitrahmen:

    Und jetzt wünsche ich erst mal ein frohes Fest! :)