Beiträge von Welm

    Nicht gut für dich, aber du hast bestimmt nicht die selbe Hardware wie Suelkun . Deshalb lies dir bitte folgendes gut durch ...

    Es sieht aber sehr sehr nach demselben Problem aus und hat daher mit dem Kapern anderer Threads nichts zu tun:

    -nur bei einigen Radeon-Karten

    -nur beim Kernel 5.3.18-150300.59.43-default

    -Booten anderer Kernels im gleichen System ist problemlos

    -Rechner bleibt im Boot mit schwarzem Bildschirm hängen

    -Zustand ist nur per Abschalten beendbar.


    Im von Sauerland erwähnten Bugreport ist inzwischen ein Workaround angegeben. Bei mir ändert er aber nichts.

    Auf einem AMD A6-6420K APU with Radeon(tm) HD Graphics [Radeon HD 8470D] läuft der vmlinuz-5.3.18-150300.59.43-default anstandlos.


    Auf einem AMD Athlon(tm) II X2 250 Processor mit [Radeon HD 6450/7450/8450 / R5 230 OEM] ist der Effekt da. Der Rechner ist nicht per ssh ansprechbar und reagiert nicht mal auf ping oder Powerknopf. Die Boots mit dem vmlinuz-5.3.18-150300.59.43-default fehlen sogar in der Liste "journalctl --list-boots".


    Vermutlich wird es mit dem nächsten Kernel beseitigt sein. Sicherheitshalber hab ich in /etc/zypp/zypp.conf das

    Code
    multiversion.kernels = latest,latest-1,running

    gegen

    Code
     multiversion.kernels = latest,latest-1,latest-2,running

    ausgetauscht.


    Mit dem Sperren hab ich mich noch nie beschäftigt. Gibt es da irgendwelche Sachen die man dann im Blick behalten muss oder ist das so einfach wie es sich anhört?

    Es ist ja das ganze Verzeichnis weg und nicht nur die RPMs darin. Sieht irgendwie mehr nach Absicht als nach Bug aus. Ich dachte, vielleicht hat jemand was von Problemen auf dem Gebiet gehört ... z.B. sowas wie "log4j-Probleme mit 15.3 und das Verzeichnis wird sicherheitshalber bis zur Lösung entfernt".

    Ich verstehe nicht, wieso ein Wohnungseinrichtungsprogramm wie SweetHome3D oder ein Bankingprogramm wie Hibiscus davon betroffen sind. Und wieso das in Tumbleweed anders ist als in 15.3.

    Leider verstehe ich Deine Problembeschreibung und die Lösung aus Post #2 nicht :).

    Dann versuch ich mal, es anders zu beschreiben :)


    Gwenview hat beim Anzeigen von Bildern aus einem großen Verzeichnis massenweise RAM gebraucht ... mehr als da war.


    Es lag aber nicht an den vielen Bildern. Es waren einzelne dieser Bilder, die enorm RAM geschluckt haben. Die große Masse der Bilder war gar kein Problem. Es lag nicht an der Kamera oder am Motif, denn ich hatte zwei direkt nacheinander mit derselben Kamera aufgenommene Bilder von denen das eine problemlos war und das andere so ein RAM-Schlucker. Geprüft hab ich es dadurch, dass ich das "böse" Bild ein paar Mal in ein neues Verzeichnis kopiert habe und beim Betrachten mit gwenview waren sofort die 16GB weg und der Rechner fing an zu swappen. Ich hab dann erstmal andere Programme statt gwenview benutzt.


    Irgendwann hab ich dann doch noch die gemeinsame Eigenschaft dieser "bösen" Bilder gefunden. In einem JPEG kann ja zusätzlich ein kleines Vorschaubild gespeichert werden. Bei JPGs aus Canonkameras wird zusätzlich noch eingetragen, welchen Ausschnitt davon bei Vorschauen das Anzeigeprogramm nehmen soll. Da stand jetzt bei einem Vorschaubild von z.B. 200x300 Pixel dran: Nimm für die Vorschau Pixelspalte 10437 bis 45358 und die Pixelzeilen 3246 bis 61799. Diese Spalten- und Zeilennummern gibt es aber in dem 200x300 Vorschaubild nicht. Da dürften ja nur viel kleinere Zahlen vorkommen. Irgendwie ist gwenview dadurch total durcheinandergeraten.


    Ich hab dann mit exiftool die vier unsinnigen Zahlen alle durch 0 ersetzt. Das bedeutet, dass das ganze Vorschaubild genommen werden soll. Die Probleme waren dann weg.


    Mit der "Prüfung" soll nur sichergestellt werden, dass man nicht an Dateien herumbastelt, die gar kein Problem machen.


    Ich hab aber keine Ahnung woher diese fatalen Canon-Angaben kamen. Dass keiner geantwortet hat könnte ein Hinweise darauf sein, dass ich als einziger so doof war diese Tags kaputt zu machen ...

    Aber für den Fall, dass doch noch jemand das Problem bekommt, wollte ich doch gern eine Umgehungsstraße ausschildern :-))

    ...es sind bestimmte Bilder...

    Die problematischen Bilder sind die mit unsinnigen Einträgen der Canon Maker Notes in "Thumbnail Image Valid Area". Damit gibt man augenscheinlich eigentlich einen Ausschnitt des Thumbnails für die Thumbnail-Anzeige an.


    Anzeige:

    exiftool -ThumbnailImageValidArea x.jpg


    falls da keine plausiblen Pixelkoordinaten stehen sondern lustige Werte zwischen 0 und 65535:


    Prüfung:

    -verdächtige Datei in ein neues Verzeichnis kopieren

    -dort vervielfältigen. z.B. "for I in {01..22}; do cp -a x.jpg pic$I; done"

    -KSysGuard oder ähnliches zur Überwachung des RAM-Verbrauchs anwerfen

    -dort "gwenview ." starten und mit der Hand über Control-C ggf. rechtzeitig abbrechen bevor die Kiste anfängt zu swappen.


    und ggf. Reparatur:

    exiftool -ThumbnailImageValidArea="0 0 0 0" x.jpg

    Letzteres bedeutet "nimm das ganze Thumbnail als Thumbnail".