# Probleme mit dem 340.102 Nvidia Treiber

## diabolusUmarov

Mahlzeit!

Seit dem letzten Systemupdate habe ich echte Probleme mit dem Nvidia-Treiber. Will ich mein System booten kommt unter anderem die Meldung, dass der Treiber bereits registriert sei. Das scheint aber weiter nicht zu stören. Kommt nun aber der Punkt, wo der X-Server gestartet wird kommt die Meldung, welche ich als Bild anhänge. Das System friert komplett ein uns es geht nichts mehr! Deshalb habe ich ein Bild davon gemacht.

Um mein System nun doch wieder zum Laufen zu bringen habe ich auf den nouveau Treiber umgestellt. Dem sagt man aber nach, dass er gerade im 3D bereich dem originalen Treiber hinterher hinkt. Mir macht derzeit am Meisten daran zu schaffen, dass Blender nicht mehr läuft, wenn ich den nouveau aktiv habe. Ansonsten hätte ich da jetzt nichts gemerkt, warum ich den originalen Treiber benutzen sollte. Vor Allem die Tatsache, dass der nouveau auch mit den neueren Kernel läuft würde mich eigentlich dazu veranlassen beim nouveau zu bleiben. Aber gut, der Originale sollte trotzdem laufen.

Hat jemand eine Idee, wo da das Problem liegen könnte?

http://diabolus-umarov.de/wp-content/uploads/2017/06/IMG_20170611_021721.jpg

----------

## Josef.95

Mahlzeit! :)

Schau mal ob der Patch aus Bug 615388 weiterhilft.

----------

## diabolusUmarov

Leider nein. Wenn ich den Patch mit einbauen will bekomme ich diesen Fehler

https://pastebin.com/NzLcykWa

----------

## Josef.95

Hm, vergiss das mit dem Patch bitte erst mal wieder - nach dem lesen des im Bugreport verlinkten nvidia-foren-Threads denke ich das es ein Irrweg ist, und das mit der nvidia-drivers-340.102 Version mit einem linux-4.9 Kernel wahrscheinlich kein Patch mehr benötigt werden sollte.

Magst du bitte mal das komplette dmesg via (no)paste-Dienst bereitstellen?

Nutzt du eventuell einen Framebuffer-Treiber wie vesafb oder uvesafb ?

falls ja, teste es bitte mal ohne.

----------

## diabolusUmarov

Hier kommt mein dmesg. Ich hoffe ich habe dich mit dem paste-dienst da richtig verstanden.

Framebuffer habe ich schon geprüft, daran liegt es anscheinend nicht.

https://pastebin.com/8yvnzCFJ

----------

## ZappeL

Ich sehe nen nouveau, evtl. mal das hier durcharbeiten (nouveau muss deaktiviert sein):

https://wiki.gentoo.org/wiki/NVidia/nvidia-drivers

----------

## diabolusUmarov

Ach so, mist! Natürlich läuft meine Kiste derzeit auf Nouveau. Dmesg kann ich auch gar nicht ausführen, wenn ich den nvidia-Treiber benutze, da das System dabei komplett einfriert. Vielleicht im Wiederherstellungsmodus, muss ich mal testen.

Ich muss aber auch dazu sagen, ich hatte zuvor den Nouveau gar nicht installiert, als die Probleme angefangen haben! Ich bin erst darauf ausgewichen, als der nvidia-Treiber seine Arbeit eingestellt hatte. Das Problem trat also definitiv auch ohne nouveau auf.

----------

## musv

Ich hab 4.10 und 4.11 damit zum Laufen gebracht:

https://forums.gentoo.org/viewtopic-t-1059660.html

Funktioniert bisher bei mir ohne jegliche Probleme. Den Patch hab ich aus den Patches für die neueren Nvidia-Treiber herausgezogen. Im Endeffekt mussten nur ein paar Zeilen entfernt werden, die es in der 340-er Serie noch nicht gibt. Aktuell verwende ich diesen Patch hier:

https://613884.bugs.gentoo.org/attachment.cgi?id=468528

Ich hab dabei das dumpfe Gefühl, dass nvidia seine Legacy-Treiber wohl nicht mehr für die neuen Kernelversionen ab 4.10 anpassen wird.Last edited by musv on Tue Jun 13, 2017 3:25 pm; edited 1 time in total

----------

## ZappeL

Problem ist gelöst.

Patch: http://dpaste.com/298ZW6W

Vorgehensweise war:

1. Kernel neu bauen (genkernel ~), natürlich ohne nouveau

2. Patch nach "/etc/patches/..." packen

3. nvidia-drivers neu bauen

[edit]:

Kernelversion ist 4.11.xx

----------

## ChrisJumper

Ja was ein Spaß!

Ich hatte mich durch diverse Foren-Beiträge gewühlt und letztlich konnte ich die patches nicht direkt anwenden weil Portage im /etc/portage/patches/x11-drivers/nvidia-drivers-340.102/ Verzeichnis Patches nur ausführt wenn:

- Die Datei .patch endet.

- Die Pfadangabe das ersten Verzeichnis ignoriert, aber alle Patches aus den NVIDIA Foren benannten direkt die Dateien.

Also kernel/nv-drm.c statt org/kernel/nv-drm.c oder patch/kernel/nv-drm.c.

----------

## musv

Ich mach das immer manuell: 

