System freezes


Photozone

Recommended Posts

2 minutes ago, MPC561 said:

Trotzdem weiter sporadisches einfrieren.

Hast du auch versucht im Safe Mode zu booten?

 

Poste auch mal deine Diagnostics bitte.

 

3 minutes ago, MPC561 said:

das einfrieren zusammen hängen kann ich aber noch nicht eindeutig sagen. 

Hast du schon mal versucht einen Monitor anzuschließen und die Konsolenausgabe zu Fotografieren wenn du einen Freeze hattest?

Link to comment

Auf dem Monitor kann ich nichts sehen. Die Graka schlatet den ja ab. Tastendruck am Server etc. wecken den auch nicht im Fehlerfall. Wie gesagt komplett eingefroren.

 

Disgnostic hab ich jetzt nicht verfügbar aber ein syslog vom Unraid Stick:

9 Uhr ist der Server aufgewacht. 9:15 Uhr sind die Platten in den Spindown. Hab den den ganzen tag nicht weiter gebraucht. 17:35 Uhr ein paar update Checks.

Dann ist er irgendwann zwischen 17:35 und 3:30 Uhr eingefroren (laut mienem Energielog irgendwann um 23 Uhr) und ich hab ihn gegen 3:40 Uhr neu gestartet als ich es entdeckt habe.

 

 

 

Oct  9 09:15:20 Hektor emhttpd: spinning down /dev/sdg
Oct  9 09:15:20 Hektor emhttpd: spinning down /dev/sdb
Oct  9 09:15:20 Hektor emhttpd: spinning down /dev/sdf
Oct  9 09:15:20 Hektor emhttpd: spinning down /dev/sdc
Oct  9 09:34:59 Hektor emhttpd: spinning down /dev/sdd
Oct  9 09:34:59 Hektor emhttpd: spinning down /dev/sde
Oct  9 17:35:01 Hektor Plugin Auto Update: Checking for available plugin updates
Oct  9 17:35:07 Hektor Plugin Auto Update: Checking for language updates
Oct  9 17:35:07 Hektor Plugin Auto Update: Community Applications Plugin Auto Update finished
Oct 10 03:41:33 Hektor kernel: Linux version 5.10.28-Unraid (root@Develop) (gcc (GCC) 9.3.0, GNU ld version 2.33.1-slack15) #1 SMP Wed Apr 7 08:23:18 PDT 2021
Oct 10 03:41:33 Hektor kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot
Oct 10 03:41:33 Hektor kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Oct 10 03:41:33 Hektor kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
 

 

Gruss,

Joerg

 

PS: Safe Mode habe ich nicht versucht. Ich war mehr auf die NVME fokusiert. Die hatte öfter mal ein sporadisches überhitzen (ohne Grund sprich ohne Aktion auf der Platte, die P5 scheint aber in vielen tests ein "Heißsporn" zu sein) 

Edited by MPC561
Link to comment
Auf dem Monitor kann ich nichts sehen. Die Graka schlatet den ja ab. Tastendruck am Server etc. wecken den auch nicht im Fehlerfall. Wie gesagt komplett eingefroren.
 
Disgnostic hab ich jetzt nicht verfügbar aber ein syslog vom Unraid Stick:
9 Uhr ist der Server aufgewacht. 9:15 Uhr sind die Platten in den Spindown. Hab den den ganzen tag nicht weiter gebraucht. 17:35 Uhr ein paar update Checks.
Dann ist er irgendwann zwischen 17:35 und 3:30 Uhr eingefroren (laut mienem Energielog irgendwann um 23 Uhr) und ich hab ihn gegen 3:40 Uhr neu gestartet als ich es entdeckt habe.
 
 
 
