X-Server wird wegen zu wenig RAM anscheinend rausgekickt

C

cabriofahrer

Well-Known Member
Wollte mal ausprobieren, was mit FreeBSD auf einer alten Mühle spielemäßig noch geht:
MSI-Board mit Intel-BX-Chipsatz, 128 MB RAM, PII 400 Mhz, ATI All in Wonder Radeon.
FreeBSD zunächst mit Xorg 6.9, dann mit Xorg 7.2, beide Male funktioniert die 3D-Beschleunigung, hier die Erfahrungen:

Quake3 (pkg_add -r quake3) und Quake2 mit wine (was auf meinem Hauptrechner tadellos funktioniert).

Sowohl auf xorg 6.9 als auch auf xorg 7.2 startet Q3 zwar, doch irgendwann wird der X-server gekillt, man befindet sich wieder in der Konsole. Unter xorg 6.9 wurde das Intro sehr langsam und stotternd wiedergegeben (2-D), das Hauptmenü war sehr schwer und langsam zu bedienen (3-D), doch es war manchmal möglich, eine Karte zu laden, man konnte sich erstaunlich schnell bewegen. Doch bald letztendlich Absturz vom X-server. Einmal sogar Freeze. Q2 mit wine ging nur einmal ganz kurz (wenn überhaupt) mit 3-D, dann auch Absturz oder gar Freeze.
Mit xorg 7.2 war bei Q3 das Intro tadellos flüssig, auch die Menüführung ging einwandfrei, doch eine Karte konnte nicht geladen werden, sofort Absturz des X-Servers, also wieder draußen in der Konsole. Q2 mit Wine ging auch nicht, X-Server auch gekillt, aber wenigstens keine Freezes mehr, wie bei xorg 6.9.

Was sonst noch auffiel: Verschiedene AGP Aperture Sizes im BIOS eingestellt: 8, 16, 32, 64 MB. Bei 8 MB gibt es gar keine 3D-Beschleunigung, erst ab 16.

Wiegesagt, nur 128 MB Ram, das hätte aber unter Win98 allemal ausgereicht, um Q3 laufen zu lassen.

Was ich hier vermute: Wenn zuwenig Spiecher, dann scheint FreeBSD den X-Server einfach rauszukicken, das dürfte eigentlich nicht sein, oder? Was ist denn mit Swapping?
Müßte nicht alles, was nicht mehr in den RAM paßt, ausgelagert werden, also zur Not auch der X-Server? Oder gibt es vielleicht einen Trick, FreeBSD mitzuteilen, den X-Server unter allen Umständen im Hauptspeicher zu behalten?
 
Hast du irgendwo eine drirc, dass führt bei einigen Radeon Karten (bei meinen zum Beispiel) zu abstürzen. Bei einer Karte nur mit bestimmten Einträgen, bei einer anderen reicht das bloße Vorhandensein der Datei.

In der Q3 Konsole solltest du dir den Parameter com_hunkmegs ansehen und eventuell verringern. Stell auch mal niedrig aufgelöste Texturen ein.

Ansonsten werden Prozesse nur getötet, wenn der Swap ausgeht. Wie viel Swap hast du denn?
 
Nun, das sollte wirklich reichen. Drirc ist eine Konfigurationsdatei in der du einige Einstellungen vornehmen kannst (wie TCL abschalten, VSYNC abschalten/erzwingen, usw...). Außerdem kann man dort hyperz aktivieren, was bisher große Performancesprünge gebracht hat. Aber seit Xorg 7.2 bringt das auf einer meiner Karten Grafikfehler und die andere veraursacht eine Panic, wenn die drirc nur existiert. Vollkommen egal, was drin steht.
 
Wieso eigentlich Q2 und Q3 in Wine? Die sollten doch auch mittlerweile als Sourceports auf FreeBSD angekommen sein. ;)
 
Stimmt. Lesen müsste ich können. Nun, bleibt noch Q2. Zumindest Freshports listet eine riesige Menge möglicher Ports. Eventuell lässt es sich ja dann damit vernünftig spielen. Ich habe damals(tm) die Original-Portierung für Linux auf einem 400 Mhz Kiste im Softwaremodus gespielt und es lief... gut. :)
 
Also wenn eine drirc (und wo soll die liegen?) nicht automatisch erstellt wird, dann habe ich wahrscheinlich keine. Und ob es irgendwelche Ports zu Q2 gibt oder nicht, ist für die Frage hier irrelevant, genauso wie "Softwaremodus". Auf einer ausreichend ausgestatteten Maschine laufen Q2 und andere OpenGL-Spiele tadellos im 3D-Modus unter wine.
Die Frage war ursprünglich doch auch, ob möglicherweise FreeBSD bei zuwenig RAM den X-Server rauskickt, vielleicht versucht, auszulagern oder sonst wie, und ob man das vielleicht verhindern kann? Als Fehlermeldung vom X-Server erscheint manchmal so was wie "Connection lost". Könnte man da vielleicht eine Priorität für den X-Server einstellen, daß der auf jeden Fall im RAM bleiben soll?
 
Bei RAM-Mangel wid immer der Prozeß mit dem größten RAM-Verbrauch gekickt. Das steht dann auch ziemlich explizit in /var/log/messages oder auf der Systemkonsole. Außerdem würdest du das bei 1024 MB Swap auch ganz deutlich merken, denn die Festplatte rödelt sich dabei fast zu Tode.

Du kannst natürlich die RAM-Nutzung auch wie folgt überwachen:
Code: 
while true
do
  echo -e "$(date)\n$(top -b | grep "^Mem: \|^Swap: ")\n" >> mem-usage
  sleep 1
