Soort nep-deadlocks m.b.t de Nvidia drivers in Linux

[fighuass]

Hallo, ik heb een probleem in Linux waarbij ik her en der willekeurig een soort deadlocks aantref. Het zijn geen echte deadlocks, want ik kan nog steeds tijdens deze gevallen via een VNC cliënt op mijn tablet de PC bedienen. KWin crasht tijdens deze deadlocks ook. Het vermoeden is dat dit een driver probleem is dat de X display server doet crashen. Heeft iemand hier een fix voor?
...

Ik gebruik Kubuntu 20.04 met de officiële Nvidia drivers (455.23.04). Verdere relevante specs zijn een i5-4440 CPU en een GTX 970 GPU.
...

Ik heb al eerder op reddit hierover gepost (https://www.reddit.com/r/...seudodeadlocks_every_now/), daar zijn ook log bestanden te vinden, maar zoek een second opinion hier (is namelijk best een ernstig probleem).
...

[Hero of Time]

Zonder de logs hier zelf te posten kunnen we niets. Ik ga iig niet een andere pagina bezoeken op zoek naar foutmeldingen waar jij last van hebt, als deze ook net zo makkelijk verwijdert kunnen worden.

Je zegt ook dat je met VNC alsnog je PC kan bedienen. Leuk, welke van de tig soorten VNC implementaties gebruik je? Neem je werkelijk je bestaande X sessie over of wordt er een nieuwe sessie gestart?

Wat is de noodzaak voor de gesloten drivers, waarom kan je niet de nouveau driver gebruiken? Heb je ook al een andere desktop omgeving of window manager geprobeerd, of instellingen van kwin aangepast?

Zo veel vragen, zo weinig informatie...

[fighuass]

Dan zal ik hier de logs nogmaals posten:

Hier is een dmesg log: https://cryptpad.fr/pad/#...sURQYD-4dfErEgpvOY/embed/

En hier van de command journalctl -xe: https://cryptpad.fr/pad/#...AYuT60zZotXvt7F2Zw/embed/

Qua VNC gebruik ik RealVNC op de PC en VNC Viewer op m'n Android tablet.

Nouveau gebruik ik niet omdat ik na onderzoek gedaan te hebben tot de conclusie kom dat deze qua performance totaal inferieur zijn vergeleken met de officiële drivers, en ik game ook op deze PC namelijk. Een andere DE of WM zou ik liever niet gebruiken, ik neem aan dat KDE en KWin nogal hecht gebonden is aan Kubuntu zelf? Maar ik zou denk ik ook wel een Timeshift backup kunnen maken, iets anders testen en dan terugrollen na die tijd, ik kom hier nog op terug dan. Qua settings in KWin heb ik niet echt iets aangepast, het is gewoon standaard. En ik zie verder ook niet veel relevants om nu aan te passen ivm het probleem.

[Hero of Time]

Irrelevant waarschijnlijk, maar je Bitwarden gaat nogal hard over z'n zuiger. Iets om ook eens naar te kijken.

De stacktrace valt weinig over te zeggen. Je kan eens kijken of je de modeset optie kan uitschakelen.

Een andere WM/DE gebruiken is niet zo moeilijk. Je kan bijvoorbeeld Xfce in een kale vorm aan je systeem toevoegen door de packages xfce4-panel, xfce4-session, xfdesktop4 en xfwm4 te installeren. Dan bij het inlogscherm kan je kiezen voor Xfce als sessie ipv Plasma.

RealVNC zie ik niet in mijn repo (die van Debian) staan. Ik kan op hun site, realvnc.com, slecht vinden hoe het precies werkt met X11. Ik kan daarom niet bevestigen of er een nieuwe sessie wordt gestart of je huidige wordt overgenomen. Daar geef je zelf ook geen antwoord op.

[DataGhost]

Hoeveel geheugen is er in gebruik op je machine? Ik zie dat je 4GB normaal geheugen hebt en geen swap. De driver klaagt om een "nvidia-modeset/: page allocation failure: order:4" waar een van de mogelijke oorzaken zou kunnen zijn dat je geheugen op is. Kan je met free -m of mischien liever, met cat /proc/meminfo eens kijken hoe en wat?

Segfaults in bitwarden kunnen iets simpels zijn als een try-catch om iets wat een nullpointer-exception veroorzaakt (tenminste, dat is/was in Java zo, dit is C#) maar die vind ik weer een stuk minder logisch in libQt5Core, waar ook segfaults optreden. Dat kan ook komen door een instabiel systeem en dan is geheugen de eerste verdenking, dus dat zou je nog kunnen testen.

[fighuass]

Hero of Time schreef op dinsdag 20 oktober 2020 @ 12:07:
Irrelevant waarschijnlijk, maar je Bitwarden gaat nogal hard over z'n zuiger. Iets om ook eens naar te kijken.

De stacktrace valt weinig over te zeggen. Je kan eens kijken of je de modeset optie kan uitschakelen.

Een andere WM/DE gebruiken is niet zo moeilijk. Je kan bijvoorbeeld Xfce in een kale vorm aan je systeem toevoegen door de packages xfce4-panel, xfce4-session, xfdesktop4 en xfwm4 te installeren. Dan bij het inlogscherm kan je kiezen voor Xfce als sessie ipv Plasma.

RealVNC zie ik niet in mijn repo (die van Debian) staan. Ik kan op hun site, realvnc.com, slecht vinden hoe het precies werkt met X11. Ik kan daarom niet bevestigen of er een nieuwe sessie wordt gestart of je huidige wordt overgenomen. Daar geef je zelf ook geen antwoord op.

Bitwarden? Dat is wel heeeeeel raar, waar zal ik naar kijken? Desnoods zou ik echter ook nog de extensie kunnen gebruiken ipv de AppImage als het echt een probleem zou zijn, trouwens.

Hoe zet ik de modeset optie uit? Ik zal XFCE ook proberen.

Ja, volgens iemand op reddit is het meer een X11 probleem aangezien VNC wel werkt dus ik neem aan dat RealVNC daar los van staat. Ik heb hier ook nog weinig verstand van als Linux noob dus kan hier verder nog weinig over zeggen.

DataGhost schreef op dinsdag 20 oktober 2020 @ 12:37:
Hoeveel geheugen is er in gebruik op je machine? Ik zie dat je 4GB normaal geheugen hebt en geen swap. De driver klaagt om een "nvidia-modeset/: page allocation failure: order:4" waar een van de mogelijke oorzaken zou kunnen zijn dat je geheugen op is. Kan je met free -m of mischien liever, met cat /proc/meminfo eens kijken hoe en wat?

Segfaults in bitwarden kunnen iets simpels zijn als een try-catch om iets wat een nullpointer-exception veroorzaakt (tenminste, dat is/was in Java zo, dit is C#) maar die vind ik weer een stuk minder logisch in libQt5Core, waar ook segfaults optreden. Dat kan ook komen door een instabiel systeem en dan is geheugen de eerste verdenking, dus dat zou je nog kunnen testen.

In gebruik zou ik niet durven zeggen, neem aan dat dat varieert. Ik heb echt wel 1x 8GB RAM, niet 4GB. Zou er iets fout kunnen zijn met het geheugen in dat geval? Of refereer je hier naar het geheugen van de videokaart, welke wel 4GB is? Ik heb ook inderdaad geen swap, want ik heb er wat over gelezen maar het schijnt niet echt heel belangrijk te zijn tegenwoordig.

De output van cat /proc/meminfo is als volgt: https://pastebin.com/raw/kzMsEidp
En free -m zegt: https://pastebin.com/raw/kKwujD3d

Wat zal ik doen volgens je laatste regel?

[DataGhost]

Oeps, ik zag 4.7GB staan maar miste de 3.6GB er vlak boven. De output van meminfo is eigenlijk juist boeiender op het moment dat het misgaat, of juist vlak daarvoor. Als het zo is (dat hoeft niet zo te zijn) dat je geheugen volloopt kan je driver ook geen geheugen meer krijgen. Vaak zie je dan een OOM-oops die dus wat anders is dan deze maar ik weet niet hoe de nvidia-driver allocations regelt. Volgens de errormessage zat het in die buurt in ieder geval, dus dat zou een van de mogelijke verklaringen kunnen zijn.

Als zoiets gebeurt zal je systeem normaal proberen iets uit het geheugen te halen en in swap te stoppen. Dat is dus een soort extra buffer, waardoor je uiteindelijk effectiever gebruik kan maken van je geheugen. Nu kan je eigenlijk met goed fatsoen niet de hele 8GB die je hebt gebruiken, aangezien elke byte die je daar per ongeluk overheen gaat direct als gevolg heeft dat er een programma wordt afgeschoten (of een driver misschien) dus je zal in de praktijk altijd toch zeker zo'n 500MB speelruimte moeten houden. Als je nu 4GB swap hebt ofzo, kan iets weiniggebruikts worden uitgeswapt waardoor je meer geheugen overhebt en worden er pas dingen afgeschoten bij 12GB gebruik. Je systeem wordt pas noemenswaardig traag op het moment dat je echt goed over je 8GB heen bent, daarvoor is het niet of nauwelijks merkbaar. Ten slotte heb je vast ook zat geheugengebruik van programma's die draaien maar waar je eigenlijk vrijwel nooit iets mee doet. Die zullen vast ook een keer in swap belanden, misschien zelfs nog voordat als je normale geheugen vol is geweest. Dat zorgt er dan wel voor dat je effectief meer geheugen vrijhebt voor cache, wat juist een kleine snelheidswinst op zou kunnen leveren. Kortom: het hebben van swap vertraagt je systeem in principe niet bij normaal gebruik, zorgt ervoor dat je bij incidenteel overgebruik niet random processen kwijtraakt en zou zelfs een kleine theoretische versnelling kunnen opleveren.

Wat betreft de segfaults: je zou met memtest86(+) eens kunnen testen of je geheugen wel stabiel is. Dan kan je dat in ieder geval uitsluiten.

Als je geheugen niet volloopt en memtest na 12-24 uur nog geen fouten heeft laten zien is het inderdaad aannemelijk dat het aan de driver ligt. Dan moet je software gaan uitsluiten, zoals @Hero of Time zei kan je naar andere WMs kijken of iets met je instellingen doen. De nouveau-drivers zijn zeker een suggestie, ook al is de performance minder, al is het alleen maar om te kijken of het probleem daarmee ook optreedt. Ten slotte kan je natuurlijk proberen oudere versies van de nvidia-drivers te gebruiken om te zien of die het issue ook hebben. Hardware-problemen (specifiek je videokaart) hebben trouwens ook vaak drivercrashes als gevolg. Dat zou je met een andere GPU moeten kunnen uitsluiten.

[fighuass]

Waar kan ik memtest86(+) vinden? Ik meende zoiets vaagjes in m'n ooghoek te zien op het GRUB menu toen ik Kubuntu installeerde via de USB, maar ik heb net weer geprobeerd in de USB te booten maar kom gewoon direct in de OS zelf zonder deze opties.

En over de swap, ik zou eigenlijk dus beter swap kunnen gebruiken? Is er nog een manier om swap aan te maken na de installatie? Want ik heb nu gewoon één grote root partitie (BTRFS), een (U)EFI partitie en verder niks.

Verder denk ik dan dat ik eerst zal wachten totdat ik weer een deadlock krijg (ik post dan opnieuw de meminfo), en wanneer dit gebeurt zal ik andere dingen proberen zoals XFCE, een andere WM (alhoewel als dit ook in XFCE gebeurt zal een WM zeker niet zoveel verschil meer maken, toch?), oudere drivers, etc.

EDIT: Ik zie ook net dat ik een kernel update heb (alhoewel een kleine), geen idee of dit een verschil maakt maar ik zal deze ook maar even installeren.

[ Voor 9% gewijzigd door fighuass op 20-10-2020 16:04 ]

[Hero of Time]

Memtest kan je krijgen door simpelweg deze via apt te installeren. Er is memtest86 en memtest86+. Zie de omschrijving voor de verschillen.

Als je Xfce draait, dan heb je ook gelijk een andere window manager, mits je uiteraard xfwm4 hebt geïnstalleerd. Anders draait er geen.

Swap is ook als bestand aan te maken ipv een partitie. De Ubuntu wiki legt vast en zeker uit hoe je dit kan maken. En anders is er gegarandeerd wel ergens anders een wiki of blogpost met deze informatie.

[DataGhost]

Nja memtest kan je toch zeker wel googlen? Het kan zijn dat 'ie al op je Kubuntu-stick staat ja, maar dan moet je wel zeker weten dat je ervan boot (en niet van je normale harddisk) en je het keuzemenu van de bootloader triggert.

Wat betreft swap, dat kan je met een swapfile doen. Icm btrfs lijkt het me handig om deze guide te gebruiken: https://askubuntu.com/que...-have-a-swapfile-on-btrfs. Als je uiteindelijk wilt weten waar het probleem precies vandaan komt zou ik steeds maar 1 ding tegelijk veranderen. Als je tegelijkertijd een swapfile begint te gebruiken en een andere WM en andere drivers dan weet je het nog niet natuurlijk.

Hero of Time schreef op dinsdag 20 oktober 2020 @ 16:19:
Memtest kan je krijgen door simpelweg deze via apt te installeren. Er is memtest86 en memtest86+. Zie de omschrijving voor de verschillen.

Ah, weer wat geleerd. Eigenlijk heel logisch, zo zet ik het zelf ook op op mijn machines in de bootloader, maar dan handmatig

[ Voor 23% gewijzigd door DataGhost op 20-10-2020 16:21 ]

[fighuass]

Oké, ik heb net de memtest86 gedaan (niet + want die is kennelijk niet voor UEFI beschikbaar). Geen problemen in deze hoek.

Dus, zoals ik net zei wacht ik eerst af tot er weer een deadlock komt, dan deel ik de info daarvan en daarna ga ik zoals DataGhost al zegt steeds 1 voor 1 iets aanpassen totdat het probleem verdwijnt.

[Hero of Time]

Je hebt de test nog geen 2 uur laten draaien, terwijl 12-24 werd geadviseerd? Hoeveel passes heeft het gedaan? Vast maar 1, en dat zegt nog steeds bar weinig. Vaak komen fouten pas met de derde of later naar voren.

Heb je sinds het openen van dit topic nog updates toegepast? Zo niet, en als het issue vaker is voorgekomen, pas dan die kernel update toe en kijk het dan aan. Want dat het probleem weer zal komen, tijdens het gamen (vermoed ik), kunnen we in principe wel vanuit gaan.

[DataGhost]

Inderdaad. Als het een geheugenprobleem blijkt te zijn, en het issue manifesteert zich normaal niet binnen 1-2 uurtjes, is het niet waarschijlijk dat je het probleem gaat vinden met een test die significant korter loopt. Het lastige aan een geheugentest is dat deze nooit kan zeggen dat je geheugen goed is, dat kan alleen maar heel erg aannemelijk gemaakt worden. Op het moment dat er fouten gevonden worden kan wel met zekerheid gezegd worden dat het kapot is (of het mobo of de geheugencontroller). Maar door het karakter van de fouten kan het zomaar een paar uur duren voordat je een fout te zien krijgt. Daarom is het standaardadvies voor een geheugentest zo'n 12-24 uur, dan pas kan je dat met redelijke zekerheid uitsluiten. Een keer een nachtje en liefst wat langer laten draaien dus, op zoveel mogelijk passes als dat instelbaar is.

Ik moet daar wel bij zeggen dat het slechts een mogelijkheid is. Het probleem manifesteert zich elke keer op dezelfde manier (toch?) en bij geheugenfouten zou je meer willekeurige, verschillende problemen verwachten.