Stotternde Maus unter FreeBSD 7.0: Die Lösung

Yamagi

Yamagi

Possessed With Psi Powers
Teammitglied
So Jungs,
ich habe eine gute Nachricht für euch. Man hat das Problem mit der ruckelnden Maus unter FreeBSD 7.0 soweit analysiert, dass es einen ersten Satz Patches gibt. Das Problem liegt nicht an FreeBSD, sondern an X.org. Und zwar tritt X.org seit einiger Zeit unter FreeBSD eine Flut von teuren gettimeofday() Syscalls los, welche durch ihre schiere Menge das System aus dem Tritt bringen können, wenn dies nicht genug Power hat. Die Lösung ist simpel:

Code: 
-------------- next part --------------
--- configure.orig	2008-02-28 16:08:55.000000000 -0500
+++ configure	2008-02-28 16:11:19.000000000 -0500
@@ -30376,7 +30376,7 @@
 else
   cat >conftest.$ac_ext <<_ACEOF
 
-#define _POSIX_C_SOURCE 199309L
+#define _POSIX_C_SOURCE 200112L
 #include <time.h>
 
 int main(int argc, char *argv[]) {
--- configure.ac.orig	2007-09-06 01:59:00.000000000 -0400
+++ configure.ac	2008-02-28 16:11:23.000000000 -0500
@@ -1055,7 +1055,7 @@
     LIBS="$CLOCK_LIBS"
 
     AC_RUN_IFELSE([
-#define _POSIX_C_SOURCE 199309L
+#define _POSIX_C_SOURCE 200112L
 #include <time.h>
 
 int main(int argc, char *argv[[]]) {
-------------- next part --------------
--- os/utils.c.orig	2007-08-23 15:04:55.000000000 -0400
+++ os/utils.c	2008-02-28 16:20:29.000000000 -0500
@@ -525,7 +525,11 @@
 
 #ifdef MONOTONIC_CLOCK
     struct timespec tp;
+#ifdef __FreeBSD__
+    if (clock_gettime(CLOCK_MONOTONIC_FAST, &tp) == 0)
+#else
     if (clock_gettime(CLOCK_MONOTONIC, &tp) == 0)
+#endif
         return (tp.tv_sec * 1000) + (tp.tv_nsec / 1000000L);
 #endif
Ihr kopiert obrigen Diff in eine Textdatei und kopiert diese (als root) in /usr/port/x11-servers/xorg-server/files. Anschließend baut ihr den Port neu. Das Problem sollte dann verschwunden sein.
Natürlich wird dieser manuelle Eingriff überflüssig, sobald der Patch in den Port eingegangen ist. Bis dahin hefte ich diesen Thread oben an.

EDIT: Ich wurde gerade darauf hingewiesen, dass die Datei mit dem Patch mit dem Namen "patch-" beginnen muss. Man nennt sie also am besten patch-jerkymouse oder so. Ach ja, danke an Tron für den Hinweis.

EDIT2: Den Patch noch mal als Anhang
 

Anhänge

Zuletzt bearbeitet:
Hab's auch gerade gelesen und bin am xorg-server neu kompilieren.

Hast du das schon ausprobiert?
 
Bei mir hilft der Patch gar nicht. Das System hängt immer noch komplett, so lang die Maus nicht in Bewegung ist. Nur der Verzicht auf moused hilft.
 
Soweit ich weiß muss die Datei einen gewissen Prefix "patch" haben damit der auch angewendet wird. Hast du das gemacht?

Ich finde es immer noch interessant das ich dieses Problem gar nicht habe, mit oder ohne Patch. O.o
 
Auf meinem neuen System habe ich das Problem auch nicht. Dennoch ruckelt meine TV-Karte wie wild. Da das Problem nur beim NVidia-Treiber (nicht beim vesa) auftritt, vermute ich die Ursache irgendwo in Grafiknähe. Daher bin ich Xorg-Bugs gegenüber auch nicht ganz abgeneigt.

Kann man jemand kurz reflektieren, was "gettimeofday() Syscalls" genau macht und warum es ausgerechnet nur die Maus zu ruckeln bringt? Könnte mein Problem auch damit zusammenhängen? Sobald die Kiste wieder 'frei' ist, teste ich den Patch trotzdem :)
 
Ich verstehe unter BSD-Feeling for allem die Trennung in Basissystem und Paketsystem (inklusive eigenem etc/) und das NetBSD-rc. Das SysV Init geht mir total auf die Nerven, wenn ich etwas mit Linux machen muss.
 
Steve` schrieb:
Dennoch ruckelt meine TV-Karte wie wild. Da das Problem nur beim NVidia-Treiber (nicht beim vesa) auftritt, vermute ich die Ursache irgendwo in Grafiknähe. Daher bin ich Xorg-Bugs gegenüber auch nicht ganz abgeneigt.
Zum Vergrößern anklicken....
Tja, leider nicht. Hab den Patch eingespielt, keine Veränderung. Egal, einen Versuch war es wert.
 
Hä, ich hab nicht genau verstanden, ob das jetzt ein allgemeiner Patch ist oder nur für Leute mit Problemen. Ich hab hier zwei Kisten mit fbsd7 und moused.... da ruckelt nichts...
Oder ist dadurch auch allgemein die performance beeinträchtigt?

edit: was damit nicht so viel zu tun haben wird, aber wenn ich irgendwas auf ner virtuellen Konsole mache, wie z.B. pfeilnachlinks drücken obwohl man schon "ganz links" ist in der Eingabe, fängt die Musik an zu stottern und alles andere wird langsam. Das einfache einloggen in der Konsole bringt schon einen kleinen Aussetzer...
 
Das geht weg, wenn du die Konsole im Standardmodus 80x25 fährst. Etzend, aber es hilft.

Steve` schrieb:
Tja, leider nicht. Hab den Patch eingespielt, keine Veränderung. Egal, einen Versuch war es wert.
Zum Vergrößern anklicken....
Hängt deine Maus, oder hängt dein X? Ich habe letzteres Problem und bin auf der ML anscheinend der Einzige. Etwas Schützenhilfe wäre da echt hilfreich.
 
Weder noch. Bei mir hängt (ruckelt) das TV-Bild im 95%-Idle. Mit vesa ist es flüssig, mit NVidia ruckelt es wie Sau. Compiz dagegen läuft superflüssig.
 
Also noch einmal zur ursprünglichen Problem: Xorg tritt seit einiger Zeit, mindestens seit Version 1.2 des Servers, bei jeder Bewegung der Maus den Syscall gettimeofday() los. Dieser holt direkt vom Kernel die genaue Uhrzeit. Nun sind Syscalls allerdings recht teuer, und gettimeofday() besonders, da der Kernel erst aus der direkten Uhrzeit und einer ermittelten Standardabweichung die Zeit berechnet. Der Patch macht nun nichts anderes, als das dem Syscall ein anderer Parameter übergeben wird, wodurch dessen Ergebnis ungenauer wird, allerdings auch deutlich günstiger. Der Patch hat keine negativen Auswirkungen und schaden tut er sicherlich nicht, von daher spricht nichts dagegen ihn anzuwenden.
 
Rennt prima mit dem patch-jerkymouse

Hallo Yamagi,

dankeschön für den patch-jerkymouse,
fühlt sich unter Vollast beim compilern
mit dem patch-jerkymouse geschmeidiger an,
das FreeBSD Desktop (KDE).

Prima! Klasse Patch! :)


Gruß, Fusselbär
 
Der Patch ist nicht auf meinen Mist gewachsen, Jung-uk Kim. Ich habe ihn nur aus freebsd-stable@ hierher kopiert :)
 
Moin,

mit GENERIC gab es mit dem Patch keine Veränderung. Erst nachdem ich SCHED_ULE aktiviert habe, kann ich auf dem System wieder arbeiten während ich kompiliere etc.

Derzeit zieht es noch xine in die Knie, den Port werde ich aber mal neu bauen. Denn (g)mplayer hat keine Probleme in dieser Richtung.

Gruß
 
Da der Patch nun schon seit dem sechsten März im Port enthalten ist, lasse ich das Thema mal nach unten runterrutschen.
 
Auch für mein Problem habe ich inzwischen eine Lösung gefunden.

Ich schiebe das Problem auf den GCC, der hat ja öfter mal 'nen Bug. Erst gestern habe ich ein Programm für einen Atmel 90-Controller compiliert und der GCC hat aus folgender Zeile eine Endlosschleife gebaut:

Code: 
REGISTER |= (1 << BITPOS);

Die Variablennamen sind geändert, denn ich habe sie nicht im Kopf. Aber das Problem ging weg nachdem ich von -O0 auf -O2 umgestellt habe.
 
Ich habe hier xorg-server-1.4_8,1 installiert und das Problem tritt bei mir dennoch auf, sobald ich portupgrade(sobald er anfängt zu kompilieren) aufrufe fängt alles an zu ruckeln.

Dies war früher definitiv(vor 7.0) nicht der Fall. Könnte es noch an etwas anderem liegen?
 
Das liegt daran, dass das VFS noch im Giant-Lock ist. Normalerweise tritt das nur merklich auf, wenn du make -j mit mehr Prozessen als CPU-Kernen aufrufst. Die Verwendung von ULE verbessert die Situation auch etwas.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben