Hi zusammen,

ich habe heute von 7.0.1 auf 7.1.4 geupdatet und bekam im Log vorhin diese Fehlermeldung:

Jun 20 12:10:30 Tower kernel: usb 1-10: device descriptor read/64, error -110

Zum besseren Verständnis habe ich noch die Diagnosedaten mit angehangen, da eine Zeile alleine in der Regel nicht aussagekräftig genug ist.

Als USB Stick verwende ich einen JetFlash Transcend 32GB.

Was genau bedeutet die Fehlermeldung bei Unraid und wie kann ich prüfen, ob der Stick ggfs. defekt ist?

Danke Euch.

Gruß

Infosucher

PS: Mir fällt gerade auf, dass sich auf dem Stick folgende Dateien befinden: FSCK0000.REC und weiter...

Das deutet wohl auf einen Dateisystemfehler auf dem Stick hin. Noch läuft alles ganz normal. Sollte ich den Stick lieber tauschen? Gibt es Unraid intern eine Möglichkeit den Stick zu prüfen und ggfs. Fehler zu beheben, sofern kein Hardwaredefekt vorliegt?

tower-diagnostics-20250620-2250.zip

Edited June 20, 20251 yr by Infosucher

6 hours ago, Infosucher said:

Als USB Stick verwende ich einen JetFlash Transcend 32GB.

Transcend hat extrem viele sehr unterschiedliche Jetflash Typen im Angebot. Diese Aussage sagt somit leider nicht viel.

6 hours ago, Infosucher said:

wie kann ich prüfen, ob der Stick ggfs. defekt ist?

Lokales Backup des USB Sticks machen (unraid bietet dafür eine Funktion),

Unraid herunter fahren

USB Stick löschen, einmal komplett mit nachvollziehbaren Daten voll schreiben und dann all diese Daten lesen und prüfen ob diese korrekt sind.

- Wenn alles okay ist, Stick wieder löschen und das Flashbackup zurückspielen und dann urnaid damit wieder starten.

- Wenn nicht alles okay ist: das deutet dann sehr stark auf einen Schreibfehler hin, was entweder ein USB-, Dateisystemfehler oder ein USB-Stick-defekt sein kann. In dem Fall sollte man sich noch genauer mit dem Stick und dem schreibenden PC beschäftigen.

Die Zeitschrift ct (Heise Verlag) hat für solche Tests, schon vor Jahren, eine sehr praktische Windows Software "h2testw.exe" raus gebracht, welche einen Datenträger mit nachvollziehbarem Kauderwelsch voll schreibt und diesen im Nachgang dann auch auf Korrektheit prüft.

6 hours ago, Infosucher said:

PS: Mir fällt gerade auf, dass sich auf dem Stick folgende Dateien befinden: FSCK0000.REC und weiter...

Solche Dateien deuten darauf hin, daß da (zumindest im Dateisystem) etwa schief gegangen ist.

Auch können solche Dateien ein Backup stark vergrößern.

6 hours ago, Infosucher said:

Sollte ich den Stick lieber tauschen?

Ein Dateisysetmfehler bedeutet nicht, daß der Stick selber physikalisch defekt ist.

Es bedeutet, daß zumindest logisch im Dateisystem etwas schief gegangen ist (Stromausfall beim Schreiben, USB Verbindungsabbruch beim Schreiben.... irgendetwas in de Art kann auch Schuld tragen).

6 hours ago, Infosucher said:

Gibt es Unraid intern eine Möglichkeit den Stick zu prüfen und ggfs. Fehler zu beheben, sofern kein Hardwaredefekt vorliegt?

Da der Stick notwendig ist um unraid zu starten (und der auch sporadisch auf Vorhandensein der Lizenz gelesen wird), kann unraid schlecht den Stick selber löschen, beschreiben. testen und dann wieder löschen und Backup zurückspielen.

Einen entspechenden Test mußt Du außerhalb von unraid machen.