done
Dann siehst du ganz genau, wie sich der Speicherverbrauch entwickelt. Bis jetzt ist das ja reine Spekulation.
 
0815Chaot schrieb:
Bei RAM-Mangel wid immer der Prozeß mit dem größten RAM-Verbrauch gekickt. Das steht dann auch ziemlich explizit in /var/log/messages oder auf der Systemkonsole. Außerdem würdest du das bei 1024 MB Swap auch ganz deutlich merken, denn die Festplatte rödelt sich dabei fast zu Tode.
Zum Vergrößern anklicken....

OK, heißt das, daß bei 128 MB RAM eine Swap von 1024 MB eine so schlechte Konfiguration darstellt, daß diese eventuell dafür verantwortlich ist, weil die Festplatte zuviel rödelt?
Welche Größe ist dann für die Swap empfehlenswert? 2-fach oder 3-fach? Es müßte ja schon genug Platz da sein für Q3.
Und (wie) kann ich die Swap verkleinern, ohne die Root-Partition zu zerschießen?
Geht das auch mit sysinstall?
 
Die Swap zu verkleinern geht mit ein wenig Fingerspitzengefühl mit bsdlabel(8) und hinterher growfs(8) auf die davor liegende Partition...
 
cabriofahrer schrieb:
OK, heißt das, daß bei 128 MB RAM eine Swap von 1024 MB eine so schlechte Konfiguration darstellt, daß diese eventuell dafür verantwortlich ist, weil die Festplatte zuviel rödelt?
Welche Größe ist dann für die Swap empfehlenswert? 2-fach oder 3-fach? Es müßte ja schon genug Platz da sein für Q3.
Zum Vergrößern anklicken....
Was ist denn das jetzt für eine abstruse Milchmädchenrechnung? Falls (!) dein X-Server aufgrund von Speichermangel abgeschossen werden sollte, dann wirst du das Problem durch Verkleinerung des Swaps nur noch verschärfen. Außerdem kannst du Speicher für aktive Anwendungen wie Q3 nicht durch Swap bereitstellen. Theoretisch natürlich schon, aber in der Praxis wirst du damit erst recht nicht auf eine brauchbare Performance kommen.

Das sind aber alles nur reine Spekulationen. Du solltest lieber die Fakten liefern, nämlich die tatsächliche Entwicklung der Speicherauslastung deines Systems. Dann sieht man doch gleich, ob du tatsächlich ein Speicherproblem hast. Falls ja, brauchst du auch nicht weniger Swap oder ähnliche Placebo-Maßnahmen, sondern schlicht und ergreifend mehr RAM.

Es steht allerdings auch weiterhin die Möglichkeit im Raum, daß der X-Server aufgrund eines Konfigurationsproblems oder eines Bugs abraucht. Dann bringt es natürlich erst recht nichts, wenn man am Swap rumfummelt und sich vielleicht am Ende sogar noch die Partitionstabelle zerschossen hat.
 
64 MB Ram sollten für Quake 3 reichen, ich glaube also nicht an ein Speicherproblem.
 
Also ich habe das Problem zum Teil gefunden, ich glaube, hier liegt ein Hardwarefehler vor:
Es gibt wohl ein Problem mit der Soundblaster Live! im Zusammenhang mit dem alten Mainboard. Wenn man den Eintrag für die Soundblaster in der /boot/loader.conf entfernt und neu startet, schmiert Q3 zumindest nicht sofort ab, sondern kann lange stabil laufen. Unter FreeBSD läuft überhaupt keine Soundanwendung (noch nicht einmal xmms) mit dieser Hardwarekombination. Dennoch stürtzt Q3 dann bei höherer Auflösung (1024x768), 32 bit und höchsten Details irgendwann ab. Wahrscheinlich ist das Board einfach nur Schrott, andererseits weiß man ja auch nicht, wie gut die Xorg-Unterstützung für die ATI-Karten wirklich ist.
Ich danke Euch wirklich für Eure Bemühungen, ich bin selbst wirklich nicht drauf gekommen, daß die Kombination Board/Soundkarte zumindest ein Teil des Problems war.
Sollte ja alles auch nur ein Experiment mit alter Hardware sein.
 
Wenn du es doch nochmal versuchen möchtest:

Hast du evtl. mal Ram/HDD/Burnintest laufen lassen? Laufen alle lüfter / wird irgendwas heiss?

Evtl. mal Bios-Update gemacht oder an den Optionen da rumgefummelt?
 
CommanderZed schrieb:
Wenn du es doch nochmal versuchen möchtest:

Hast du evtl. mal Ram/HDD/Burnintest laufen lassen? Laufen alle lüfter / wird irgendwas heiss?

Evtl. mal Bios-Update gemacht oder an den Optionen da rumgefummelt?
Zum Vergrößern anklicken....

Also heiß läuft nichts. Und wie mache ich die Ram/HDD/Burnintests? Was ist überhaupt ein Burnintest? Die Lüfter laufen, es läuft auch nichts heiß, das ist sicher nicht das Problem, dafür sind die Abstürze zu prompt un zu vorhersehbar.
Am BIOS habe ich viel rumgemacht, bei einigen AGP-Aperture-Sizes geht manchmal gar nichts. Möglicherweise sind aber durch die zahlreichen Abstürze auch schon Dateien beschädigt worden.
 
Also für einen Memory-Test bietet sich z.B. http://www.memtest86.com/

um die Festplatte Low-Level zu testen gibt es von den meisten herstellern ensprechende Tools ...

Ich selbst verwende die tools von

http://www.toolhouse.de/

die allerdings Geld kosten.

Ein BurnIn test ist ein Test der meist auswählbare Komponenten für eine einstellbare zeit unter dauerlast stellt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben