Hi.
Ich bräuchte mal etwas Hilfe...
Nach den letzten Tumbleweed Updates habe ich nur noch eine flimmernde Anzeige. :-(
Weis nicht recht wonach ich noch schauen kann. Fing vor dem Urlaub mit einem Update an, da dachte ich noch: Einfach auf den nächsten Kernel warten, aber gebracht hat es nix.
Wenn ich den Kernel: X64 5.1.7-1 boote funktioniert alles normal, ab der 5.1.61-1 ff. flimmert es mich nur noch an.
Ist ein Laptop mit einer:
ATI/AMD Radeon RV620/M82 [Mobility Radeon HD 3450/3470
Geladen ist der radeon Treiber.
Das Flimmern geht ab laden der Initrd los, so Doppel-Dreifachbild.
Was kann ich tun, woran drehen?
Mäh! Und irgend was löscht mir die alten Kernel OBWOHL ich in /etc/zypp/zypp.conf die lastest-1 zu latest-11 geändert habe. :-(
multiversion.kernels = latest,latest-11,running
Tschö' Sue
Am 26.08.2019 um 18:30 schrieb Sandre Useres:
Mäh! Und irgend was löscht mir die alten Kernel OBWOHL ich in /etc/zypp/zypp.conf die lastest-1 zu latest-11 geändert habe. :-(
multiversion.kernels = latest,latest-11,running
Hab ich wohl mit einer anderen Config vebuchselt, muss man (umständlicherweise) so schreiben:
multiversion.kernels = latest,latest-1,latest-2,latest-3,latest-4,running
Und ich dachte: latest-11 == latest BIS nn :-/
Tschö' Sue
Am Mon, 26 Aug 2019 18:30:05 +0200 schrieb Sandre Useres suse@fkn-systems.de:
Hi.
Ich bräuchte mal etwas Hilfe...
Nach den letzten Tumbleweed Updates habe ich nur noch eine flimmernde Anzeige. :-(
Weis nicht recht wonach ich noch schauen kann. Fing vor dem Urlaub mit einem Update an, da dachte ich noch: Einfach auf den nächsten Kernel warten, aber gebracht hat es nix.
Wenn ich den Kernel: X64 5.1.7-1 boote funktioniert alles normal, ab der 5.1.61-1 ff. flimmert es mich nur noch an.
Ist ein Laptop mit einer:
ATI/AMD Radeon RV620/M82 [Mobility Radeon HD 3450/3470
Geladen ist der radeon Treiber.
Das Flimmern geht ab laden der Initrd los, so Doppel-Dreifachbild.
Sichere mal /etc/X11/xorg.conf, sofern vorhanden. Dann mittels Xorg -configure eine neue /etc/X11/xorg.conf erstellen. [...]
-Dieter
Am 26.08.2019 um 19:24 schrieb Dieter Klünter:
Am Mon, 26 Aug 2019 18:30:05 +0200
Wenn ich den Kernel: X64 5.1.7-1 boote funktioniert alles normal, ab der 5.1.61-1 ff. flimmert es mich nur noch an. ATI/AMD Radeon RV620/M82 [Mobility Radeon HD 3450/3470 Geladen ist der radeon Treiber. Das Flimmern geht ab laden der Initrd los, so Doppel-Dreifachbild.
Sichere mal /etc/X11/xorg.conf, sofern vorhanden. Dann mittels Xorg -configure eine neue /etc/X11/xorg.conf erstellen.
M.E. sollte man ja wohl eher mit dem /etc/xorg.d/ Verzeichnis arbeiten, aber ok...
Auf dem System hat es keine /etc/X11/xorg.conf
* Boot mit altem Kernel nach Runlevel 3. * cd /etc * cp -a X11 X11.BAK * Xorg -configure * mv ~/xorg.conf.new /etc/X11/xorg.conf * X # ... Läuft (mit altem Kernel) * mkinitrd # baut ohne Fehler für alten und neuen Kernel * reboot * Grub2: Auswahl neuer Kernel # (keine ungewöhnlichen Parameter in der Configzeile) * Shredderbild schon für Passphrase Cryptodisc
Das funktioniert also auch nicht. :-(
Die nächste Idee bitte...
Tschö' Sue
Am 26.08.2019 um 18:30 schrieb Sandre Useres:
Hi.
Ich bräuchte mal etwas Hilfe...
Nach den letzten Tumbleweed Updates habe ich nur noch eine flimmernde Anzeige. :-(
Weis nicht recht wonach ich noch schauen kann. Fing vor dem Urlaub mit einem Update an, da dachte ich noch: Einfach auf den nächsten Kernel warten, aber gebracht hat es nix.
Wenn ich den Kernel: X64 5.1.7-1 boote funktioniert alles normal, ab der 5.1.61-1 ff. flimmert es mich nur noch an.
5.1.61 ??? So eine Version gibt es nicht
Ab 5.1.21 war Schluss
Ist ein Laptop mit einer:
ATI/AMD Radeon RV620/M82 [Mobility Radeon HD 3450/3470
Geladen ist der radeon Treiber.
Das Flimmern geht ab laden der Initrd los, so Doppel-Dreifachbild.
Was kann ich tun, woran drehen?
Ansonsten gibts nur die Möglichkeit, alten Kernel behalten und Bug-Report schreiben
Manfred
Am Mon, 26 Aug 2019 18:30:05 +0200 schrieb Sandre Useres suse@fkn-systems.de:
Hallo Sue!
Nach den letzten Tumbleweed Updates habe ich nur noch eine flimmernde Anzeige. :-(
Reine Spekulation: Hast Du es schonmal mit bzw. ohne den Bootparameter nomodeset probiert?
Viele Grüße
Matthias
Am 26.08.2019 um 18:30 schrieb Sandre Useres:
Ich bräuchte mal etwas Hilfe... Nach den letzten Tumbleweed Updates habe ich nur noch eine flimmernde Anzeige. :-( Wenn ich den Kernel: X64 5.1.7-1 boote funktioniert alles normal, ab der 5.1.61-1 ff. flimmert es mich nur noch an. ATI/AMD Radeon RV620/M82 [Mobility Radeon HD 3450/3470 Geladen ist der radeon Treiber. Das Flimmern geht ab laden der Initrd los, so Doppel-Dreifachbild.
Nach einigen Tests und rumprobieren mit viel Internetsuche, hat mich bisher nichts weitergebracht. Also habe ich ein openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20190810-Media.iso auf einen Stick gebracht und gestartet.
Es ist dasselbe Fehlerbild wie in den Systemen:
* Flimmern nach laden initrd * Kein flimmern, aber auch kein X nach bootparam: nomodeset
Es scheint sich m.E. um Probleme mit dem vcync? zu handeln.
Kann man das als Kernel-Parameter zur Boot-Zeit irgendwie setzten?
Ist ein Laptop mit TFT, müsste also 50-60Hz und ~40-80VhZ liegen.
Tschö' Sue
Am Tue, 27 Aug 2019 16:28:37 +0200 schrieb suse suse@fkn-systems.de:
Hallo Sue!
- Flimmern nach laden initrd
Hat der zu dem neuen Kernel auch eine neue initrd (erfolgreich) gebaut? Du mußt zu jedem Kernel eine passende initrd haben.
- Kein flimmern, aber auch kein X nach bootparam: nomodeset
Was heißt "kein X"? Hast Du mal versucht (flimmerfrei) in eine Textkonsole zu starten und den Xserver von dort per Hand aufzurufen? Möglicherweise gibt es hilfreiche Fehlermeldungen. (Dabei /etc/permissions.local beachten.)
Es scheint sich m.E. um Probleme mit dem vcync? zu handeln.
Kann man das als Kernel-Parameter zur Boot-Zeit irgendwie setzten?
video=$HRESx$VRES[@refresh] wobei hres und vres für die echte Auflösung des Monitors steht und refresh für LCDs in der Regel 60 ist. Wenn ich es richtig sehe, gelten diese Werte aber nur bis zum Starten der graphischen Oberfläche.
"Eigentlich" sollte das mittlerweile nicht mehr nötig sein, aber es gibt es noch eine Möglichkeit auf Ebene des Xservers, die in /etc/X11/xorg.conf.d/??-monitor.conf beschrieben ist. Bei falschen Werten konnte man sich früher seine CRTs in einen Haufen Elektronikschrott verwandeln. Wie das bei LCD ist, weiß ich nicht, also _ohne_ Gewähr!
Hast Du schonmal geguckt, ob Du unter /etc/modprobe.d/ evtl. konkurrierende Treiber lädst?
Mehr fällt mir dazu im Moment leider auch nicht ein.
Viele Grüße
Matthias
Am 27.08.2019 um 18:52 schrieb Matthias:
Am Tue, 27 Aug 2019 16:28:37 +0200 schrieb suse suse@fkn-systems.de:
- Flimmern nach laden initrd
Hat der zu dem neuen Kernel auch eine neue initrd (erfolgreich) gebaut? Du mußt zu jedem Kernel eine passende initrd haben.
Ja
- Kein flimmern, aber auch kein X nach bootparam: nomodeset
Was heißt "kein X"? Hast Du mal versucht (flimmerfrei) in eine
Heisst kein X, nix Grafik, nix SHDM^WGrafische_Anmelde, X nicht getartet
Textkonsole zu starten und den Xserver von dort per Hand aufzurufen? Möglicherweise gibt es hilfreiche Fehlermeldungen. (Dabei /etc/permissions.local beachten.)
Textkonsolen flimmern dann auch, was korrekte Eingaben, aber vor allem das Lesen zur echten Challenge macht.
Es scheint sich m.E. um Probleme mit dem vcync? zu handeln.
Kann man das als Kernel-Parameter zur Boot-Zeit irgendwie setzten?
video=$HRESx$VRES[@refresh]
Und funktioniert ebenfalls nicht.
"Eigentlich" sollte das mittlerweile nicht mehr nötig sein, aber es gibt es noch eine Möglichkeit auf Ebene des Xservers, die in /etc/X11/xorg.conf.d/??-monitor.conf beschrieben ist. Bei falschen
Ich würde dir ja zustimmen, aber das Prob siedelt doch wesentlich VOR dem X. Es tritt bereits beim Plymeth-Boot-Screen, etwa zur Eingabe der Cryptophrase auf und auf den Textkonsolen, auch Runlevel 1+3, wenn hochgefahren.
Hast Du schonmal geguckt, ob Du unter /etc/modprobe.d/ evtl. konkurrierende Treiber lädst?
Wenn es flimmert, ist der radeon geladen.
Entweder wurde was am Kernel und/oder den radeon-Treibern, bzw. dem DRM-, DRI-, GLX-, MESA-Umfeld seid der Version 5.1.7 geändert. Ein Crosstest mit tagesaktueller LiveCD bestätigt, das das Prob nicht in meinem System liegt.
Aber da nachfroschen liegt etwas außerhalb meiner Begabung... Drum frag ich ja hier. :-)
Gab es da nicht noch eine Möglichkeit dem Grafik-Treiber direkt Optionen mitzugeben? M.E. müsste man da die Framerate auf 60Hz festnageln. Denn die scheint doch zu hoch zu sein, weswegen das LCD flimmert und Doppelbild macht.
Tschö' Sue
Am Tue, 27 Aug 2019 21:14:45 +0200 schrieb suse suse@fkn-systems.de:
Hallo Sue!
Du hast mich noch auf zwei Ideen gebracht, die ich aber nur als Frage formulieren kann, da ich keine AMD-Graphik habe.
Wenn es flimmert, ist der radeon geladen.
Auch bei AMD gibt es doch zwei Treiberlinien: Eine von AMD selbst und eine von der Community entwickelt. Hast Du mal die andere Linie probiert?
Ich weiß nicht, wie das bei AMD geregelt ist, aber auch dort sollte es doch ein Kernel-Modul des Graphiktreibers geben, das zum jeweiligen Kernel passen, d.h. bei einem Kernel-Update auch neu kompiliert werden muß. Zusatzfrage: Passen Kernelversion und Graphiktereiberversion überhaupt noch zusammen?
Textkonsolen flimmern dann auch, was korrekte Eingaben, aber vor allem das Lesen zur echten Challenge macht.
Trotzdem noch einen schönen Abend
Matthias
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Am Dienstag, den 27.08.2019, 22:36 +0200 schrieb Matthias:
Auch bei AMD gibt es doch zwei Treiberlinien: Eine von AMD selbst und eine von der Community entwickelt.
Jaein. Der alte fglrx-Treiber wurde bereits seit längerer Zeit eingestellt.
Aktuell sind jedoch 2 freie Treiber. Der "radeon" und der "amdgpu". Amdgpu ist der neuere von den beiden und unterstützt AMD-Grafikkarten ab der Southern Island GPU-Reihe. Für ältere Grafikchips sollte der "radeon"-Treiber genutzt werden.
Das Nachfolgemodell des ehemaligen fglrx ist die "amdgpu-pro" Treibersammlung. Hierin gibt es aber einen Teil, welcher mit den in den Distributionen vorhandenen, freien Komponenten sehr verwandt ist und, sozusagen, zusätzliche, geschlossene Bestandteile. Außerdem zielt AMD mit den pro-Treibern auf professionelle Anwender und den Enterprise Sektor. Dies ist unter anderem auch daran zu erkennen, dass von diesem Treiberpaket lediglich die Distributionen RHEL (Red Hat Enterprise Linux), CentOS, Ubuntu LTS sowie SLES/SLED unterstützt werden.
Am freien Treiber entwickeln nicht nur freiwillige mit, sondern, ebenso wie bei Intel, Entwickler von AMD selbst.
Ich weiß nicht, wie das bei AMD geregelt ist, aber auch dort sollte es doch ein Kernel-Modul des Graphiktreibers geben, das zum jeweiligen Kernel passen, d.h. bei einem Kernel-Update auch neu kompiliert werden muß.
Nein. Die Quellen sind im Linux-Kernel. Gibt es ein Kernel-Update, so wird somit ja eh immer ein entsprechendes, aktuelles, zum Kernel passendes Modul mitgeliefert.
Zusatzfrage: Passen Kernelversion und Graphiktereiberversion überhaupt noch zusammen?
Das müssen sie zwangsläufig (s.o.).
- --
MfG Richi
Am 31.08.19 um 02:32 schrieb Richard Kraut:
Am Dienstag, den 27.08.2019, 22:36 +0200 schrieb Matthias:
Auch bei AMD gibt es doch zwei Treiberlinien: Eine von AMD selbst und eine von der Community entwickelt.
... Nein. Die Quellen sind im Linux-Kernel. Gibt es ein Kernel-Update, so wird somit ja eh immer ein entsprechendes, aktuelles, zum Kernel passendes Modul mitgeliefert. ...
Zusatzfrage: Passen Kernelversion und Graphiktereiberversion überhaupt noch zusammen?
Das müssen sie zwangsläufig (s.o.).
Ich habe von AMD amdgpu-pro openCL Teil hinzugenommen (opencl-amdgpu-pro).
Es gab - nicht immer, aber doch gelegentlich - Schwierikeiten bei einem Kernelupdate, ich musste den amd-Teil komplett deinstalliern und nach dem Update neu installieren. Sonst alles schmerzfrei.
System: Leap 15.0, amdgpu-pro_19.30 von AMD.
Gruß Peter
musst ich sie herausnehmen und
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Am Samstag, den 31.08.2019, 14:39 +0200 schrieb Peter McD:
Ich habe von AMD amdgpu-pro openCL Teil hinzugenommen (opencl-amdgpu-pro).
Jepp. Den Teil habe ich auch nachgerüstet. Aber ohne das dkms-Modul.
Es gab - nicht immer, aber doch gelegentlich - Schwierikeiten bei einem Kernelupdate, ich musste den amd-Teil komplett deinstalliern und nach dem Update neu installieren.
Bis jetzt hier noch nicht. Läuft top.
Sonst alles schmerzfrei.
Kann ich bestätigen.
- --
MfG Richi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Am Dienstag, den 27.08.2019, 21:14 +0200 schrieb suse:
Entweder wurde was am Kernel und/oder den radeon-Treibern, bzw. dem DRM-, DRI-, GLX-, MESA-Umfeld seid der Version 5.1.7 geändert. Ein Crosstest mit tagesaktueller LiveCD bestätigt, das das Prob nicht in meinem System liegt.
In allen neueren Distributionen ist es doch gerade Mode, dass man einen "flimmerfreien" Startvorgang möchte. Vom Start weg ab Grub bis zum geladenen Desktop. Bei Dir scheint das ja gerade völlig umgekehrt zu sein.
Gab es da nicht noch eine Möglichkeit dem Grafik-Treiber direkt Optionen mitzugeben? M.E. müsste man da die Framerate auf 60Hz festnageln. Denn die scheint doch zu hoch zu sein, weswegen das LCD flimmert und Doppelbild macht.
Wenn ein halbwegs moderner Monitor mit zu viel Hz angesteuert wird, erhält man die bekannt Meldung "Out of range" o.ä. und außer der Meldung zeigt der Monitor sonst nichts mehr an. Bei digitalen Anschlüssen kann man zudem nicht einfach eine beliebige Wiederholfrequenz einstellen. Im Falle meines Laptops sowie meines Desktop-PCs kann ich bspw. in den beiden Desktopumgebungen KDE als auch XFCE in den Monitoreinstellungen ledigich zwischen "Automatisch" und "59.9 Hz" wählen. Mehr oder andere Werte werden mir gar nicht zur Verfügung gestellt. Über den alten, analogen VGA-Anschluss konnte man die Frequenzen freier wählen bzw. hatte hier mehr Wahlmöglichkeiten.
Wie sieht der Startvorgang bei Dir überhaupt aus, wenn Du mal mit den beiden Optionen "nosplash" und "noplymouth" startest?
- --
MfG Richi
Am 30.08.2019 um 18:06 schrieb Richard Kraut:
Wie sieht der Startvorgang bei Dir überhaupt aus, wenn Du mal mit den beiden Optionen "nosplash" und "noplymouth" startest?
Es ist egal.
Egal ob mit oder ohne Optionen. Egal ob Text oder Grafik Start. Es hängt nicht am X, es geht bereits direkt nach dem GRUB-Screen los.
* Laptop Gaka * ATI/AMD Radeon RV620/M82 [Mobility Radeon HD 3450/3470 * radeon driver * GRUB-MENU: OK * Kernelload: OK * Initrdload: Flimmert OK on Kernel X64: * 5.1.7-1 * False on: * 5.1.16-1 * 5.2.9-1 * False on too: * Boot from actual Tumbleweed Live Iso
Siehe anhängende Bilder. (hab die so klein wie möglich gemacht)
Auf c.jpg erkennt man gut das Doppelbild. Sowas kenne ich nur von früher mit den Analogmonitoren. Auf TFT sollte das so nicht funktionieren.
Es schaut aus wie wenn die Bildwiederholungsrate daneben ist, in der Konsequenz wird das Bild mehrfach überlagert angezeigt. Dabei flimmert es und springt Zeilenweise wie bei einem schlechten Fernseher von früher.
In der Zwischenzeit habe ich weiter recherchiert und ausprobiert, bisher ohne weiteres Ergebnis - und mir gehen die Ideen aus... :-(
Tschö' Sue
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Am Samstag, den 31.08.2019, 16:55 +0200 schrieb suse:
Es ist egal.
Egal ob mit oder ohne Optionen. Egal ob Text oder Grafik Start. Es hängt nicht am X, es geht bereits direkt nach dem GRUB-Screen los.
Also auch mit dem Parameter "nomodeset" wie von Matthias bereits erwähnt?
Auf c.jpg erkennt man gut das Doppelbild. Sowas kenne ich nur von früher mit den Analogmonitoren. Auf TFT sollte das so nicht funktionieren.
Es schaut aus wie wenn die Bildwiederholungsrate daneben ist, in der Konsequenz wird das Bild mehrfach überlagert angezeigt. Dabei flimmert es und springt Zeilenweise wie bei einem schlechten Fernseher von früher.
Nicht schön.
In der Zwischenzeit habe ich weiter recherchiert und ausprobiert, bisher ohne weiteres Ergebnis - und mir gehen die Ideen aus... :-(
Zwei, drei, evtl. auch vier Dinge, welche man noch prüfen und testen könnte wären:
1) In der Grub-Konsole mit dem Befehl "vbeinfo" prüfen, welche Auflösungen erkannt bzw. zur Verfügung stehen. Diese können Grub dann ggf. übergeben werden. Bei einem Standard Full-HD Monitor (in meinem Fall hier ein 22" TFT im 16:10 Format) und einer Grafikkarte, welche dies auflösen kann, sollten auf alle Fälle Einträge mit 1680x1050 auftauchen.
2) Man kann die Auflösung, welche mit vbeinfo gewonnen wurde, dem System, zumindest bis zum Start des X-Server aufs Auge drücken. Hierzu öffnet man mit einem Editor seiner Wahl mit Rootrechten die Datei /etc/default/grub und ergänzt in dieser die beiden Zeilen (Achtung: Beispielwerte) GRUB_GFXMODE=1680x1050x32 und GRUB_GFXPAYLOAD_LINUX=keep. Erstere von beiden ist meist bereits vorhanden, enthält aber einen anderen Wert und ist zudem auskommentiert. Danach die Grub-Konfiguration neu schreiben lassen bzw. aktualisieren.
3) Um auszuschließen, dass Dein Problem von dem ganzen grafischen Schnickschnack während des bootens ausgelöst wird, kann man die betreffenden Pakete testweise deinstallieren. Kandidaten hierfür sind bspw. splash, bootsplash, plymouth und gfxboot.
4) Du hast ja bereits auch einen Test mit einer neueren Live-CD von Tumbleweed unternommen - ohne Erfolg. Mach den selben Test doch noch einmal aber bei diesem Versuch dann mit einer Live-CD von Leap (dient jetzt nur mal zum Vergleich).
- --
MfG Richi
-
Dieter Klünter -
Manfred Kreisl -
Matthias -
Peter McD -
Richard Kraut -
Sandre Useres -
suse