Also ich setze auch einen "Transcent JetFlash 32Gb" (USB3 Stick, aber in USB2 Port) ein. Seit 7.0 hatte ich nun schon mehrfach Probleme. Meist nach Updates weigert sich UNRAID neu zu booten, einmal kam sogar die böse Seite in der GUI : "Kommunikation zum Stick unterbrochen, ich konnte die Lizenz nicht prüfen". Nach einem Reboot (meist eben mit anschließendem Parity Check) gings dann wieder.

Ich hatte das anfangs damit abgetan, dass ich eventuell bei Baumassnahmen das Rack (auf Rollen) zu heftig verschoben hatte und dadurch der Stick einen Wackelkontakt im Port bekam. Hab dann den Stick oben aufs Gehäuse geklebt und mit einem 1m USB Kabel an ein hinteres Port angeschlossen. So steht er nicht mehr vor.

Aber die letzten beiden Male passierte es trotzdem und eindeutig "ohne Fremdeinwirkung"...

Gibt mir auch ein mulmiges Gefühl :-(

(PS: mehrfache Überprüfungen des Sticks a la @DataCollector ergaben gar nichts, der Stick ist völlig ok. Scheint mir mal wieder (siehe USV Probleme) der USB Treiber von UNRAID/Linux zu sein...)

Edited June 21, 20251 yr by MAM59

8 minutes ago, MAM59 said:

Also ich setze auch einen "Transcent JetFlash 32Gb" (USB3 Stick, aber in USB2 Port) ein...

Klinght mir nach "USB Kontroller des Mainboard kappt die Verbindung/Stromversorgung, bevor der letzte Schreibvorgang abgeschlossen ist.

Somit verliert der Stick die Möglichkeit die letzten zu schreibenden Bits eben zu schreiben, weil das Mainboard neu bootet und in dem (noch nicht abgeschlossenen) Vorgang des Schreibens auf den Stick unterbricht, indem es den USB Kontroller eben zu früh abschaltet/initialisiert.

USB 3.0 Sticks (5GBit/s) sind eigentlich auf bis zu 5V mit 0,9A ausgelegt (basierend auf der USB Spec sind bis herab zu fast 4V zulässig). Mit dieser Leistung (Spannun * Strom) erreichen die die hohen Schreib-/Lesegeschwindigkeiten.

Ein USB 2.0 Port ist aber nur für 0,5A vorgesehen. Deshalb beherrschen die Sticks auch einen Modus, welcher dann dort etwas langsamer arbeitet, weil einerseits das die elektrische Leistung reduziert und andererseits sowieso ein USB 2.0 Port eben weniger Daten liefern kann. Doch der USB Stick braucht dann intern auch mehr Zeit für die Verarbeitung (weil er bei normal hoher Geschwindigkeit ja mehr elektr. Leistung haben müsste).

Der Kontroller im USB Stick meldet aber dem PC, daß er schon fertig ist, obwohl er intern die Daten noch in die Zellen quetscht.

Sollte der PC dann in Reboot gehen ist es Glückssache ob man lange genug gewartet hat vor dem Reboot und alles sicher ind en Zellen angekommen ist oder ob der PC den Kontroller resettet und somit auch der USB Stick dieses "Alles zurück auf Anfang" Signal mitbekommt und dem Befehl folgt.

Ja, das kann man in einem USB Stick entweder mit Puffern und geschickter Firmware abfangen, doch das kostet Geld.

Und da sind wir dann eben wieder bei "ja, es gibt sehr viele Jetflash Sticks der Firma Transcend. Die Kosten und Qualität sind dabei von sehr preiswert bis doch recht hochwertig weit gestreut.

Meine Jetflask 600, 780, 790 930c haben mir noch keine solche Probleme bereitet. Einige 760 und 350 haben mich hingegen vor etlichen Jahren stark enttäuscht und sind mittlerweise bei mir fast komplett entsorgt.

2 minutes ago, DataCollector said:

Sollte der PC dann in Reboot gehen ist es Glückssache ob man lange genug gewartet hat vor dem Reboot und alles sicher

Ja, aber Du hast mich "Misstverstanden" :-) (bzw ich habe Details ausgelassen)