Oct  9 09:15:20 Hektor emhttpd: spinning down /dev/sdg
Oct  9 09:15:20 Hektor emhttpd: spinning down /dev/sdb
Oct  9 09:15:20 Hektor emhttpd: spinning down /dev/sdf
Oct  9 09:15:20 Hektor emhttpd: spinning down /dev/sdc
Oct  9 09:34:59 Hektor emhttpd: spinning down /dev/sdd
Oct  9 09:34:59 Hektor emhttpd: spinning down /dev/sde
Oct  9 17:35:01 Hektor Plugin Auto Update: Checking for available plugin updates
Oct  9 17:35:07 Hektor Plugin Auto Update: Checking for language updates
Oct  9 17:35:07 Hektor Plugin Auto Update: Community Applications Plugin Auto Update finished
Oct 10 03:41:33 Hektor kernel: Linux version 5.10.28-Unraid (root@Develop) (gcc (GCC) 9.3.0, GNU ld version 2.33.1-slack15) #1 SMP Wed Apr 7 08:23:18 PDT 2021
Oct 10 03:41:33 Hektor kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot
Oct 10 03:41:33 Hektor kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Oct 10 03:41:33 Hektor kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
 
 
Gruss,
Joerg
Mir würd es eher generell um die Diagnostics gehen, hat nichts mit dem syslog zu tuhen, damit man einfach sieht welche hardware usw du verbaut hast, ich hab mit meinem 10600 auf einem ASUS Z490-E Gaming keine probleme... Deswegen frag ich.

Sent from my C64

Link to comment

Ok hier anbei:

 

hektor-diagnostics-20211020-2151.zip

 

Einige Platten haben paar Problemchen. Normal nichts zu kritisches (Hab alles auf einer DS1817 gebackuped und wirklich wichtige Daten auf einer weiteren DS414 an einem anderen Wohnsitz). Das ist hier mein Arbeitssystem das Tagsüber immer läuft. Die DS schalte ich nur für Backups an (Die braucht im Dauerbetrieb zu viel Strom). Da sind die "guten" Platten drin.

 

Gruss,

Joerg

 

PS: Das Syslog basiert schon auf der neuen NVME

Edited by MPC561
Link to comment
22 hours ago, MPC561 said:

Ich habe vermutet das es wie gesagt evtl. an der Cache NVME liegt (Crucial P5 1TB). Diese habe ich vor 4 Tagen durch eine Samsung 970 EVO ersetzt. Seitdem ist jetzt erstmal Ruhe und ich beobachte weiter (kann auch sein es knallt in 4 Tagen wieder...). Ob das Problem mit der Cache NVME und das einfrieren zusammen hängen kann ich aber noch nicht eindeutig sagen. 

Das wäre ja echt ein Ding. Update erwünscht!

 

Hattest du statt Deaktivierung von ASPM auch das probiert?

https://forums.unraid.net/topic/96589-solved-nvme-as-ud-corsair-mp600-keeps-disappearing/?tab=comments#comment-889971

 

 

Link to comment

Feedback gerne, kann aber noch 2-3 Wochen dauern. Erst dann wenn kein erneutes einfrieren oder auswerfen der NVME Auftritt klassifiziere ich den Test als erfolgreich. 

 

Ich hatte das aus deinem Link nicht gelesen, wohl aber das einige NVME Probleme mit den Powerstates machen. Deswegen dann auch die Idee die zu tauschen gegen etwas was viele von euch hier im Einsatz haben.


Ich hab eigentlich viel mehr getestet. Mein erstes Board war ein GA B460m DS3H.

das lief lange mit normaler SSD aber ohne ASPM aktiviert (ich hab mich in die Energiesparoptionen erst durch deine Beiträge eingelesen) ohne Probleme allerdings kam das nicht unter C3 wegen dem Verbauten Realtek Netzwerkchip. Dann war die P5 im Angebot und ich habe das genutzt um einen SATA Port frei zu bekommen. Zeitgleich habe ich das Board mit einem B460m Aorus Pro ersetzt. Das wurde im Hardwareluxx Thread sehr gelobt bzgl. Leistungsaufnahme.
 

Dann ging’s los mit dem auswerfen der NVME wenn ASPM DMI und PCH aktiviert waren. Nun war ich mir nicht sicher. Hat das Board eine Macke oder die NVME. Austauschen konnte ich das Board nicht, keine mehr verfügbar…

War sogar mit Sassicaia, der das board im Hardwareluxx Thread ausgemessen hatte in Kontakt. Der riet mir die C States mal auf C8 zu begrenzen. Erfolglos.

RAM und Prozessor ausgetauscht. Erfolglos. PicoPSU 160W gegen Seasonic Focus GX 550 Gold ausgetauscht. Erfolglos.

 

Also W480m bestellt und erstmal glücklich bis die freezes kamen. Und da dann wieder die Beobachtung des auswerfen der NVME beim freeze bzw. einmal sogar Docker IO Fehler im laufenden Betrieb. Alle Tests der NVME waren erfolgreich (BIOS, Dateisystem Check etc.)

 

Ob jetzt nur meine eine P5 eine Macke hat oder ob es ein generelles Problem mit den Powerstates gibt kann ich nicht sagen.

 

Ich habe die P5 jetzt erstmal in den Hackintosh meiner Frau verbannt. Da läuft die seit dem Umbau ohne Probleme. Und mein Server läuft  Problemlos seit 5 Tagen.

 

 

 

Gruss,

Joerg

 

 

Edited by MPC561
Link to comment

Vorhin ist mein Server wieder eingefroren. Man siehts schön wie er um 11.03 Uhr auf 51W Verbrauch hochgeht und einfach da bleibt. Wieder keine Reaktion am Monitor auf Tastendruck am Keyboard.  Ping keine Antwort.

 

Log auf Flash sagt nix aus:

 

9 Uhr ist der Bursche aufgewacht. Platten sind zeitnah in den Spindown gegangen.

11 Uhr ist er eigefroren (siehe das andere Bild)

13.40 Uhr hab ich gesehen das er eingefroren ist und rebootet.

 

Oct 22 09:00:21 Hektor kernel: PM: suspend exit
Oct 22 09:00:21 Hektor emhttpd: read SMART /dev/sdg
Oct 22 09:00:21 Hektor emhttpd: read SMART /dev/sdd
Oct 22 09:00:21 Hektor emhttpd: read SMART /dev/sde
Oct 22 09:00:21 Hektor emhttpd: read SMART /dev/sdb
Oct 22 09:00:21 Hektor emhttpd: read SMART /dev/sdf
Oct 22 09:00:21 Hektor emhttpd: read SMART /dev/sdc
Oct 22 09:00:41 Hektor crond[1849]: time disparity of 521 minutes detected
Oct 22 09:15:22 Hektor emhttpd: spinning down /dev/sdg
Oct 22 09:15:22 Hektor emhttpd: spinning down /dev/sdb
Oct 22 09:15:22 Hektor emhttpd: spinning down /dev/sdc
Oct 22 09:24:57 Hektor emhttpd: spinning down /dev/sde
Oct 22 09:25:26 Hektor emhttpd: spinning down /dev/sdd
Oct 22 09:25:26 Hektor emhttpd: spinning down /dev/sdf
Oct 22 13:42:09 Hektor webGUI: Successful login user root from 192.168.0.40
Oct 22 13:42:14 Hektor root: getConvertedTemplates
Oct 22 13:42:15 Hektor root: getConvertedTemplates
Oct 22 13:44:42 Hektor webGUI: Successful login user root from 192.168.0.125

 

 

Cache NVME war nicht ausgeworfen. Ich setze jetzt mal die Bootoption pcie_aspm=off, wobei das eigentlich glaube ich unsinn ist da die freezes sicher von einem anderen gerät kommen. Ich denke mal von einer Festplatte oder irgendwas anderem das auch über den DMI geht und ein Problem mit den Powerstates hat. 

 

 

Bildschirmfoto 2021-10-23 um 14.10.13.png

Edited by MPC561
Link to comment
On 10/20/2021 at 9:20 PM, MPC561 said:

 

Aber @Photozone

Versuche mal die ASPM Optionen im Bios zu deaktivieren und zu schauen ob Du immer noch freezes hast.

 

 

Hallo Jörg,

 

danke für deine Anregung!

 

Derzeit läuft der Server seit über 12 Tagen stabil --- das hatte ich schon seit - ich weiß gar nicht wie lange das schon her ist, nicht mehr!

 

Den Cache Pool mit beiden Laufwerken habe ich wieder in Betrieb (hatt weiter oben was dazu geschrieben). Cache NVMe sind eine Samsung 970 Pro und eine WD Black.

 

Jedoch habe ich die Intel und eine Samsung Sata SSD nicht mehr in den Unassigned Devices eingehangen - ev. gibt es allgemeine Firmware Inkompatibilitäten zu SSD´s in gewissen Konfigurationen.

 

