Ach, es ist doch zum Kotzen ... da pfrickelt man um den einen Bug herum und stolpert gleich in den nächsten ...
Warum deine Tastatur so langsam ist, steht in den Xorg.log-Dateien:
Xorg.0.log hat geschrieben:[ 16.327] (EE) AIGLX error: r200 does not export required DRI extension
[ 16.327] (EE) AIGLX: reverting to software rendering
[ 17.167] (II) AIGLX: Loaded and initialized swrast
[ 17.167] (II) GLX: Initialized DRISWRAST GL provider for screen 0
Xorg.0.log.old hat geschrieben:[ 933.315] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 933.315] (II) AIGLX: enabled GLX_INTEL_swap_event
[ 933.315] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[ 933.315] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[ 933.315] (II) AIGLX: Loaded and initialized r200
[ 933.315] (II) GLX: Initialized DRI2 GL provider for screen 0
Der radeon.modeset=0-Parameter schaltet also jegliche Hardware-Beschleunigung aus, dein Prozessor muss jeden einzelnen Pixel per Hand berechnen, darum fühlt sich das so träge an.
Zur Erklärung: Früher lief der Grafikkartentreiber im "UMS"-Modus (Userspace Mode Setting), und genau den haben wir mit radeon.modeset=0 wieder eingeschaltet. Mit UMS konnte jeder Grafiktreiber sein eigenes Süppchen kochen, der Kernel hatte keine Ahnung, wie der Treiber funktioniert und konnte so die Auflösung auch nicht selber ändern - darum hast du diese große Schrift auf der Konsole - das ist die UMS-Auflösung. Inzwischen haben sie auf "KMS" (Kernelbased Mode Setting) umgestellt, der Kernel kann also inzwischen dem Grafikkartentreiber sagen, was er machen soll. Gleichzeitig haben sie von der Hardwarebeschleunigung "DRI" auf "DRI2" umgestellt ... der liebe Fortschritt. Im UMS-Modus kann der radeon-Treiber kein DRI2, der Rest des Grafiksystems erwartet aber inzwischen DRI2, darum schaltet der Treiber auf "software rendering" um, lässt also den Prozessor alles berechnen.
Die Zukunft lautet also "KMS" ... und wie ich gerade gelesen habe, soll die UMS-Unterstützung ab Kernel 3.9 ganz rausfliegen. Darum haben sie sich auch keine Mühe mehr mit DRI2 unter UMS gegeben.
Der handfeste Bug ist also nach wie vor, dass das mit dem Aufwachen nach dem Suspend nicht klappt ... das wussten wir aber schon vorher.
Der übliche Trick bei alten ATI-Karten soll hier sein, sie vom AGP- in den PCI-Modus zu schalten, oder zumindest vom AGP4x-Modus in den AGP1x-Modus.
Ich dachte, das hätten wir mit "radeon.agpmode=-1" schon ausprobiert, aber wenn ich mir die manpage vom aktuellen radeon-Treiber so angucke ("man radeon"), dann ist der Wert "-1" eh nicht bekannt, und "agpmode" versteht er nur, wenn UMS ausgewählt ist ... wir brauchen aber KMS.
Darum probiere bitte noch mal folgende zwei Sachen:
1) Den Kernel-Parameter
Und danach ein
Im Moment erscheint da unter anderem folgende Zeile:
dmesg hat geschrieben:[ 15.551512] agpgart-nvidia 0000:00:00.0: putting AGP V2 device into 4x mode
Und wir wollen das "4x mode" weg bekommen.
Mit agp=off schaltest du (hoffentlich) den AGP-Steckplatz zurück auf PCI-Geschwindigkeit ... das ist zwar nicht so toll, aber wenn es damit geht, sind wir auf der richtigen Spur.
2) Wenn das geht, müssen wir den AGP-Steckplatz irgendwie auf 1x Geschwindigkeit zwingen, und ich weiß nicht, wie das gehen soll.
Die beste Methode führt über das BIOS ... da gibt es häufig eine Einstellung für den AGP-Bus, bei der man zwischen 1x, 2x und 4x auswählen kann. Schau mal, ob du da was findest.
Sonst wäre der Kernel-Parameter "radeon.agpmode=1" noch einen Versuch wert.
ludger hat geschrieben:Das habe ich nicht verstanden, was ich da machen soll? Kannst Du das bitte noch mal erklären, ich steh gerade auf der Leitung ...! Dankeschön!
Eins nach dem anderen ... wenn wir das Suspend nicht zum Laufen bekommen, müssen wir das dem XFCE eh noch abgewöhnen.
Was ich übrigens noch nie gesehen habe, ist diese Fehlermeldung:
dmesg hat geschrieben:[ 2115.752006] floppy driver state
[ 2115.752008] -------------------
[ 2115.752032] now=453938 last interrupt=4294892629 diff=528605 last called handler=reset_interrupt
[ 2115.752034] timeout_message=lock fdc
[ 2115.752036] last output bytes:
[ 2115.752038] 8 80 4294892615
[ 2115.752040] 8 80 4294892615
[ 2115.752042] 8 80 4294892615
[ 2115.752044] 8 80 4294892625
[ 2115.752046] 8 80 4294892625
[ 2115.752048] 8 80 4294892625
[ 2115.752049] 8 80 4294892625
[ 2115.752051] e 80 4294892626
[ 2115.752053] 13 80 4294892626
[ 2115.752055] 0 90 4294892626
[ 2115.752057] 1a 90 4294892626
[ 2115.752059] 0 90 4294892626
[ 2115.752061] 12 90 4294892626
[ 2115.752063] 0 90 4294892626
[ 2115.752064] 14 90 4294892626
[ 2115.752066] 18 80 4294892626
[ 2115.752068] 8 80 4294892629
[ 2115.752070] 8 80 4294892629
[ 2115.752072] 8 80 4294892629
[ 2115.752074] 8 80 4294892629
[ 2115.752075] last result at 4294892629
[ 2115.752077] last redo_fd_request at 4294892629
[ 2115.752085] status=0
[ 2115.752086] fdc_busy=1
[ 2115.752091] do_floppy=reset_interrupt
[ 2115.752093] cont=f83ed254
[ 2115.752095] current_req= (null)
[ 2115.752096] command_status=-1
[ 2115.752098]
[ 2115.752101] floppy0: floppy timeout called
Und sie scheint verdammt selten zu sein ... ich gratuliere!
Ich habe keine Hinweise gefunden, dass sie weitere Probleme verursacht, außer dass das Diskettenlaufwerk nicht mehr funktioniert. Falls du keins mehr hast oder es eh nicht mehr benutzt, schalte es doch trotzdem einfach im BIOS aus.
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001