Ich komme gar nicht mehr zum Reboot. Nach dem Einspielen des Updates per GUI drückt man auf "fertig". Normalerweise kommt dann die normale GUI (und blendet oben "du musst aber rebooten!") ein.

Soweit kommt man nicht, der Bildschirm bleibt weiss und der Pausenfüller dreht endlos seine Runden.

Auch SSH usw gehen dann nicht mehr.

Laufende SSH Sitzungen gibt es zwar noch, aber egal, welchen Befehl man aufruft, die Kiste hängt.

Nur die Resettaste belebt die Kiste dann wieder.

Es ist also garantiert kein Stromproblem.

(Nach dem Reset geht es brav weiter. Das Update ist erfolgreich geschrieben worden, keine Dateien sind beschädigt usw....)

Hab nun schon eine KVM Platine eingebaut, damit ich nicht immer runterrennen muss und die Power und Resettaste remote drücken kann...

Edited June 21, 20251 yr by MAM59

1 minute ago, MAM59 said:

Ja, aber Du hast mit "Misstverstanden" :-)

Ich komme gar nicht mehr zum Reboot. Nach dem Einspielen des Updates per GUI drückt man auf "fertig". Normalerweise kommt dann die normale GUI (und blendet oben "du musst aber rebooten!") ein.

Soweit kommt man nicht, der Bildschirm bleibt weiss und der Pausenfüller dreht endlos seine Runden.

Da Du "Fertig" schreibst vermute ich Deutsches Sprachpaket.

Das ist des öfteren schon bei Problemen mit der GUI Anzeige benannt worden.

1 minute ago, DataCollector said:

Das ist des öfteren schon bei Problemen mit der GUI Anzeige benannt worden.

Die hängende GUI ist doch nur ein Symptom. Die Ursache liegt irgendwo in einer Blockade des USB Sticks.

Wenn schon auch SSH Sessions nicht mehr gehen, ist das wohl ein Problem des Kernels und/oder des Dateisystems.

Edited June 21, 20251 yr by MAM59

40 minutes ago, MAM59 said:

Die hängende GUI ist doch nur ein Symptom. Die Ursache liegt irgendwo in einer Blockade des USB Sticks.

Wenn schon auch SSH Sessions nicht mehr gehen, ist das wohl ein Problem des Kernels und/oder des Dateisystems.

Ich verstehe nicht, warum ein ssh Zugriff auf das (im Ram laufende) unraidsystem von einem parallelen Schreibprozess auf einem USB Stick beeinflusst werden sollte und selbst wenn ein USb Stick langsam schreibt dürfte das (im Ram laufende) OS nicht vom Stick, sondern vom USB Kontroller des PC blockiert werden. DER USB STick ist eine eigenständig arbeitende Einheit, die vom PC nur Strom und Befehle bekommt. die Befehle führt der Stick in seinem eigenen Kontroller aus. Dass ein PC USB Kontroller dann eien Blockade auslöst ist nicht Sache des Sticks, sondern des nicht multitakstingfähigen PC Kontrollers (bzw. seiner Firmware oder OS Treiber).

Unraid bootet vom USB Stick und schaut beim starten von Docker und Vm auf dem USB Stick nach der anzuwendenden Konfiguration.

Auch wird ab und zu auf dem USB Stiuck nachgesehen ob die Lizenz da ist.

Wenn man es einstellt wird auch das Syslog auf dem USB Stick platziert.

Aber wenn man ein laufendes System (wie unraid) hat und den Update OS Button drückt wird das OS dort neu aufgespielt/ausgetauscht.

Warum sollte die Aktivität auf dem USB Stick das in der beschriebenen Weise im RAM laufende OS beeinflussen?

Es ist ja nicht so, daß damit auch das gerade laufende OS im RAM ausgetauscht wird oder der Transfer von 300-800MB OS Update sooooo extrem viel ist, daß der vorhandene PC Ram (vermutlich mindestens 4GB DDR Ram) maximal ausgelastet ist. Selbst das entpacken der gezippten Version sollte den PC nicht so stark auslasten, daß der ganze PC alles Andere stoppt.

Wenn also ein OS Update (ohne danach zu booten) die Reaktion(en), des ansonsten sauber laufenden (und nicht hoffnungslos untermotorisierten) Systemes im RAM beeinflußt, ist es mir unverständlich, warum dies am USB Stick liegen soll.

Aber ich kenne mich mit Linux leider auch nicht so genau aus. Sollte Linux evtl. doch nicht so multitaskingfähig sein, daß es einerseits einen USB Stick bespielen und andererseits laufende Prozesse, die nichts mit USB zu tun haben, nicht sauber weiter laufen lassen kann?

8 minutes ago, DataCollector said:

Ich verstehe nicht, warum ein ssh Zugriff auf das (im Ram laufende) unraidsystem von einem parallelen Schreibprozess auf einem USB Stick beeinflusst werden sollte und selbst wenn ein USb Stick langsam schreibt dürfte das (im Ram laufende) OS nicht vom Stick

Der Kernel STEHT, ist BLOCKIERT. Da geht nix mehr!

9 minutes ago, DataCollector said:

ist es mir unverständlich, warum dies am USB Stick liegen soll.

Verstehen tue ich es ja auch nicht, aber offensichtlich ist "Schreiben auf den USB Stick" der Auslöser für die Blockade.

10 minutes ago, DataCollector said:

Sollte Linux evtl. doch nicht so multitaskingfähig sein

Der Kernel selber kennt kein Multitasking. Der ist (muss er zwangsläufig sein) eine single Thread Schleife, die den sogenannten "Scheduler" abarbeitet. Und wenn aus irgendeinem Grund diese Schleife blockiert, ist Ende Gelände.

Aber so tief wird der Absturz nicht sein, man kann ja zumindest noch an der Konsole die Screens wechseln und laufende Sessions sind bedienbar.

BIS sie irgendeinen Zugriff aufs Dateisystem machen, dann werden sie schlafen gelegt und nie wieder geweckt.

("Deadlock")

Ist zwar nun schon ein paarmal passiert, aber bislang nicht reproduzierbar. Deshalb hab ich noch nie was gesagt. Aber wenn nun einer mit denselben Phänomenen vorbeikommt, dann wird die Sache interessant...

6 hours ago, DataCollector said:

Transcend hat extrem viele sehr unterschiedliche Jetflash Typen im Angebot. Diese Aussage sagt somit leider nicht viel.

Lokales Backup des USB Sticks machen (unraid bietet dafür eine Funktion),

Unraid herunter fahren

USB Stick löschen, einmal komplett mit nachvollziehbaren Daten voll schreiben und dann all diese Daten lesen und prüfen ob diese korrekt sind.

- Wenn alles okay ist, Stick wieder löschen und das Flashbackup zurückspielen und dann urnaid damit wieder starten.

- Wenn nicht alles okay ist: das deutet dann sehr stark auf einen Schreibfehler hin, was entweder ein USB-, Dateisystemfehler oder ein USB-Stick-defekt sein kann. In dem Fall sollte man sich noch genauer mit dem Stick und dem schreibenden PC beschäftigen.

Die Zeitschrift ct (Heise Verlag) hat für solche Tests, schon vor Jahren, eine sehr praktische Windows Software "h2testw.exe" raus gebracht, welche einen Datenträger mit nachvollziehbarem Kauderwelsch voll schreibt und diesen im Nachgang dann auch auf Korrektheit prüft.

Solche Dateien deuten darauf hin, daß da (zumindest im Dateisystem) etwa schief gegangen ist.

Auch können solche Dateien ein Backup stark vergrößern.

Ein Dateisysetmfehler bedeutet nicht, daß der Stick selber physikalisch defekt ist.

Es bedeutet, daß zumindest logisch im Dateisystem etwas schief gegangen ist (Stromausfall beim Schreiben, USB Verbindungsabbruch beim Schreiben.... irgendetwas in de Art kann auch Schuld tragen).

