Bronies.de

Bronies.de > Off-Topic > Internet & Technik > Von Windows auf Linux - die Umsteiger
Normale Version: Von Windows auf Linux - die Umsteiger
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

404compliant

21.01.2015
fglrx meide ich, erstens mag ich mein System nicht durch unfreie Blob-Treiber gefährden, zweitens haben die meine Grafikkarte längst zu Elektroschrott erklärt. Sowohl die im PC, als auch die im Notebook.

Der xorg-radeon funktioniert dagegen von selbst. Auflösung wird automatisch erkannt. Einzustellen gibts da normalerweise nichts.

Falls der fglrx so frei war, dein System mit einer ungeeigneten /etc/X11/xorg.conf zuzumüllen, die vielleicht mal löschen/umbenennen.
Andernfalls mal /var/log/Xorg.0.log inspizieren, Zeilen mit (EE) sind schwerwiegende Fehler.

Crash Override

21.01.2015
Entweder, Kubuntu verarscht mich nach Strich und Faden, oder es ist xserver... jetzt hab ich (hatte gestern noch mit der Life - CD gearbeitet zwecks Datensicherung), nach einer Auswahl (ähnlich dem, wenn Windoof nen Bluescreen hatte und man in den abgesicherten Modus will) den Grafischen Login wieder.

Nun wirds interessant: zuerst passte beim Ladevorgang die Auflösung (geschätzte 1280 x 1024), etwa 2 Sekunden später wurde die wieder auf 800 x 600 reduziert. Zwar komm ich jetzt wieder überall dran, aber wieder wie schonmal passt die hälfte nicht. /var/log/Xorg.0.log will allerdings nicht. Ohne Sudo gibts keine Berechtigung, mit sudo su heissts "kein Passwortentrag". Wird also schwieriger was zu finden - ich bleib dran und schau, dass ich euch ne Logfile zukommen lass sobald es möglich ist.

Tante Edith sagt:

So. Nun wirds sehr Interessant: /etc/X11/xorg.conf Existiert nichtmal. Na dann...

404compliant

21.01.2015
(21.01.2015)Crash Override schrieb: [ -> ]So. Nun wirds sehr Interessant: /etc/X11/xorg.conf Existiert nichtmal. Na dann...

Ist ok, braucht man heutzutage normalerweise nicht mehr, so erledigt das der Autodetect. Bei fglrx und seiner gewachsenen Altlast-Struktur war ich nur nicht sicher, ob nicht irgend ein Konfig-Tool eine generiert hat, die dann das Laden anderer Treiber verhindert.

Crash Override

21.01.2015
So - nu weiß ich was los is. Funktionieren tut kein Treiber - weil die X1400 "zu alt ist". Ergo: Bis auf die standardtreiber geht nix. Daher ist auch kein fglrx installiert (egal wie ich es dennoch versuche). Heisst also: Meine T60 sind für Ubuntu zu alt, so dass ich die beiden gradewegs "entsorgen" kann... meh. Twilight: No, Really?

Werde dann wohl oder übel auf X201 & T400 umsteigen müssen, damit ich wenigstens noch unterstützung für die Grafikchips erhalte. So'n schiet...

404compliant

22.01.2015
(21.01.2015)Crash Override schrieb: [ -> ]So - nu weiß ich was los is. Funktionieren tut kein Treiber - weil die X1400 "zu alt ist".

Also das ist Quark. Die X1400 müsste zur Radeon R500 Serie gehören (RV515?), und wird selbstverständlich vom xorg radeon Treiber unterstützt. Mein Notebook hat auch nur einen RV530-Chip (aka. FireGL 5200), und funktioniert einwandfrei, inklusive 3D- und Video-Beschleunigung.

AMD's fglrx-Treiber gibt es dagegen schon seit 5 Jahren nicht mehr für den Chip.

Crash Override

22.01.2015
Ja, Rv515. Das Problem ist, dass ich auch woanders nachgefragt hatte - und dort eben die Antwort (und zu überzeugende antworten dahingehend) bekam.

Zwar sieht der Link hoffnungsbereitend aus - aber ganz ehrlich: Ich hab nicht den blassesten Schimmer was ich damit anfangen soll. Selbst unter "repo info" seh ich weder ne Installationsanleitung noch eine Repository, die ich per "sudo" anhängen kann. So schnell wie es für mich bergauf ging als ich das las - so schnell ging's auch wieder herab... Ich hab mich inzwischen zwar mit dem Terminal angefreundet (so oft wie ich da jetzt drin hing), aber dennoch bin ich bisher nicht wirklich viel weiter als am anfang...

Spoiler (Öffnen)

404compliant

22.01.2015
Bei mir – Debian, du weißt schon, die Distribution, bei der alles immer extra kompliziert ist – genügt es, xserver-xorg-video-all zu installieren (eventuell braucht er noch firmware-linux-free und/oder firmware-linux-nonfree), und danach funktioniert alles automatisch, kein gefrickel mit irgend welchen config-Programmen.

Wenn gar keine X-Oberfläche startet, gib uns mal die xorg.0.log, und eventuell die Ausgabe von dmesg oder dem syslog, falls es schon Fehler beim booten gibt.

Wenn X läuft, kann man noch mal nach OpenGL schauen. glxgears ausprobieren – bei mir glatt 60fps, glxinfo für Diagnoseausgaben, etc.

Was generell nicht besser werden kann: Der Chip kann nur OpenGL 2.1 , falls dein Programm mehr braucht, hast du pech.

EDIT:
Für 3D-Unterstützung brauchst du noch die DRM-Treiber, such mal nach libdrm-radeon, und die (OpenGL) Mesa GLX-Treiber. (libgl1-mesa-glx)
Nur für den Fall, dass deine fglrx-Versuche da ein paar Bibliotheken verdrängt haben.

Crash Override

22.01.2015
xorg.0.log existiert nicht. Ich bekomme da keine ausgabe von - hatte ich aber schonmal erwähnt...

Code:
crash@crash-ThinkPad-T60:~$ /var/log/Xorg.0.log
bash: /var/log/Xorg.0.log: Keine Berechtigung
crash@crash-ThinkPad-T60:~$

Mit sudo davor bringt's nix, weil er den Befehl nicht findet.

Beim Booten gibt's keine Fehler (mehr), aber ich denk mal, ich hab da was, was vielleicht interressant sein könnte:

Spoiler (Öffnen)


Hoffe mal, ihr könnt das finden, was ihr zu finden meint. Dmesg kommt im nächsten post - bin über die Zeichengrenze gekommen (knapp über 82.000 Zeichen - erlaubt sind max. 65.000 Zeichen...)

DrDerrek

22.01.2015
(22.01.2015)Crash Override schrieb: [ -> ]xorg.0.log existiert nicht. Ich bekomme da keine ausgabe von - hatte ich aber schonmal erwähnt...

Code:
crash@crash-ThinkPad-T60:~$ /var/log/Xorg.0.log
bash: /var/log/Xorg.0.log: Keine Berechtigung
crash@crash-ThinkPad-T60:~$

Das funktioniert eh nicht, da du ja irgendein Programm brauchst, welches dir die Logdatei anzeigst. Probier mal

Code:
vi  /var/log/Xorg.0.log

oder

Code:
cat  /var/log/Xorg.0.log

als root.

Ob die Datei wirklich existiert kannst du auch ohne Rootrechte mit folgendem Befehl sehen:

Code:
ls /var/log

Crash Override

22.01.2015
Hier der 2.te teil:

dmesg part 2 (Öffnen)

ls /var/log (Öffnen)

404compliant

22.01.2015
Ok, der Kernel-Teil der Grafiktreiber scheint schon mal korrekt zu initialisieren, damit müsste auch die Firmware vorhanden sein.

Die Xorg.0.log ist auch da, ist ja in der ls-Ausgabe aufgeführt. Nur wie schon geschrieben, das ist kein Programm, sondern eine Textdatei. Ich würde es mal mit sudo less /var/log/Xorg.0.log versuchen. Mit etwas Glück kannst du less auch durch gedit ersetzen, macht das Kopieren einfacher.

Crash Override

22.01.2015
Na dann...

/var/log/Xorg.0.log (Öffnen)

404compliant

23.01.2015
Hmmmm, sieht so aus, als würde kernel modesetting (KMS) nicht funktionieren, d.H. der Kernel kontrolliert nicht den Grafikmodus der Karte. Vor einigen Jahren ist die Zuständigkeit für den Wechsel des Grafikmodus vom X-Server zum Kernel umgezogen, seit dem bittet der Radeon-Treiber den Kernel um Hilfe beim Moduswechsel.
Der fglrx-Treiber unterstützt das bis heute nicht, weshalb er irgendwie dafür sorgt, dass KMS deaktiviert wird. Ich kann nur vermuten, dass irgend welche Reste des fglrx-Treibers immer noch verhindern, dass KMS aktiv ist, und dadurch auch den radeon-Treiber sabotieren.

Google findet spontan das:
https://wiki.ubuntu.com/X/Troubleshooting/VideoDriverDetection#Problem:_Need_to_purge_-fglrx
Das wäre mal einen Versuch wert.

Crash Override

23.01.2015
Code:
crash@crash-ThinkPad-T60:~$ dpkg --get-selections|grep libgl1-mesa
libgl1-mesa-dri:i386                            install
libgl1-mesa-glx:i386                            install
libgl1-mesa-glx-dbg:i386                        install
crash@crash-ThinkPad-T60:~$

Zumindest zeigt das die Überprüfung über dpkg. ich hoffe mal, dass dann alles richtig läuft - denn fglrx wollte er nicht de-installieren, da nix da war.

