nachdem wir das Downloadproblem mit einem Kernelparameter bei der ersten HW-Klasse in den Griff bekommen haben (bei der zweiten noch nicht), dauert dafür der „Neu+Start“ des Betriebssystems ca. 10 Mal so lang wie „vorher“ (LMN 7.1->7.2, Linbo 4.0.x->4.1.36,…?), d.h. über 1Std statt ca. 6 min!
Fun fact: bei der zweiten HW-Klasse ist es genau andersherum: Download ist nur noch ca. 25MB/s statt vorher ca. 100MB/s, dafür „neu+starten“ die genauso schnell wie vorher!?
Muss ich das verstehen? Habt Ihr ne Idee für
a. Kernelparameter für HW-Klasse 2 (modprobe.blacklist=r8169 und loadmodules=r8168 (einzeln, noch nicht in der Kombi) schon erfolglos versucht
b. das Neu+Start-Problem von HW-Klasse 1!? Das hat ja sicher nichts mehr mit der (Realtek-)NIC zu tun.
Vielen Dank für’s Mithirnen und viele Grüße,
Jochen
ich würde erstmal testen, was passiert, wenn du garkeinen
Kernelparameter mehr mit gibts.
Wenn du an den Kernelparametern in der start.conf.GRUPPE rum machst:
immer dran denken: linuxmuster-import-devices ist nötig, und die
/srv/linbo/boot/grub/GRUPPE.cfg muss die richtige managed by linuxmuster.net Zeile enthalten.
Hallo Jochen,
bist Du bei Dir schon weitergekommen? Wir haben nach dem Update auf 7.2, und in dem Fall auf Linbo 4.1.36 auch mit einer Hardwareklasse (Dell Optiplex3060 mit einer Realtek NIC) auch sehr ähnliche Probleme. Beim Download des Images kommen wir auch nicht mit der Datenrate höher als ziemlich genau 25600K/s.
Der Download wird dann zwar erfolgreich abgeschlossen, aber das Synchen bricht fast immer bei ca. 99,06 % ab. Damit landet Windows dann beim Startversuch in einem Bluescreen. Wir vermuten bei uns aber ein Problem mit dem Plattencontroller weil wir die HDDs gegen NVMe Riegel getauscht haben. Mit Linbo 4.0.x lief die Konstellation prima. Mit Linbo 4.1.36 nicht mehr. Mein Versuch für morgen wäre jetzt erst mal den NVMe Riegel nacheinander gegen eine SSD und HDD zu tauschen und dann auch noch den alten Linbo 4.0.x mit einem USB Stick zu booten. Jetzt muss ich nur noch schauen wo ich den alten 4er Linbo also iso her bekomme.
nein, wir haben heute nochmal getestet aber keine Lösung gefunden.
Auch wir haben NVMe SSDs drin, der Sync (neu+start) dauert statt ca. 8 min nun fast 80 min (!) und bricht manchmal (nicht immer) ab.
An Kernelparameter die Netzwerkkarte betreffend glaube ich nicht, vielleicht hat sich ja , wie Du auch vermutest, mit dem neuen Linbo was bezüglich des Plattencontrollers geändert?
Hallo Jochen,
eins der zwei Probleme konnten wir bei uns lösen: mit dem Kernelparameter „modprobe.blacklist=r8169“ ist zumindest mal unsere Datenrate wieder so, wie es sein soll bei ca. 100MB/s. Es lag also doch am Realtek Treiber im neuen linbo Kernel.
Das Problem mit dem Abbruch beim Entpacken des BS in die Partition konnten wir eingrenzen.
Fehlermeldungen waren:
qemu-img: error while writing at byte …: Input/output error (teilweise auch mit reading Fehler)
in der Folge kam dann noch die Fehlermeldung:
cannot mount /dev/nvme0n1p3
Manchmal konnten wir noch eine weitere Fehlermeldung beobachten beim Zurückspielen des Images: „Timer timeout in wrong state: 6“
Wir vermuten, dass der nvme Treiber im neuen linbo Kernel die Verbindung zum NVMe Riegel verliert, weil nach dem Fehler die Partitionen nur nach einem Neustart wieder erreichbar sind.
Unser NVMe Riegel ist eine Crucial CT1000P3SSD8.
Ein Vergleichstest mit einer 2.5" SSD am SATA Port läuft problemlos durch. Hier wird ja das Kernel Modul „pcie“ verwendet und nicht „nvme“
Jetzt wäre es natürlich prima, wenn es einen alternativen NVMe Treiber geben würde, den man über Kernel Parameter adressieren könnte, wie bei der NIC auch.
VG
Steffen
Kleiner Nachtrag: Unter LMN7.1 mit Linbo 4.0.42 hat die Konstellation mit dem NVMe Riegel sehr gut funktioniert. Daraus schließe ich, dass das NVMe Kernel Modul ein anderes ist im neuen Linbo und damit bei uns das Problem verursacht.
Hi zusammen,
ein weitere Nachtrag: Heute habe ich mal partedMagic gestartet und mit dd das qcow2 Image von der Cache Partition in die für Windows vorgesehene Partition kopiert. Ziel war es herauszufinden, ob beim Kopieren von großen Datenmengen auch der Zustand eintritt, dass irgendwann Schreib-/Lesefehler auftreten wie beim Entpacken des qcow2 Images unter Linbo.
Ergebnis: mit dd wurden 22GB in 35 Sekunden fehlerfrei kopiert.
Also stellt sich immer noch die Frage, was im neuen Linbo Kernel mit dem NVME Modul anders läuft.
VG
Steffen
welche linbo Version habt ihr?
Welche Hardware ist den da drin? (Mainboard oder halt
Massenspeichercontroller: sollte mit lspci angezeigt werden).
@Jochen: ab welcher linbo Version gibt es die Probleme mit NVMe?
Ich hab 4.1.36 und habe auch vereinzelt NVMe Clients gesynct: erst
Gestern ein Yoga L13 … da ging es fix wie immer …
Ich tippe auf Probleme mit dem 6er Kernel und dem Massenspeichercontroller.
wir haben die Probleme seit dem Umstieg auf die 7.2 und aktuell Linbo 4.1.36.0.
Das sind Custom built PCs von exone, das Problem tritt dabei sowohl auf den AMD-CPU-PCs mit Gigabyte MB GA-A320M-S2H als auch auf den Intel-CPU-PCs mit Fujitsu-MB (genaues Modell steht nicht drauf, was für ein Käse) auf. Beiden gemein ist, dass eine Gigabyte NVMe-SSD drin ist, Modell GP-GSM2NE3256GNTD.
Hallo Holger,
die Linbo-Version ist die 4.1.36 nach dem Update von 7.1 auf 7.2, also wie bei Jochen auch.
Hardware Konfiguration: Dell Optiplex 3060 , Chipsatz Intel H370, NIC Realtek RTL8111HSD-CG.
Die Ausgabe von lspci -k ergibt Folgendes:
Mein Kollege hat sich ein wenig auf Github → Linuxmuster umgeschaut und die Kernel Module etc. unter die Lupe genommen. Ihm sind dabei ein paar Sachen aufgefallen:
Unter der Linbo Version 4.1.36 gibt es auf Github ein Kernel Update von 6.5.3 auf 6.5.7 seit ca. zwei Wochen. Tatsächlich ist darin ein Patch für den Realtek r8168 integriert. Außerdem wurden wohl auch im Kernel kleine Änderungen bezüglich nvme vorgenommen.
Wir haben das Geschwindigkeitsproblem bei uns gelöst, indem wir mit dem Kernel Parameter modprobe.blacklist=r8169 den neueren Treiber nicht mehr zur Auswahl stellen. ABER: Interessant ist, dass unter /lib/modules/6.5.3/kernel/drivers/net/ethernet das Modul r8168.ko nicht im Unterordner realtek zu finden ist, sondern eine Ebene höher. Das empfinden wir irgendwie als falsch. Somit könnte es ja sein, dass ohne Kernelparameter der „richtige“ r8168 gar nicht gefunden wird und dadurch auf den r8169 ausgewichen wird.
Um bei uns mit dem Massenspeicher Problem weiter zu kommen, habe ich mir von Github das Linbo Kernel Update 6.5.7 runter geladen und mit dem Buildscript von Thomas auf unserem Server ein Debian Package gebaut um Linbo nochmal mit nem neuen Kernel zu versehen. Das Update starte ich aber erst am Mittwoch, nachdem ich ein Snapshot von unserer LMN7.2 gemacht habe . Davor schaffe ich es erkältungsbedingt nicht in die Schule. Und wenn ich das mache, möchte ich das ja auch gleich an einem Windows Client testen. … Ich werde berichten
Viele Grüße
Steffen
Nein, das ist völlig egal, in welchem Verzeichnis der Treiber liegt. depmod erstellt in modules.dep eine Liste, in der alle Treiberdateien aufgelistet sind.
Hallo Thomas,
danke schon mal für die Antworten. Ich habe heute mal den linbo Kernel auf 6.5.7 aktualisiert. Leider sind die Probleme mit unserer NVME SSD dadurch nicht gelöst.
Ich habe aber ein paar Logs erzeugt: https://nextcloud.elektronikschule.de/index.php/s/XGyaeQ4KjofJzYb
Soll ich das an support@linuxmuster.net zusätzlich noch schicken, oder reicht das hier im Forum?
VG
Steffen
Zeilen wie Buffer I/O error on dev nvme0n1p3, logical block 11540921, lost async page write
in der Ausgabe von dmesg deuten lt. Suchmaschine auf defekte Sektoren hin.
Das sollte zuerst ausgeschlossen werden, bevor man Linbo die Schuld gibt.
Hallo Thomas,
Steffen hatte die Crucial NVME SSDs vorher mit linbo 4.0 ohne Probleme verwendet und er hat inzwischen, um Hardwarefehler aus zu schließen, die SSD getestet: „Heute habe ich mal partedMagic gestartet und mit dd das qcow2 Image von der Cache Partition in die für Windows vorgesehene Partition kopiert. Ziel war es herauszufinden, ob beim Kopieren von großen Datenmengen auch der Zustand eintritt, dass irgendwann Schreib-/Lesefehler auftreten wie beim Entpacken des qcow2 Images unter Linbo.
Ergebnis: mit dd wurden 22GB in 35 Sekunden fehlerfrei kopiert.“
Insofern können wir annehmen, dass es sich nicht um Hardwarefehler handelt.
@Steffen: vielen Dank, dass du dich da so rein hängst: die allerwenigsten stellen sich eine eigene Buildumgebung her um mal einen neueren kernel zu testen.
Ich betreibe, wenn ich Freitag wieder Zuhause bin, mal Nachforschungen, was es so zu nvme und kernel >=6.2 Problemen zu finden gibt, vielleicht auch in Verbindung mit Crucial.
Ich erinnere, aus den Anfängen der SSDs (also SATA SSDs), dass ein Freund für seine Schule 50 Kingston SSDs gekauft hatte: genau die gleichen wie ich hatte, weil er dann davon ausgehen konnte, dass sie funktionieren… hat natürlich nicht geklappt damals.
Er gab mir eine und ich habe sie untersucht: auf der SSD stand die Firmwareversion. Ich hab sie mit denen meiner SSDs verglichen: sie war neuer. Ich hab die ganz aktuelle Firmware drauf gespielt: dann gingen auch die wieder. Ich glaub nicht, dass es genau das bei dir ist
Hallo Holger,
vielen Dank für Eure Unterstützung. Wir sollten nur nicht zu viel Zeit investieren für ein doch möglicherweise sehr spezielles (Hardware)Problem. Auf Deine Aussage hin hat mein Kollege noch ein Tool von crucial gefunden um die Firmware zu aktualisieren und Fehler auslesen zu können. Das werden wir auch nochmal testen.
Die PCs werden maximal noch zwei oder drei Jahre laufen, und die neue Generation Rechner, die wir schon im Haus haben laufen ja wunderbar. Im Notfall probieren wir einen Downgrade von linbo aus. @thomas : damit möchte ich auf keinen Fall eine Schuldzuweisung Richtung linbo machen. Ich kann mir nämlich auch kein besseres System an der Schule vorstellen als Linuxmuster. Die NVMe SSDs machen ja ein thermal throttling und wir haben ein Update von 7.1 auf 7.2 gemacht als es draußen kalt wurde und die Räume wieder beheizt wurden. Wer weiß… Vielleicht weit hergeholt … aber ein witziger Gedanke
Die nächsten Tage gönne ich mir aber erstmal eine Auszeit. Ich melde mich ab dem 6.11. wieder.
VG
Steffen
Alles gut. Das neue Linbo-Release kann jetzt zusätzliche Firmware integrieren (siehe Lmn 7.2 testing - #504 von thomas). Im Falle deiner Hardware ist die Firmwaredatei i915/kbl_dmc_ver1_04.bin anzugeben. Evtl. hilfts ja.
Hallo Thomas,
gestern habe ich mit meinem Kollegen eine lange try-and-error-session gemacht. Ich versuche das mal nachvollziehbar zusammenzufassen.
Wir haben nochmal aktualisiert und sind nun bei Linbo Version 4.2.2
Der Eintrag für die Intel i915 dmc Firmware bringt den Erfolg, dass die Warnmeldung im Log verschwindet.
Das Problem an den Dell3060 Rechnern mit den von uns eingebauten Crucial NVMe 1TB Riegeln besteht aber weiterhin. Problembeschreibung: Das Entpacken des qcow2 Images vom Cache in die zugehörige Partition bricht mit einem Schreibfehler ab. Danach ist keinerlei Partition auf dem NVMe Riegel mehr verfügbar, selbst beim Versuch manuell zu mounten. Es hat den Anschein, dass der Riegel keine Verbindung mehr zum Controller hat. Erst nach einem Neustart des Rechners ist er wieder verfügbar.
Partitionierung, Formatierung, Cachepartition aktualisieren funktioniert einwandfrei. Auch ein von USB Stick installiertes Betriebssystem läuft einwandfrei.
Wir haben gestern zwei weitere NVMe Riegel von anderen Herstellern in den Dell 3060 Rechnern getestet. Diese haben einwandfrei funktioniert. Wir konnten den Fehler auch beim Kreuztausch der Riegel über drei Rechner hinweg reproduzieren. Der Fehler ist eindeutig mit dem Crucial NVMe „mitgewandert“.
Daher würden wir unseren Verdacht nochmal bekräftigen, (auch auf Basis von Holgers Erfahrung mit den SSDs von seinem Kollegen) dass hier eine seltsame Inkompatibilität zwischen dem Crucial NVMe Riegel und dem Intel Controller besteht, oder ein Timingproblem oder irgendwas in dieser Art. Auf ein Timingproblem bei den Schreib-Lese-Vorgängen könnte man schließen, weil wir auch einen Rechner hatten, bei dem drei mal das Zurückspielen des Images nicht funktioniert hatte und beim vierten mal auf einmal doch. @baumhof : Hi Holger. Wir haben das Crucial NVMe Tool ausprobiert um die Riegel zu überprüfen. Die neueste Firmware ist schon installiert und verschiedene Tests ergaben keine Fehler.
Was wir uns überhaupt nicht erklären können ist, warum wir mit dem Linbo in der Version 4.0.24 diese 140 Rechner ohne das oben beschriebene Problem nutzen konnten. Aber da stecke ich überhaupt nicht drin um nur ansatzweise eine Idee zu haben warum das so ist.
Um die 140 NMVe Riegel jetzt nicht in die Tonne zu schmeißen hätte ich noch zwei Optionen.
Downgrade des Linbo von 4.2.2 auf 4.0.24. Da bräuchte ich aber Deine Expertise und Dein Wissen ob das so einfach möglich ist, sinnvoll ist oder ob da Probleme mit Abhängigkeiten auftreten die nicht lösbar sind. Nachteil davon wäre halt auch, dass ich nach jedem Update wieder ein Downgrade von Linbo machen müsste. Das wäre aber verkraftbar.
Ein anderer Kollege von mir hat auf Github noch was Interessantes gefunden: Dell OptiPlex 3060 - Enable NVMe Gen 3 speeds (Enable PCIe 3.0) · GitHub
Das klingt verlockend und ich liebe hardwarenahe Programmierung. Da hat es natürlich einen großen Anreiz mal ein paar Bits auf Registerebene zu ändern
Wenn es sich also tatsächlich um ein Timingproblem zwischen NVMe Riegel und Controller handelt, wäre das ein Versuch, auch wenn der Rechner nachher gar nicht mehr geht
Nachteil hier: wenn das erfolgreich wäre, müsste ich an 140 Rechnern das BIOS verbiegen. Wenn man das als Überstunden anrechnet, brauche ich nächstes Jahr nicht mehr in die Schule
Was wir uns überhaupt nicht erklären können ist, warum wir mit dem Linbo
in der Version 4.0.24 diese 140 Rechner ohne das oben beschriebene
Problem nutzen konnten.
… da hab ich eine Theorie zu: der kernel in linbo 4.0 ist sehr viel älter.
Neuere Kernel reizen die Hardware besser aus: vorallem „neue“, also nvme
Geräte: und schon fallen ungereimtheiten in Firmwares oder
kompatibilitätsprobleme eher auf.
Der jetzige 6.9er Kernel ist halt „cutting Edge“.
Normalerweise wird sowas dann gelößt durch eine neue Firmware oder einen
neuen Kernel, der das Problem eben umschifft.
… habt ihr mal so eine nvme ssd in einen andern Rechner eingebaut?
Ihr könnt nicht zufällig die 140 SSDs in andere Rechner einbauen?
(könnte ja sein).
Ansonsten: vielelicht gibt es kernel Parameter, die bei nvme z.B.
Stromsparmechanismen im Kernel ausschalten: ich könnte mir vorstellen,
dass es sowas sein könnte.
Grüß Dich Holger,
Danke für Deine Antwort.
Wir haben gestern tatsächlich auch mal einen Kreuztausch der NVMe Riegel gemacht zwischen den alten Dell3060 mit den Crucial NVMe und unserer neusten Rechner Dell Optiplex 5000 mit xioxo (oder so ähnlich) NVMe. Die Crucials im Optiplex 5000 haben da auch nicht funktioniert, der Fehler war aber ein anderer. Das Entpacken des qcow2 Images ging am Anfang recht zügig bis ca. 25%. dann wurde er immer langsamer und blieb schlussendlich bei 99,06% stehen, bis ich das nach einer Stunde dann abgebrochen habe. Dafür war der andrere Riegel im Dell 3060 wahnsinnig schnell, also ich würde sagen knappe drei mal schneller als der Crucial, und natürlich ohne Fehler.
. Davor schaffe ich es erkältungsbedingt nicht in die Schule. Und wenn ich das mache, möchte ich das ja auch gleich an einem Windows Client testen. … Ich werde berichten