Da der Stick notwendig ist um unraid zu starten (und der auch sporadisch auf Vorhandensein der Lizenz gelesen wird), kann unraid schlecht den Stick selber löschen, beschreiben. testen und dann wieder löschen und Backup zurückspielen.

Einen entspechenden Test mußt Du außerhalb von unraid machen.

OK das ist soweit erstmal klar. Welchen Stick genau kannst Du empfehlen, damit ist einfach schon mal eine Reserve parat habe? Und womit sollte ich das Backup zurück spielen? Das habe ich nämlich schon lokal gezogen. Mit dem UnRaid Tool? Und kann ich die FSK Dateien löschen?

Gruß

Infosucher

Edited June 21, 20251 yr by Infosucher

3 hours ago, MAM59 said:

Der Kernel STEHT, ist BLOCKIERT. Da geht nix mehr!

Das dürfte dann eher eben eher ein OS oder Treiberproblem sein.

3 hours ago, MAM59 said:

Aber so tief wird der Absturz nicht sein, man kann ja zumindest noch an der Konsole die Screens wechseln und laufende Sessions sind bedienbar.

Das klingt mir nicht nach einem "stehenden" Kernel, da er diese Aufgaben ja abarbeitet.

8 minutes ago, Infosucher said:

Welchen Stick genau kannst Du empfehlen, damit ist einfach schon mal eine Reserve parat habe?

Ich greife aktuell zu den erwähnten Transcent Jetflash 600 und 780, weil diese (laut Beschreibung) MLC NAND Flash-Chips verwenden, von denen ich mir eine längere Haltbarkeit verspreche.

Da die 600er Serie (USB2.0) nur noch in einigen geringeren Kapazitäten (als 32GB) erhältlich sind, wurde mein letzter unraid USB Stick ein 780 32GB (USB 3.0).

Ich sollte aber nicht unterschlagen, daß auch meine ersten beiden USB Sticks mit unraid bisher super funktionieren (siehe auch meine Signatur): "Samsung Bar Plus" + "Sandisk Cruzer Fit" (beide vor rund 3 Jahren für unraid neu gekauft und nach anfänglichen Tests, seitdem als unraid Bootstick in USB 2.0 Anschlüssen am Mainboard betrieben).

8 minutes ago, Infosucher said:

Und womit sollte ich das Backup zurück spielen?

Ich verwende der Bequemlichkeit halber den "Unraid.USB.Creator.Win32-2.1.exe", den ich mir gesichert habe. Alternativ kann man aber auch den manuellen Weg gehen:

https://docs.unraid.net/unraid-os/getting-started/manual-install-method/

Mit dem erwähnten Creator spiele ich gelegentlich ältere Versionen in mein Testsystem (Gigabyte B760M DS3H DDR4) ein, weil es sich mit unraid 6.12.4 einfacher testen läßt, als mit den Nachfolgeversionen.

8 minutes ago, Infosucher said:

Das habe ich nämlich schon lokal gezogen. Mit dem UnRaid Tool?

Der aktuelle unraid USB Stick Creator erfordert eine Installation und hat Probleme bei einigen USB Sticks die korrekte ID zu erkennen und zu nutzen.

Da kommen dann (sinngemäß) Aussagen wie: der Stick sei nicht nutzbar oder habe keine eindeutige ID oder so.

Mit dem älteren "Unraid.USB.Creator.Win32-2.1.exe" hingegen hatte ich noch keine solchen Probleme.

8 minutes ago, Infosucher said:

Und kann ich die FSK Dateien löschen?

Ich habe es gemacht, als ich die einmal nach einem Absturz entdeckt hatte und das unraid problemlos gebootet hat.

Edited June 21, 20251 yr by DataCollector

21 hours ago, DataCollector said:

Ich greife aktuell zu den erwähnten Transcent Jetflash 600 und 780, weil diese (laut Beschreibung) MLC NAND Flash-Chips verwenden, von denen ich mir eine längere Haltbarkeit verspreche.

