Zurück zu X mit ALT-F7 --> FREEZE

[Sloop]

So, einen wunderschönen guten Sonntagabend mit'nander,

ich möchte momentan folgendes Problem angehen, es geht um folgendes. Ich starte den X, springe mit der Tastenkombi STRG+ALT+Fn zur Konsole zurück, sehe die laufenden letzten Nachrichten vom X-Server, und dann drücke ich ALT-F7, um zum X wieder zurückzuwechseln. Wenn das geklappt hat, dann wiederhole ich das, indem ich wieder STRG-ALT-Fn drücke.

Das Problem: sobald er zum X zurückspringt, sehe ich noch kurz den X, die Maus ist eingefroren und man kann nichts mehr tun. Um es ganz einfach zu gestalten: es hat nichts mit meinem DE zu tun, denn das gleiche kann ich jederzeit mit dem Starten von "X" reproduzieren. Dabei wird NUR der X-Server gestartet, kein Script, keine Zusatzprogramme, keine Desktop-Environments, oder irgendwelche Terminalkonsolen, usw... also nur X Wenn ich es überhaupt schaffe mit ALT+F7 zum X zurückzugelangen, dann schaff ichs mit einem erneuten STRG+ALT+Fn jedoch nicht mehr zur Konsole. Der Rechner scheint abzustürzen, der Bildschirm stellt sich ab, als ob er kein Signal kriegt.
Das komische ist, ich kann mich mit ssh remote einloggen und selbst wenn ich den X prozess kille mit kill -9 kill -15 oder was auch immer ich probiert habe, der Prozess bleibt aktiv. So als ob er wirklich komplett irgendwie eingefroren wäre.

Ich konnte durch Ausprobieren feststellen, dass es wohl wieder etwas mit der Acceleration zu tun hat, oder irgendetwas was damit zu tun hat. Wenn ich den treiber auf "Vesa" in der xorg.conf stelle, dann kann ich beliebig oft Hin- und Herschalten. Wenn ich meinen normalen "radeon"Treiber wähle, und NoAccel auf True setze, dann funktioniert das auch beliebig oft. Sobald ich aber NoAccel auf False setze (quasi der default-Zustand) kommt es zum genannten Problem. Ich habe aus diesem Grunde sämtliche Varianten durchprobiert, die mit Acceleration zu tun haben, dazu zählen die radoen-Einstellungen:

Option "RenderAccel" "true"("false")
Option "AccelMethod" "XAA"("EXA"
Option "DepthBits" "16"
Option "FBTexPercent" "50" (0, 25,60,90,100)
Option "AccelDFS" "false" (true)

Ich hab natürlich schon einige Sachen ausprobiert, jedoch noch nicht zu einem Ergebnis gekommen. Ich dachte mal, ich frag wieder hier rein, ob einer eine Idee hätte, womit das evtl. zusammenhängen könnte. Was ist anders, wenn Acceleration genutzt wird ?

Wenn jemand was weiß, bin ich gerne wie immer ganz Ohr und sehr dankbar.

Ist zwar kein weltbewegendes "Problem", reizt mich aber trotzdem das herauszukriegen und zu beheben

Grüße,
Sloop.

 

[pit234a]

Soll ich meine Sturheit beweisen?

Zunächst, die Frage des passenden Treibers, die du nicht angesprochen hast. Es gibt scheinbar einen neuen Port, x...ati613 und das probiere ich bei mir selbst gerade mal aus.
Damit ist die Anzahl an möglichen Treibern für deine radeonhd nochmal gestiegen.
Hast du alle ausprobiert?

Viel einfacher scheint mir das mit HAL zu sein.
Benenne mal deine xorg.conf um und aktiviere HAL und dbus und versuch es mal damit.
Nicht, dass damit alles immer funktioniert!
Aber, das startet den X-Server (wenn nötig) mehrmals und probiert verschiedene Settings und wohl auch Treiber (die dann natürlich installiert sein müssen) und entscheidet automagisch und trifft bei mir in immerhin 4 von 5 Fällen wirklich gute Entscheidungen.
Die xorg.0.log gibt dann auch häufig gute Hinweise auf mögliche Fehlerquellen.

Bei mir selbst sieht es allerdings gerade ähnlich aus, wie du es beschreibst.
Nachdem ich mal etwas aufräumen wollte, habe ich doch etwas exzessiv gelöscht und nahezu mein komplettes System deinstalliert, was dazu führte, dass ich nun sehr Vieles wieder reinstallieren musste und ich hänge damit an manchen Stellen noch ein wenig. Klar, manche Ungereimtheiten sind nicht so dringend und andere zeigen sich erst nach einiger Zeit.

Komisch ist aber, dass ziemlich genau das von dir beschriebene Verhalten NUN auftritt, während es vorher von mir nicht bemerkt wurde. Außerdem funktioniert Copy_n_Paste über X nicht mehr so, wie zuvor. Deshalb halte ich das für ein Problem, das durch meinen "neuen ati-Treiber" verursacht wird und habe es erst mal nach hinten verschoben. Andere Dinge sind mir erst mal wichtiger.

Zusammen mit deinem Thread, ergeben sich natürlich auch andere Deutungsmöglichkeiten.

Wie gesagt, mir bleibt noch ausreichend anderes zu reparieren und vielleicht findest du inzwischen die Lösung für mich. Hilfreich kann das sein, was ich dir beschrieb, aber es muss nicht sein.

 

[Sloop]

Hi pit,

[...]Wenn ich meinen normalen "radeon"Treiber wähle, und ...

hast es wohl überlesen. Ich hatte natürlich den radeon Treiber verwendet, denn der radeonhd sollte nicht verwendet werden, weil er schon viel älter ist.

Hal läuft bei mir, brauchte das für meine Maus.

Und wie um alles in der Welt kommst du auf den ati613? Das ist die Version 6.13.2.
Der xf86-video-ati ist hingegen Version 6.14.3

Ich würde doch fast sagen, der xf86-video-ati ist also dein Freund

Grüße,
Sloop.

 

[pit234a]

Hi pit,


hast es wohl überlesen. Ich hatte natürlich den radeon Treiber verwendet, denn der radeonhd sollte nicht verwendet werden, weil er schon viel älter ist.

Hal läuft bei mir, brauchte das für meine Maus.

Und wie um alles in der Welt kommst du auf den ati613? Das ist die Version 6.13.2.
Der xf86-video-ati ist hingegen Version 6.14.3

Ich würde doch fast sagen, der xf86-video-ati ist also dein Freund

Grüße,
Sloop.

Ah, guter Hinweis!
Wie gesagt, ich hatte bisher noch keine Zeit darauf verschwendet und den 613er einfach aus Neugierde mal genommen, weil er mir bisher nie aufgefallen war. Hätte er gar nicht funktioniert, hätte ich gleich anders weiter gemacht. So ließ ich es erst mal dabei und machte sonstwo weiter und zwar auch nicht gleich mit übergroßem Eifer, weil ich so in mir irgendwie auch dachte, vielleicht mal vollkommen neu zu starten. Mein System auf diesem PC erhalte ich nun seit irgendeiner 6er Version und wollte es auf 8.3 stehen lassen, Weil vermeintlich alles damit lief, was ich wollte. Nun bin ich leicht verunsichert und weiß noch nicht, wohin ich gehen werde. Ich arbeite auch nicht so intensiv daran, wie früher.

Aber zurück zu deinem derzeitigen Problem.
Es kann also gut sein, dass wir nicht das gleiche Problem gemeinsam haben und meines sich sehr einfach erledigen wird.
Das ist dann gut.
Dann ist es kein allgemeiner Fehler, über den man stolpern muss.

Was die Sache mit dem HAL und so anbelangt, glaube ich (aus Beobachtung, nicht, weil ich es weiß), dass die automatische Konfiguration mit HAL treffender ist, als die automatische Konfiguration durch X -configure. Deshalb erwähne ich das dauernd, weil ich es einen Versuch für Wert halte.
Vielleicht bringt es dir gar nichts oder zeigt sich noch schlimmer, als du es jetzt erlebst. Aber, wenn du es versucht hast, wissen wir es wenigstens ganz genau.
Wie schon gesagt, auch bei mir habe ich damit durchaus nicht durchgehend Erfolg gehabt, aber immerhin doch so häufig, dass es mir eine wirkliche Alternative zu Testzwecken ist.

Ich halte das Problem, das du schilderst, für ein Treiberproblem und für ein Problem mit deiner Maus zusammen mit X.
Normalerweise braucht eine Maus keinen Hal, wenn sie richtig erkannt und mit Treibern versehen ist. Meine Maus ist eine USB und die geht auch auf der Konsole mit moused und ich brauche den für X nicht zu deaktivieren.
HAL hatte aber letztlich Mist gemacht und genau auch den Mauszeiger einfrieren lassen. Da half es, Hal für die Maus auszuschließen und diese ausdrücklich in der xorg-conf zu etablieren. Den betreffenden Thread hatten wir vor wenigen Wochen hier und Yamagi gab da den entscheidenden Rat. Das kann sicher leicht gefunden werden. Wenn nicht, kann ich demnächst genauer nachsehen.

 

[Yamagi]

Der Konsolenwechsel funktioniert grob gesagt so, dass die GPU all ihre derzeit vorhandenen Daten in RAM zurückgibt und in einen jungfräulichen Zustand zurückspringt. Wechselt man dann zurück ins X11, werden die Daten aus dem RAM erneut auf die GPU übertragen. Die meisten Probleme mit dem Konsolenwechsel entstehen bei diesen Übertragungen. Klappt der Wechsel in die Konsole nicht, wird die GPU nicht sauber zurückgesetzt. Kommt man nicht wieder ins X11 zurück, wurden meist erst gar nicht alle Daten gesichert. Daran sind fast immer Treiberprobleme schuld. Auch bei dir spricht viel dafür: Ohne Beschleunigung geht es. Mit Beschleunigung werden mehr Register genutzt, zumindest ein Teil dieser wird nicht gesichert und *kabumm*.

Wenn ich dir einen Tipp geben darf: Du sagtest mal, dass in der Kiste eine alte ATI R600 (HD/X2000 Serie) steckt. Das Ding ist inzwischen restlos veraltet und unter FreeBSD ist der Treibersupport diplomatisch ausgedrückt sehr ausbaufähig. Ja, ich war mal sehr begeistert von der Idee freier Treiber, aber ich wurde bitter enttäuscht. Selbst unter Linux sind die freien ATI-Treiber eine mittlere Katastrophe. Und während unter Linux das Powermanagement inzwischen wenigstens in Ansätzen funktioniert, ist unter FreeBSD davon nichts zu sehen. Die Karte läuft immer unter Volllast, ist laut, frisst Strom ohne Ende und grillt sich dabei langsam zu Tode. Wenn das mit FreeBSD eine längere Beziehung werden soll, tue dir selbst den Gefallen und kaufe dir die kleinste Nvidia-Karte. Die gibt es passiv gekühlt für 30 bis 40 Euro, sie hat perfekte Treiberunterstützung, du bekommst Videobeschleunigung und spart große Mengen Strom.

 

[Sloop]

Hi Yamagi,

genau dieser Eindruck wurde mir über die ATI-Karten in Zusammenhang mit BSD erweckt, als ich viele Beiträge in diversen Foren las. Das einfachste wird wirklich eine neue nVidia sein, aber gut. So eilig und dringend ist das nicht, und dazulernen tue ich ja jeden Tag damit

Danke für dein feedback.