[Eisfair] kthreadd invoked oom-killer

[Uwe Kunze]

> Ich bin nicht der Meinung, dass das der richtige Weg für alle ist, so
> lange das niemand ausser Dir verifizieren kann. Du kannst es gern mal
> bei Dir ausprobieren.

Nicht für alle ... nur als TEST(Paket), welches ich hier aufspielen könnte.

Ich würde den Kernel sicher auch selbst kompilieren können ... ich 
könnte mir nur vorstellen, dass Du das 'zigmal schneller machst, weil Du 
sicher ein "fertiges" Equipement (Scripte etc.) aufgebaut hast und ein 
Profi in dieser Hinsicht bist.

Außerdem fehlen mir die Quellen für die closed-Source-Treiber (AVM, 
dahdi), so dass ich keinen wirklich brauchbar produktiven Kernel 
erzeugen könnte.

Aber mal davon abgesehen ... es MUSS doch einen plausiblem Grund für 
diesen Mist mit dem angeblichen Speichermangel geben.

Warum sollen Programme (ob als eisfair-Paket oder aus anderen Sourcen 
kompiliert), die unter einem Kernel problemlos funktionieren, auf einmal 
unter einem anderen Kernel fehlerhaft sein ?

Es kann m.E. nach nicht richtig sein, die "Schuld" einzig auf die 
Anwendersoftware zu schieben. Was sollte man Deiner Meinung nach noch 
tun, außer das, was wir bereits gemacht haben ?
Die Speicherbeobachtung hat ergeben, dass der Speicherverbrauch zu 
keiner Zeit anormal ansteigt, eine Sekunde vor dem oom-Killer ist jede 
Menge Speicher verfügbar, der Swap wird überhaupt nicht angesprochen usw.

Schau Dir mal bitte den folgenden Link an.
Es geht um einen anderen kernel, aber die Beschreibung des Problems 
trifft exakt auf mein Problem zu.

https://marius.bloggt-in-braunschweig.de/2016/11/17/linuxkernel-4-74-8-und-der-oom-killer/

Gruß Uwe