Code:
crash@crash-ThinkPad-T60:~$ sudo apt-get remove --purge xorg-driver-fglrx fglrx
[sudo] password for crash:
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.      
Statusinformationen werden eingelesen.... Fertig
E: Paket xorg-driver-fglrx kann nicht gefunden werden.
crash@crash-ThinkPad-T60:~$


Nach erfolgtem Restart (Merke: niemals neu starten, sondern immer herunterfahren und dann manuell starten, das fabriziert sonst nur unnötige verwirrung) sagt
sudo less /var/log/xorg.0.log (Öffnen)

404compliant

23.01.2015
Hast du den install- und den recofigure-Aufruf auch gemacht?

Code:
sudo apt-get install --reinstall libgl1-mesa-glx libgl1-mesa-dri xserver-xorg-core
sudo dpkg-reconfigure xserver-xorg
Multiarch scheinst du nicht zu haben, es bleibt also bei den einfachen Aufrufen.

Crash Override

23.01.2015
Hatte ich auch gemacht - schön schritt für schritt. Das, was "sudo less /var/log/Xorg.0.log" ausgegeben hat, war nach dem kompletten Prozedere und dem Neustart (bzw. den Neustarts, da beim einfachen restart die Usb-Anschlüsse nicht reagierten - und somit weder Maus, noch Trackpoint oder UMTS-Stick was getan hatten). Sozusagen ist dass das, was seit dem Neustart "funktioniert" (oder auch nicht).

404compliant

24.01.2015
Seltsam. Ich bleibe bei meiner Theorie, irgendwas verhindert, dass der Kernel die Grafikkarte übernimmt und per KMS steuert. Leider kenne ich das System nicht genug, um zu wissen, wie der fglrx-Treiber das in dem Fall bewerkstelligt.

Unter Debian legt der installierte radeon-Treiber unter /etc/modprobe.d/radeon-kms.conf eine Kerneloption ab, die modesetting für Radeon-Karten aktiviert. Ob es noch einen vergleichbaren, entgegen gesetzten Mechanismus gibt, den der fglrx verwendet, um sich durchzusetzen, weiß ich nicht.
Auch könnte der entsprechende Punkt, zu dem KMS sich abschaltet, schon in der init-ramdisk sein, dann müsste auch die regeneriert werden, um den Spuk zu beenden. Vielleicht steckt dort immer noch der fglrx-Kerneltreiber drin.

Schwer, irgend welche weiteren Tipps zu geben, ohne Zugriff auf das System, zumal ich nicht mal ein ähnliches Vergleichssystem hier habe.
Wird echt Zeit, dass der fglrx-Treiber eingestampft wird.

Maglor

25.01.2015
(24.01.2015)404compliant schrieb: [ -> ]Unter Debian legt der installierte radeon-Treiber unter /etc/modprobe.d/radeon-kms.conf eine Kerneloption ab, die modesetting für Radeon-Karten aktiviert. Ob es noch einen vergleichbaren, entgegen gesetzten Mechanismus gibt, den der fglrx verwendet, um sich durchzusetzen, weiß ich nicht.

Befindet sich ebenfalls in modprobe.d und nennt sich als Eintrag z.B. "blacklist radeon"
Meistens in der /etc/modprobe.de/modprobe.conf bzw /etc/modprobe.d/blacklist.conf zu finden.

Fest einschreiben würde der Philosophie und dem Grundgedanken widersprechen.
Dieses existiert schon seit geraumer Zeit nicht mehr für die externen Grafiktreiber.
Daher geht man dort den Weg des blacklistens. [Bild: 01-scootangel.png]
Bei unsauberen entfernen, passiert es häufig das ein blacklist Eintrag schlicht "vergessen" wird.
Einzig Matrox macht dieses noch für ihre Grafikkarten mit ~10-20 Anschlüssen. (Genutzt für Videleinwände)

Würde am liebsten paar Dinge mehr zur Problemlösung schreiben... jedoch muss ich erst den Thread durchlesen, sobald ich Zeit für finde [Bild: cl-sl-annoyed.png]

Crash Override

25.01.2015
Kein Problem, lass dir Zeit. Vielleicht kommt man so wieder nen schritt weiter.

404compliant

25.01.2015
Ein Modul-Blacklist könnte es vielleicht auch sein, die dmesg-Ausgabe sieht mir erst mal aber nicht so aus. Ein lsmod|grep radeon sollte es uns verraten.

Die Datei, die ich erwähnt habe, entspricht dem Kernel-Parameter radeon.modeset=1, unter Debian ist der Voraussetzung dafür, dass der xorg-Treiber läuft.

@Crash, mach doch auch mal ein sudo grep -r radeon /etc , vielleicht finden wir so irgend welche Hinweise.
Seiten: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
Bronies.de > Off-Topic > Internet & Technik > Von Windows auf Linux - die Umsteiger