Hallo allerseits,


ich nehme auf einen nfs-share auf, allerdings passiert es nicht selten, daß die Aufnahme einfach stehenbleibt. Die Vu+ meldet dann einen "read error" und alle Zugriffe auf das nfs hängen mit einem uninterruptible sleep ("D"). Es gibt zwar keinen Grund, weshalb die Vu+ das nfs verliert (der nfs-server ist mit 4xGE redundant angebunden, andere nfs-clients halten die Verbindung problemlos, Kabel sind in Ordnung, Dose ist in Ordnung, Patchpanel ist in Ordnung, Switchports sind in Ordnung), aber gut, dann ist es halt so.

Was mich allerdings irritiert, ist daß sich Linux anders verhalten sollte, z.B. den nfs-mount nach einem Timeout wegschmeißen. Aber nichts dergleichen passiert.
In der Prozesstabelle sind gerade, als ich das Problem genauer untersuchen wollte, Einträge mit irgendwelchem Unsinn überschrieben worden:

Screenshot from 2020-01-31 22-45-20.png

Nach einem Reboot war der Sender kurz da, dann gab es kein Signal mehr – weder an TV (hdmi) noch an den Verstärker (s/pdif). Die Vu+ war noch über ssh erreichbar. Nach Poweroff/-on über den rückseitigen Schalter verhält sich die Vu+ jetzt erstmal wieder normal.

Es fühlt sich ein wenig so an, als sei eventuell der RAM kaputt. Sind die Speicherriegel vielleicht austauschbar? Oder hat jemand eine andere Idee?

Danke.
Gibt es denn eine Möglichkeit, den RAM zu tauschen? Die Vu+ ist jetzt ein Jahr und 20 Tage alt, damals bei Alternate gekauft.

Bitmap? Der Screenshot kommt aus der Konsole (ssh), nicht vom Fernseher. Ich hatte ein ähnliches Problem schonmal vor zig Jahren auf einem System mit RAM ohne ECC. Da hagelte es zusätzlich zur kaputten Prozesstabelle auch segvs. Umgehen konnte ich es kurzfristig durch memory mapping, bis ich neue Riegel geholt hatte. Was theoretisch auch mit der Vu+ gehen könnte.

Zum Zeitpunkt, als der Screenshot entstand, war zudem noch ein swapfile aktiv. Wenn ich Glück habe, war nur das swapfile (bzw. die Platte, auf der es lag) defekt. Ich warte mal ab, ob es nochmal auftritt.

GaborDenes schrieb:

Ein swapfile auf ner Uno4K?
Wozu das?

Bei irgendwelchen Experimenten hatte ich den Speicher zugemüllt und brauchte mehr. Hatte die halt noch drin. Swappiness auf 0, aber trotzdem kann was verwendet werden.

RickX schrieb:

Wie sieht das denn auf Linux-Ebene aus?
Was zeigt z.B. htop an?

Wenn das alles noch läuft, ohne dass die Box abstürzt, glaube ich eher nicht an Hardware-Fehler...


Computer sind empfindlich. Wenn RAM kaputt ist, knallt es.
Es gibt keine RAM-Bereich, die nur für diese Fragezeichen zuständig sind...
Sowas sind eher Software-Probleme.

122MiB von den (verfügbaren) 741MiB sind belegt. Soweit alles easy.

Die Box blieb bisher öfter mal mit dem Spinner hängen, dazu hatte ich auch den einen oder anderen thread hier eröffnet.

RAM kann durchaus auch nur partiell kaputt sein, was man durch memory mapping wenigstens kurzfristig umgehen kann. Sofern man die entsprechenden Tools drauf hat und Zeit mitbringt. Und Muße.
Natürlich gibt es keinen "RAM-Bereich, der für Fragezeichen zuständig ist", aber eine kaputte Prozesstabelle kann einen Hinweis auf korrupten Speicher an der Stelle, an der in dem Moment die Prozessnamen lagen, liefern. Wenn man sich RAM-Inhalte sonst so ansieht, wird man kaum visuell entscheiden können, ob ein Speicherbereich den richtigen Inhalt hat, wenn dort nicht interpretierbarer Klartext vorliegt (sprich: man erwartet "shellinaboxd" und liest "sh?..%!&&§xd" oder so).

Also: überflüssiges swapfile ist wieder weg, verdächtige Platte wird nicht mehr für swapfile, logs, timeshift verwendet, Montag kommt ne neue Platte, dann wird auch nfs nicht mehr für timeshift verwendet, ich beobachte weiter. Vermutlich hat sich der thread schon erledigt, denn entweder das Problem tritt nochmal auf, womit die Box zu Alternate geht, oder das Problem löst sich in Luft auf, womit ich überaus zufrieden wäre

Danke für die Antworten!