```

cd /usr/portage/x11-drivers/nvidia-drivers

ebuild nvidia-drivers-340.102.ebuild unpack
```

```

cd /var/tmp/portage/x11-drivers/nvidia-drivers/work

patch -p1 --dry-run < /pfad/zum/patch

patch -p1 < /pfad/zum/patch

```

Dabei kann ich mir nie merken, ob das jetzt p0 oder p1 ist.

```

ebuild nvidia-drivers-340.102.ebuild compile

ebuild nvidia-drivers-340.102.ebuild install

ebuild nvidia-drivers-340.102.ebuild qmerge

```

Durch das dry-run kann man auch gut ausprobieren, ob der Patch überhaupt noch kompatibel ist.

----------

## ChrisJumper

Ja das ist eigentlich eine gute Fingerübung. So hab ich es dann auch gemacht, wollte natürlich einen Patch direkt erstellen der Funktioniert und dabei ist mir aufgefallen warum es vorher nicht geklappt hatte.

Meine Gentoo-Admin Zeit wird aktuell auch immer weniger, daher fehlt mir nach Monaten ein wenig die Fingerübung. Ohne sich immer wieder neue Projekte oder Optimierung vorzunehmen fehlt der Antrieb und die Praxis. Denn der Rest läuft aktuell ziemlich Rund und wie geschmiert.

----------

## Josef.95

 *diabolusUmarov wrote:*   

> Leider nein. Wenn ich den Patch mit einbauen will bekomme ich diesen Fehler
> 
> https://pastebin.com/NzLcykWa

 

Hab mir das mal kurz angesehen, und ja, ich bekomme hier den gleichen Fehler.

Dem Patch fehlen oben in der Pfadangabe jeweils ein "/" Slash

Ändere mal bitte 

```
--- kernel/nv-drm.c   2016-12-15 12:41:26.000000000 +0100

+++ kernel/nv-drm.c   2016-12-15 12:58:48.000000000 +0100
```

 zu 

```
--- /kernel/nv-drm.c   2016-12-15 12:41:26.000000000 +0100

+++ /kernel/nv-drm.c   2016-12-15 12:58:48.000000000 +0100
```

 Damit sollte er funktionieren (hier tat er das beim Test).

----------

## musv

Ich hab mal einen Patch für die 4.12. erstellt. Diesmal hab ich das Ding sogar so angepasst, dass es einfach im Ebuild verwendet werden kann. 

https://bugs.gentoo.org/show_bug.cgi?id=627550

Viel Spaß damit.

----------

## Josef.95

@musv,

danke, ist ja gut gemeint, aber einen Gentoo-Bug dafür zu eröffnen wird wahrscheinlich nichts bringen, da Gentoo ausschließlich Treiber supportet so wie sie von Upstream kommen. Wahrscheinlich wird man den Bug mit [Invalid] schließen (es gibt zig Beispiele im Bugtraker, wo das genau so geschehen ist).

Wahrscheinlich wird der Gentoo-Meintainer drauf verweisen hierfür ggf einen Upstream-Bug zu eröffnen.

Siehe zb auch den Hinweis im 

```
        if use kernel_linux && kernel_is ge 4 10; then

                ewarn "Gentoo supports kernels which are supported by NVIDIA"

                ewarn "which are limited to the following kernels:"

                ewarn "<sys-kernel/gentoo-sources-4.10"

                ewarn "<sys-kernel/vanilla-sources-4.10"

                ewarn ""

                ewarn "You are free to utilize eapply_user to provide whatever"

                ewarn "support you feel is appropriate, but will not receive"

                ewarn "support as a result of those changes."

                ewarn ""

                ewarn "Do not file a bug report about this."

                ewarn ""

        fi
```

----------

## musv

Mag sein, aber zumindest kann man sich dann von dort den Patch und die Änderung im Ebuild ziehen.

----------

## ChrisJumper

Liebe Leidensgenossen des nvidia-drivers-340.102,

heute solltet ihr wegen dem Spectre-NG Bugs auf Kernel 4.16.11 oder 4.14.43 oder 4.9.102 updaten.

Infos zu den normalen Nvidia-Treibern:

https://devtalk.nvidia.com/default/topic/1030082/linux/kernel-4-16-rc1-breaks-latest-drivers-unknown-symbol-swiotlb_map_sg_attrs-/1

Der Treiber ist dafür natürlich noch nicht angepasst. Ich konnte ihn aber übersetzen wie gewohnt, doch es bootet ohne X weil das Modul beim Laden fehl schlägt.

```

Security Options -->

[*] Harden memory copies between kernel and userspace

[*]     Allow usercopy whitelist violations to fallback to object size

```

Bin nicht sicher ob CONFIG_HARDENED_USERCOPY der Schutz für /sys/devices/system/cpu/vulnerabilities/spec_store_bypass ist, aber ich habe es als neues Feature in meine Kernel gebaut.

Wenn CONFIG_HARDENED_USERCOPY_FALLBACK=y funktioniert auch das starten des Systems und der Treiber wird geladen. Allerdings wird auch eine Warnung notiert das der Kerneltreiber den Fallback ausgelöst hat.

P.s: Bei den normalen Nvidia-Drivers (396.24) habe ich das noch nicht getestet, er kompiliert aber normal und ich denke mit dem Fallback sollte dieser auch vorerst starten.

----------

