Probleme mit VESA [solved]

Kamikaze

Warrior of Sunlight
Teammitglied
Inzwischen gibt es eine bessere Lösung, weiter geht es hier:
Probleme mit VESA [solved]
-----
Seit dem letzten großen Update aus den Ports auf Xorg 7.7 und e19 habe ich zahlreiche Probleme.

e19 reagierte erst mal deutlich flinker als e17, sehr schick.

Leider gab es zahlreiche Probleme:
- Häufige Freezes oder Panics
- Flash geht nicht mehr
- Starkes Ruckeln in Anwendungen, etwa beim Scrollen von Firefox
- Unerträgliche Video-Performance
- Hohe CPU Last durch Xorg
- Träges Terminal, selbst ohne Load

Zumindest die Performance-Probleme sind jetzt gelöst. Videos laufen ohne Tearing, Flash geht, Firefox scrollt wieder ordentlich und rxvt-unicode läuft auch flüssig. Die Lösung war die ShadowFB Option des VESA-Treiber abzuschalten.

Dazu habe ich die Datei /usr/local/etc/X11/xorg.conf.d/vesa.conf angelegt:
Code:
Section "Device"
	Identifier "vesa0"
	Driver     "vesa"
	Option     "ShadowFB" "Off"
EndSection

Nach einem Neustart von X kann man überprüfen ob die Option greift:
Code:
# grep -i shadowfb /var/log/Xorg.0.log
[   876.263] (**) VESA(0): Option "ShadowFB" "Off"
 
Zuletzt bearbeitet:
Heißt das, ich könnte auf mein Haswell-Notebook (mit Intel HD 4x00 - oder HD5x00) das Display über den VESA-Treiber mit 1600x900 ansteuern und ohne "Ruckeln" arbeiten?
Spielen tu ich nicht, aber etwas Transparenz, ruckelfreies Verschieben von Fenstern und ggf. Abspielen von Internet-Videos würde gehen?

Danke und Gruß
Markus
 
Bei mir geht das jetzt (1920x1080).

Nur der Maus-Cursor flackert mit der Konfiguration. Aber das kann ich so verschmerzen.

[edit]
Bei Flash muss ich inzwischen Einschränkungen machen. Das geht nicht so toll. Dafür läuft HTML5 passabel.
 
Ok, dann werd ich es die Tage einfach mal probieren.

Hast du ein Tipp, wie ich bei der Einrichtung von VESA für Haswell vorgehe? Analog Handbuch?

Gruß
Markus
 
@Kamikaze: Kannst du sagen ob der E16 artige "Live Modus" des Desktop Pagers funktioniert? Also ich meine den Modus mit der echten Miniaturansicht des Desktops, keine wie auch immer geartete Abstraktion mit Fensterumrissen und Symbolen wie man es von vielen anderen Pagern kennt ...
 
Hast du ein Tipp, wie ich bei der Einrichtung von VESA für Haswell vorgehe? Analog Handbuch?
Dafür musst Du nichts tun. Die Config musst Du überhaupt nur anlegen, damit Du die ShadowFB Option abschalten kannst.

@Kamikaze: Kannst du sagen ob der E16 artige "Live Modus" des Desktop Pagers funktioniert? Also ich meine den Modus mit der echten Miniaturansicht des Desktops, keine wie auch immer geartete Abstraktion mit Fensterumrissen und Symbolen wie man es von vielen anderen Pagern kennt ...
Ja, das funktioniert. Der Default-Pager in e19 macht das so. Mir geht das auf dem Senkel, deswegen verwende ich den Simple Pager. Zum Wechsel einfach das eine Modul entladen und das andere laden.
 
Mit den letzten Xorg Updates war die unterirdische Performance wieder da. Doch in den FreeBSD Foren gibt es Abhilfe:
https://forums.freebsd.org/threads/xorg-vesa-driver-massive-speedup-using-mtrr-write-combine.46723/

Dazu habe ich noch eine Anmerkung. Da ich inzwischen per EFI boote verwende ich scfb, nicht mehr VESA. Wie sich herausstellt greift das aber auch hier.

Beim Speicher habe ich die Werte nicht mit vidcontrol ermittelt (geht mit vt nicht) sondern aus dmesg:
Code:
# dmesg|grep vga
vgapci0: <VGA-compatible display> port 0xf000-0xf03f mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff at device 2.0 on pci0
vgapci0: Boot video device

In meinem Fall habe ich also write-combine für den Speicherbereich 0xe0000000-0xefffffff aktiviert.

Code:
memcontrol set -b 0xe0000000 -l 0x10000000 -o BIOS write-combine

In einer perfekten Welt, wäre damit die Sache erledigt. Leider hat sich memcontrol aber geweigert. Das Kommando memcontrol list zeigte dann auch schnell warum. Der gesamte Anfangsbereich des Speichers war als write-back gekennzeichnet, das ist inkompatibel mit write-combine.

Wenn man den Eintrag löscht wird die Maschine sehr langsam. Deswegen sollte man von Anfang an seine Experimente in einem Skript machen, das man dann halt ausführt. Wenn es nicht klappt ist oft die einfachste Möglichkeit wieder zu einem performanten System zu kommen den Ausschalter zu drücken und 15 Minuten zu warten bis das System heruntergefahren ist.

Damit das ganze funktioniert muss man also überlagernde Einträge mit memcontrol clear löschen. Dann muss man den Eintrag als Serie neuer Einträge umsetzen, die den Zustand für allen Speicher um den Grafikspeicher herum wieder herstellt. Dabei muss man beachten das die Länge von Speicherbereichen immer eine 2er-Potenz sein muss. Das heißt also die Länge besteht aus einer Hex-Zahl, die nur eine Ziffer ungleich Null aus der Menge [1, 2, 4, 8] erhält.

Das resultierende Skript sieht bei mir dann so aus:
Code:
#!/bin/sh -f

#
# Set write-back for memory surrounding video memory
#

# Clear the great write-back block
memcontrol clear -b 0x0 -l 0x400000000
# Write-back in front of video memory
memcontrol set -b 0x0 -l 0x80000000 -o BIOS write-back
memcontrol set -b 0x80000000 -l 0x40000000 -o BIOS write-back
memcontrol set -b 0xc0000000 -l 0x20000000 -o BIOS write-back
# Write-back behind video memory
memcontrol set -b 0x100000000 -l 0x100000000 -o BIOS write-back
memcontrol set -b 0x200000000 -l 0x200000000 -o BIOS write-back

# VESA memory, yay!
memcontrol clear -b 0xe0000000 -l 0x20000000
memcontrol set -b 0xe0000000 -l 0x10000000 -o BIOS write-combine
memcontrol set -b 0xf0000000 -l 0x10000000 -o BIOS uncacheable
memcontrol set -b 0xf0000000 -l 0x10000000 -o BIOS write-back
 
  • Like
Reaktionen: lme
Tut auf jeden Fall Wunder für die Laufzeit. Und der Lüfter ist auch nicht mehr ständig am plärren.

Nur mit ACPI spielt das nicht so schön. Damit der Shutdown funktioniert habe ich auch eine undo-Variante, die den Ursprungszustand wieder herstellt. Das Problem ist hier wahrscheinlich, dass die Tabelle nicht genug Plätze hat um nur den Grafikspeicher auf write-combine zu stellen. Ich muss eine doppelt so große Menge Speicher verwenden.
 
Zurück
Oben