Da die 600er Serie (USB2.0) nur noch in einigen geringeren Kapazitäten (als 32GB) erhältlich sind, wurde mein letzter unraid USB Stick ein 780 32GB (USB 3.0).

Ich sollte aber nicht unterschlagen, daß auch meine ersten beiden USB Sticks mit unraid bisher super funktionieren (siehe auch meine Signatur): "Samsung Bar Plus" + "Sandisk Cruzer Fit" (beide vor rund 3 Jahren für unraid neu gekauft und nach anfänglichen Tests, seitdem als unraid Bootstick in USB 2.0 Anschlüssen am Mainboard betrieben).

Ich verwende der Bequemlichkeit halber den "Unraid.USB.Creator.Win32-2.1.exe", den ich mir gesichert habe. Alternativ kann man aber auch den manuellen Weg gehen:

https://docs.unraid.net/unraid-os/getting-started/manual-install-method/

Mit dem erwähnten Creator spiele ich gelegentlich ältere Versionen in mein Testsystem (Gigabyte B760M DS3H DDR4) ein, weil es sich mit unraid 6.12.4 einfacher testen läßt, als mit den Nachfolgeversionen.

Der aktuelle unraid USB Stick Creator erfordert eine Installation und hat Probleme bei einigen USB Sticks die korrekte ID zu erkennen und zu nutzen.

Da kommen dann (sinngemäß) Aussagen wie: der Stick sei nicht nutzbar oder habe keine eindeutige ID oder so.

Mit dem älteren "Unraid.USB.Creator.Win32-2.1.exe" hingegen hatte ich noch keine solchen Probleme.

Ich habe es gemacht, als ich die einmal nach einem Absturz entdeckt hatte und das unraid problemlos gebootet hat.

OK vielen Dank. Ich stelle mir immer die Frage, warum es ein 32 GB Stick sein muss? Mein Stick ist nahezu leer. Reicht das nicht auch locker ein 16 GB Stick? Oder was genau ist der Hintergrund?

Gruß

Infosucher

1 minute ago, Infosucher said:

Ich stelle mir immer die Frage, warum es ein 32 GB Stick sein muss? Mein Stick ist nahezu leer. Reicht das nicht auch locker ein 16 GB Stick? Oder was genau ist der Hintergrund?

Der Hintergrund ist eigentlich, dass man kleinere Sticks kaum noch kaufen konnte. Klar ist 32Gb "overdressed", aber wenn es nix mehr anderes gibt?

Und 32Gb ist das Limit für FAT. Es geht nun aber auch exFAT, so dass man auch grössere Sticks verwenden kann.

Wenn Du also so ein 16gb Dingen in der Ecke rumfliegen hast: NUR ZU! (selbst 8 ist schon zuviel)

Edited June 22, 20251 yr by MAM59

1 hour ago, Infosucher said:

OK vielen Dank. Ich stelle mir immer die Frage, warum es ein 32 GB Stick sein muss? Mein Stick ist nahezu leer. Reicht das nicht auch locker ein 16 GB Stick? Oder was genau ist der Hintergrund?

Muß es nicht.

Der verwendete 'Cruzer Fit ' hat 16GB (als ich mit unraid angefangen habe, habe ich mich eben spontan dafür entschieden und da er noch nicht verstorben ist, ist er es geblieben).

Aber seitdem nutze ich 32GB.

In der Anleitung wurde mal von bis 32 GB Sticks geschrieben (hatte wohl etwas mit Bootfähigkeit des jeweiligen UEFI/BIOS zu tun).

Man könnte auch größere Sticks verwenden, doch wofür?

Auf dem Stick befindet sich ein weniger als 2GB an OS und Konfigurationsdateien und temporär werden durch Logs oder Erzeugung des FlashBackups vielleicht nochmal 1GB benötigt.

Somit sollte auch ein Stick mit 4GB schon auf lange Zeit reichen, doch dann kann der USB Stick Kontroller beim Schreiben nicht auf so viele unterschiedliche Speicherzellen zurückgreifen.