Ich werde jedenfalls weiter berichten, hoffe aber dass es lange nichts negatives zu berichten gibt.

 

Gruß Mike

  • Like 1
Link to comment
13 hours ago, mgutt said:

Die ist schuld. WD Black und Crucial sind instabil in Linux. Daher muss man ASPM deaktivieren. Ich habe deswegen auch wieder Samsung gekauft.

 

Wobei ich aber dazu sagen muss dass ich diese Probleme alle schon lange vor der WD Black hatte und sie mit ihr nicht schlimmer geworden sind. 

Spricht aber nicht dagegen, beim nächsten Absturz ASPM mal zu deaktivieren. Aber auf die WD alleine könnte ich es nicht schieben.

 

Gruß Mike

Link to comment
39 minutes ago, mgutt said:

 

Zitat aus dem Link:

Settings > Docker

This is the one I truly believe may have fixed the issue. One of the issues I've read is that the docker service assigns an ip address to containers that are in use by something else on your network.... or something along those lines. So you should be setting a range that your router doesn't use and have your docker service run in that range. To do this set enable docker to no and apply change. Once your containers are turned off make sure you're in advanced view. You'll see check boxes for custom network. for each of those enabled you'll want to set a DHCP range. So lets say on your router you isolate 192.168.1.128 to 192.168.1.159 which is br0 you can write the CIDR as 192.168.1.128/27 (you can do CIDR transitions at this site

 

Hi,

 

also sofern ich das verstehe, könnten Dockercontainer die sich irgendwie mit dem Router "nicht einigen können" oder eine IP Doppelbelegung provozieren, den Absturz verursachen? Das würde dann so einiges erklären, weil ich nach dem Dockerumstellen derweil nur die für mich wirklich wichtigen installiert habe und diese scheinen wohl problemlos zu funktionieren, da ich so lange schon lange nicht mehr online war.

 

Die anderen Lösungsansätze treffen nämlich bei mir nicht zu. Weder habe ich den Switch, ich fahre komplett auf Unifi und auch die FlowControl ist bei mir aus.

 

Habe ich das so richtig verstanden?

 

Auf alle fälle vielen Dank für den Link!!!!

 

Gruß Mike

 

 

Link to comment
4 hours ago, Photozone said:

also sofern ich das verstehe, könnten Dockercontainer die sich irgendwie mit dem Router "nicht einigen können" oder eine IP Doppelbelegung provozieren, den Absturz verursachen?

Ja, dies ist ein Problem, was wohl auch zu Abstürzen führen kann, wenn VMs und Container beide br0 nutzen. Das soll aber in der nächsten unRAID Version 6.10 nicht mehr auftreten, wenn man bei den Docker Einstellungen von macvlan auf ipvlan ändert.

 

 

Link to comment
  • 3 weeks later...
On 10/27/2021 at 1:14 PM, Photozone said:

Derzeit läuft der Server seit über 12 Tagen stabil --- das hatte ich schon seit - ich weiß gar nicht wie lange das schon her ist, nicht mehr!

 

Da @MPC561 mit dem W480M das selbe Problem hat wie du, würde ich noch eine andere Methode vorschlagen sofern ihr darauf Lust habt.

 

Und zwar würde ich das System mit Ubuntu starten und nach ca 2 Minuten führt man den Befehl aus:

lspci -vv | awk '/ASPM/{print $0}' RS= | grep --color -P '(^[a-z0-9:.]+|ASPM )'

 

Das Ergebnis abfotografieren. Dann Unraid mit ASPM starten und den selben Befehl ausführen. Fällt beim Vergleichen etwas auf?

 

Danach erst mal wieder ASPM deaktivieren. Danach mit setpci bei einem Gerät nach dem anderen ASPM aktivieren, bis man weiß welches den Crash verursacht.

 

 

Link to comment

Ersteres nicht.

 

Das zweite hatte ich vor längerem mal untersucht. Ich bin nur nicht sicher ob das mit dem W480 oder dem GA B460m Aorus Pro. Mit dem Aorus Pro hatte ich die Probleme ja auch schon. War irgendwas mit Clocksource und das war ok. Die freezes waren trotzdem da.

 

Zweites kann ich mal testen. Testen ist halt schwer wenn die Freezes sehr sporadisch auftreten.

Wobei ersteres vermutlich nur Auswirkungen auf die NVME hat?

 

Damit mein System Stabil bleibt muss ich:

 - ASPM DMI und PCIe im Bios deaktivieren oder

 - ASPM DMI off im Bios und pcie_aspm=off bei den Kernelparametern ändern.

 

Aber jetzt erstmal schlafen. Danke nochmal!

Edited by MPC561
Link to comment
  • 2 months later...

Ich hole den alten Thread nochmal hervor weil ich glaube die Quelle meiner System Freezes gefunden zu haben, da der Server jetzt das seit 2 Wochen Stabil gelaufen ist.

 

Es scheint schlicht und ergreifend der iGPU Treiber i915 zu sein der die Probleme macht. 

Ich habe im Bios jetzt alle ASPM Optionen und Package States bis 10 aktiv aber in Unraid lade ich den treiber nicht mehr.

Powertop sagt das ich meist im Package States C7 und C8 hänge, vermutlich weil durch das entfernen der Treiber die iGPU nicht mehr in den Sleep geht.

 

Aber auch damit bin ich glücklich, da mein Server damit auf ca. 17W im HDD Spindown ist.

 

Gruss,

Joerg

Link to comment
18 hours ago, MPC561 said:

Es scheint schlicht und ergreifend der iGPU Treiber i915 zu sein

 

50 minutes ago, mgutt said:

@ich777 evtl eine wichtige Info für dich

Danke für den Report aber das wäre mir neu das der i915 Treiber mit 10th gen Probleme hat...

 

Hast du einen Monitor oder dergleichen dran am Server?

Für was hast du die iGPU benutzt?

 

EDIT: bitte pass auch noch deine VFIO Konfiguration an, dein Server vereucht beim booten noch das Gerät 2 zu binden was eigentlich deine iGPU wäre, das schlägt aber fehl weil die GeräteID nicht passt und der i915 Treiber dort schon geladen ist.

Link to comment

@ich777

Ein alter 2k Dell Monitor ist dran, aber abgeschaltet.

Eigentlich habe ich die iGPU nur für deinen Jellyfin Container benutzt.

 

Danke das du mich auf die vfio-pci.cfg hinweist. War mir nicht bewusst das ich dort ein manuelles binden der UHD vorgenommen habe. Interessanterweise zeigt das Unraid bei den Werkzeugen und den Systemgeräten gar nicht an.

 

Ok, sieht man wenn man auf Log anschauen klickt.

 

 

1151016169_Bildschirmfoto2022-02-11um22_48_29.thumb.png.224fec5c9354863d5164dfa0625b811a.png

 

Muss wohl ein Relikt sein als ich versuchte die iGPU für VM freizuschneiden, oder da die Adresse ja gar nicht existiert noch vom alten J4105 Atom Board. Da hatte ich den Stick zuerst laufen.

 

Ja, scheint vom alten Board zu sein. 

in der vfio-pci.cfg steht: 1987:5012

 

Im System hier beim W480 Board:1803678109_Bildschirmfoto2022-02-11um23_06_06.png.ff1b7759e8d13a6ce44c35eeb2c05788.png

 

Aber jetzt bin ich total verwirrt. Beim Atom Board hat die UHD die Adresse: 

root@BamBam:~# lspci -n -s 00:02.0

00:02.0 0300: 8086:3185 (rev 03)

 

Die RX580 die ich mal drin hatte kann es auch nicht sein, die hat eine ganz andere Busadresse. Ach ich glaub jetzt weiss Ichs. Der Server lief zwischenzeitlich zu Testzwecken auf 2 anderen Boards B460 DS3H und Z390 M Gaming. Die Adresse wird wohl von einem der beiden sein.

 

 

 

Ich kann mich nur auf Teufel komm raus nicht dran erinnern das durch Manuelle Änderung der vfio-pci.cfg gemacht zu haben.

 

Ich werde mal noch eine Woche den Server laufen lassen (um sicherzustellen das er wirklich stabil ist) und dann die vfio-pci.cfg bereinigen.

Ich dachte erst dann nochmal die iGPU Treiber einbinden und sehen ob es wieder freezes gibt. Aber das macht keinen Sinn. Ich hatte ja nur versucht ein device zu binden das es gar nicht gibt. Oder?

 

