URL: https://www.overclockers.at/linux/designed-in-china-lemote-yeeloong-loongson-2f-risc_225942/page_2 - zur Vollversion wechseln!
Ja, leck! Ein echter Failkauf...
Ich kanns ja mal mit "NoDRI" versuchen in der Xorg Config?Zitat von MarcellusDer software rasterizer ist aber mist, an deiner stelle würd ich dri gleich abdrehen, dann verschenkst du wenigstens nicht die cpu leistung beim herumschieben von Fenstern.
Ich hab mir bei weitem ned alles durchgelesen, aber irgendwie sieht das für mich eher mühsam als spaßig aus!
Trotzdem viel Erfolg! Ich drück dir die Daumen!
"NoAccel" ist die option für dich.
Ok, hab nur gelesen, daß NoAccel nicht das DRI, sondern nur die Acceleration ausschaltet, daher hab ich's ned probiert.
Werd ich morgen mal testen, hab die Maschine grade ned bei mir.
Edit: So, getestet, leider keine Besserung. Fensterschupfen kostet immer noch massiv CPU, visuell ist vom Speed her kein Unterschied festzustellen..
Doublepost ftw.!
Es gab ja einen Haufen X11/Gnome Apps, die alle mit SIGBUS vom Kernel gekillt wurden (Bus Error), weil sie einen unaligned Memory Access verzapft haben, Speicherzugriffe müssen hier ja 8-byte-aligned sein. Das lag aber ned direkt an den Apps selbst, sondern an einer common Library, gegen die sie alle gelinked waren (Ein freundlicher User auf VA hat mich drauf gebracht, daß es an einer shared lib liegen könnte!). Und so ist es auch, der Verbrecher war libXi6, und dafür gibts einen Patchvorschlag, der zwar noch nicht durchgegangen ist, aber probieren geht über studieren? Also den Sourcecode von libXi6 gezogen, und folgenden Patch manuell im C Code vorgenommen:
Code:apt-get source libxi6
Dann das übliche:Code:Index: libxi-1.4.3/src/XExtInt.c =================================================================== --- libxi-1.4.3.orig/src/XExtInt.c 2011-08-07 02:46:36.164701285 +0200 +++ libxi-1.4.3/src/XExtInt.c 2011-08-07 02:37:50.808340152 +0200 @@ -1435,7 +1435,7 @@ break; } - len += l; + len = ((len + 7) & -8) + l; ptr_wire += any_wire->length * 4; } @@ -1467,6 +1467,7 @@ for (i = 0; i < nclasses; i++) { + ptr_lib = (void*)(((size_t)ptr_lib + 7) & -8); any_lib = (XIAnyClassInfo*)ptr_lib; any_wire = (xXIAnyInfo*)ptr_wire;
Danach die Libs einfach über die bestehenden drüberkopiert (vorher backupped, eh klar), und BÄM!! gnome-terminal geht, Epiphany geht, alles was mit Bus Error krachen gegangen ist, läuft jetzt! So herrlich!!!Code:export CFLAGS="-march=loongson2f -mtune=loongson2f" export CXXFLAGS="-march=loongson2f -mtune=loongson2f" ./configure make
So, habe es geschafft, Truecrypt 7.1 zu bauen im Debian. Wieder Mal mit -O3. Funktioniert sogar sauber mit ntfs-3g zusammen, jetzt kann ich meine im Windows XP erzeugten Truecryptvolumes mit NTFS sauber einhängen am kleinen RISC (hab da so eine USB HDD).
Der Benchmark hier zeigt gleich Mal, wo's lang geht!
Er is so geil ultralahm...
wie schaut der benchmark ohne verschlüsselung aus?
Ich hab mit dd Mal auf der Disk rumgetestet (lineares Lesen und Schreiben mit 1MB Blockgröße auf EXT4, sync), und das Resultat ist ernüchternd.
17MB/s lesen
13MB/s schreiben
Dafür habe ich den Systemkern ausgetauscht, jetzt: linux-libre-3.0.4 von [gNewSense für Lemote]. Der Kern soll wesentlich kompatibler sein, heißt es. Und najo. Er IST es auch. Jetzt funktioniert das Akkumanagement, die Sensoren können alle ausgelesen werden (CPU Temp, Akkutemp, Lüfterdrehzahl), und die Webcam tut!
also performance ist ja echt bescheiden - hoff da tut sich noch ein wenig
Warum nicht gleich gNewSense drauf?
Weil ich schon einen riesen Haufen Arbeit investiert habe, damit das System läuft (WOCHEN!), jetzt geh ichs sicher ned wieder runterreißen. Vor allem deswegen nicht, weil der Kern im Debian eh läuft.
Never change a running system.
Zudem hab ich kA was fürn Software Repo gNewSense hat, bei Debian weiß ich, daß es gut is, sogar für mipsel.
Edit: Yay!
Manuelle Lüftersteuerung aktivieren:
Level einstellen [0|1|2|3]:Code:echo 1 > /sys/class/hwmon/hwmon0/pwm1_enable
Levels:Code:echo 3 > /sys/class/hwmon/hwmon0/pwm1
Zitat von GrandAdmiralThrawnIch hab mit dd Mal auf der Disk rumgetestet (lineares Lesen und Schreiben mit 1MB Blockgröße auf EXT4, sync), und das Resultat ist ernüchternd.
17MB/s lesen
13MB/s schreiben
Mit einem flotten Quad schaffst so um die 300-600MB/s je nach OC. Mein 4GHz Hexcore (980X) schafft ~500MB/s ohne AES-NI, und 4000-5000MB/s mit AES-NI Hardwarebeschleunigung...
Hier ein Vergleichsshot von meiner i7 980X Workstation, wie gesagt 4GHz, hier mit AES-NI, selbe Puffergröße:
Wennst AES-NI außen vor gelassen sehen willst, kannst ja hier z.B. die Twofish Werte vergleichen...
Puh, das AES-NI ist wirklich schnell…
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2024