Deshalb gehe ich eben über 4GB hinaus und sehe eine (für mich) akzeptable Preisgrenze bei max. 32GB.

Damit habe ich dann den Kompromiß zwischen mindestens genug Speicherplatz für das Nötigste, ausreichend angenommener Haltbarkeit und andererseits zuviel Geld rausgeschmissen.

On 6/21/2025 at 6:42 AM, MAM59 said:

Scheint mir mal wieder (siehe USV Probleme) der USB Treiber von UNRAID/Linux zu sein...)

Ist da tatsächlich etwas bekannt? Hab keine USV - ist wohl an mir vorbei gegangen. Kannst Du mir ggfs. den passenden Thread benennen? Das wäre sehr freundlich.

Ich kämpfe seit einiger Zeit mit meinen USB Lizenz Sticks. Nach ein paar Wochen (4-8) kommt immer die selbe Nachricht und der Rechner ist tot. Mittlerweile starte ich den Server (einen Server!) alle 4 Wochen neu, um dem Phänomen zuvor zu kommen.

Der Stick ist nach dem Crash sofort in jedem anderen Gerät lesbar, keine Fehler. Ich habe schon andere Sticks, andere Ports, USB3, USB2, Verlängerungskabel dazwischen, einfach alles versucht. Ohne Erfolg.

Das ist die Meldung. Passt die eventuell zu dem von Dir genannten USV Thread?

May 31 01:28:57 Tower kernel: usb 1-3: reset high-speed USB device number 2 using xhci_hcd

May 31 01:29:02 Tower kernel: usb 1-3: device descriptor read/64, error -110

May 31 01:29:18 Tower kernel: usb 1-3: device descriptor read/64, error -110

1 hour ago, hawihoney said:

st da tatsächlich etwas bekannt? Hab keine USV - ist wohl an mir vorbei gegangen. Kannst Du mir ggfs. den passenden Thread benennen? Das wäre sehr freundlich.

Na ja, der erste Thread dazu ist schon Jahre her, aber unlängst hatte ich nochmal einen Refresh gemacht unter https://forums.unraid.net/topic/190870-amazon-basic-ups-geht-doch-mit-unraid/#comment-1559044

Danach haben sich einige gemeldet, bei denen der Tipp auch funktioniert hat.

Das "Problem" mit Sticks ist allerdings, dass sie keine eigene Stromversorgung haben, somit also keine 5V Kollision auftreten kann. Insofern trifft der Tipp nicht auf Sticks zu.

Ich meine nur "probieren schadet nix", man könnte es mal einfach machen und gucken, was passiert.

Schlechter werden kann es dadurch auf jeden Fall nicht.

(Die USV hat nun auch schon 2 Monate durchgehalten, früher unmöglich)

1 hour ago, hawihoney said:

Das ist die Meldung. Passt die eventuell zu dem von Dir genannten USV Thread?

Ja, sowas in der Art war das (genau weis ichs nicht mehr, das war noch zu 5.x Zeiten, danach hatte ich aufgegeben und erst mit 7.0 wieder probiert (die Ausfälle waren ohne Hub weiterhin quasi sofort wieder vorhanden)).

(Addon: diese "Spikes", "Notabschaltung" oder wie immer man es nennen will, ist kein "Fehler" der Hardware. Es ist eine Lücke im USB Protokoll. Man hat schlichtweg vergessen zu regeln, wer "Vorfahrt" hat und somit kann jeder Hersteller sich eine eigene Implementation ausdenken. Im Normalfalle gibt es dadurch keine Probleme. Aber es gibt wohl genug Stress mit bestimmter Hardware, so dass die Raspberry Foundation sich entschlossen hat, eine Gegenmaßnahme zu entwickeln. Kann sein, dass neue Raspis demnächst den Schutz gleich mit onboard implementiert haben. Such mal da nach ner Doku, die haben sich recht ausführlich darüber ausgelassen)

Edited June 22, 20251 yr by MAM59