Gruss,

Joerg

 

Edited by MPC561
Link to comment
9 hours ago, MPC561 said:

Ein alter 2k Dell Monitor ist dran, aber abgeschaltet.

Probier mal den an zu schalten ob das Problem dann noch immer auftritt, manche Monitore werden erst erkannt wenn die an geschaltet sind.

 

9 hours ago, MPC561 said:

Danke das du mich auf die vfio-pci.cfg hinweist. War mir nicht bewusst das ich dort ein manuelles binden der UHD vorgenommen habe. Interessanterweise zeigt das Unraid bei den Werkzeugen und den Systemgeräten gar nicht an.

Hast du das evtl. mal früher gemacht mit dem VFIO plugin?

 

9 hours ago, MPC561 said:

Aber jetzt bin ich total verwirrt. Beim Atom Board hat die UHD die Adresse: 

1987:5012 dürfte die Geräte ID eines Phison controllers sein, sprich NVME

 

9 hours ago, MPC561 said:

Ich dachte erst dann nochmal die iGPU Treiber einbinden und sehen ob es wieder freezes gibt. Aber das macht keinen Sinn. Ich hatte ja nur versucht ein device zu binden das es gar nicht gibt. Oder?

Ja/Jein, da du versucht hast auch die Adresse zu binden ist es schon möglich das dir dort irgendwas einen Schaden rein geschmissen hat, ich würd die vfio-pci.cfg mal bereinigen und einen neustart machen.

 

Kann auch sein das im BIOS für die iGPU was nicht "richtig" eingestellt ist, der i915 Treiber auf Linux wird immer komplizierter und verursacht bei Alder Lake mal richtig probleme.

 

Beim transcodieren selbst hattest du aber noch nie Probleme oder? Es wäre aber trotzdem interessant welche Meldung er am Bildschirm ausgibt wenn er crasht.

 

Bitte berichte mal, nach einer Woche oder so ob das System noch stabil ist.

Mich würde auch interessieren wie es aussieht wenn der i915 Treiber geladen ist, kannst ruhig wieder mit dem Intel-GPU-TOP plugin machen (spätestens bei unRAID 6.10.0 werden die Treiber sowieso wieder automatisch geladen).

Hatte auf 10th gen noch nie das Problem das der Server crashed, hab selber auch eine 10th gen CPU verbaut:

 

Link to comment
3 hours ago, ich777 said:

Beim transcodieren selbst hattest du aber noch nie Probleme oder? Es wäre aber trotzdem interessant welche Meldung er am Bildschirm ausgibt wenn er crasht.

 

Beim transcodieren noch nicht. Nutze ich aber eher weniger. Deswegen tat es auch nicht weh das i915 zu deaktivieren.

Zum Thema Bildschirm. Er gibt beim einfrieren gar nichts aus. Es steht in keinem Log was. Er friert einfach ein. Anschalten ok, aber der verdammte als Dell Monitor zieht Strom, jenseits von gut und böse. Selbst im Standby.

 

3 hours ago, ich777 said:

1987:5012 dürfte die Geräte ID eines Phison controllers sein, sprich NVME

 

Richtig 02:00.00 vs 00:02.0. Kann er aber nicht binden weil die von einem anderen Mobo war aber egal. Geht jedenfalls nicht.

 

3 hours ago, ich777 said:

Hast du das evtl. mal früher gemacht mit dem VFIO plugin?

Nein. Ich habe ausser der einen Modifikation an der vfio-pci.cfg alles via Kernel/Bootparamter gemacht. Alles im Kontext GPU Passthrough und der NVME Eintrag war auch für eine VM um der eine OSX Installation auf einer NVME zur Verfügung zu stellen (langsam kommt die Erinnerung wieder). Ich habe die Idee aufgegeben (obwohl alles funktionierte wie gedacht) weil der Stromverbrauch mit Grafikkarte einfach zu hoch war.

 

 

Nun gut. Dann räume ich mal auf und hole mir den i915 Treiber wieder ins System. Und teste mal 2 Wochen. (1 Woche wird nicht reichen mein System hat auch schonmal 10 Tage bis zum Freeze durchgehalten).

 

Und dann melde ich mich nochmal.

 

Gruss

Edited by MPC561
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.