SuSE stürzt ständig ab
Hi! Ich habe im Moment ein sehr nerviges Problem: mein Linux stürzt richtig ab (ja, genau wie Windows, nur BlueScreen gibt's keinen, Linux stirbt leise). :-( Wann? Ich schreibe grade einen kleinen Raytracer, der auf einem Rechner gleicher Hardware +/- RAM fehlerfrei läuft. Das ganze unter C++. Wer sowas noch nicht gemacht hat: mehr oder weniger sind das zwei for-schleifen, in denen Berechnungen ausgeführt werden. Das ganze läuft 400x300 mal, also 120000 Ausführungen der inneren Schleife. Jetzt zum Problem: nach ca 300x3 Ausführungen wird es bei mir dunkel, umschalten auf Konsole geht nicht mehr (anpingen kann man ihn vielleicht noch, habe hier aber nur einen Rechner stehen). Das passiert sogar, nachdem ich alles mit OpenGL und den Bibliotheken der GUI, die ich verwende, rausgeschmissen habe, also nur noch ein reines "Rechenprogramm" laufen lasse. Bis hierhin passiert auch noch nichts wildes in der Szene (Hintergrundfarbe), also die wilden Berechnungen starten noch nicht. Der Fehler tritt auch nicht immer an der gleichen Stelle des Programms auf, sondern nach einer gewissen Anzahl von Schleifendurchläufen, den Speicher habe ich inzwischen auch statisch zugeteilt, STL wird auch nicht mehr benutzt. Ach ja, zu Tode swappen kann man auch ausschließen, der swap bleibt schön leer. Zum System: SuSE 7.2, Kernel 2.4.4, Nvidia-GK (akt. Treiber, 3D und alles läuft), 256 MB RAM, XFree 4.0.3 switch2mesasoft ausgeführt Das ist alles bis auf die Distri identisch mit dem Rechner, auf dem ich den Kram zum Laufen kriege (RedHat). Ich linke sogar gegen die gleichen Bibliotheks-Versionen. Da ich aber im Moment wirklich nur Berechnungen laufen lasse (keine Speicherzugriffsfehler, RAM-Speicher habe ich schon mittels MEMTest gecheckt) wollte ich mal fragen, ob a) schon mal jemand ähnliche Probleme hatte? b) jemand eine Idee hat, woran das liegen könnte? Kann das am Kernel liegen??? Ich bräuchte den 3D-Beschleunigungs-Kram nicht, Tips, wie ich ein mega-stabiles System hinkriege, wären mir super-recht (mesasoft reicht). Linux ständig rebooten hinterläßt ein komisches Gefühl beim Arbeiten...um eine Neuinstallation würde ich mich gerne drücken, mal abgesehen davon, daß das wohl nix bringt, denn alle Einstallungen, die was mit Grafik zu tun haben sind eh' "Standard". CU und danke Martin
On Mon, 8 Oct 2001, Martin Oehler wrote:
Hi!
Ich habe im Moment ein sehr nerviges Problem: mein Linux stürzt richtig ab (ja, genau wie Windows, nur BlueScreen gibt's keinen, Linux stirbt leise). :-(
Wann? Ich schreibe grade einen kleinen Raytracer, der auf einem Rechner gleicher Hardware +/- RAM fehlerfrei läuft. Das ganze unter C++. Wer sowas noch nicht gemacht hat: mehr oder weniger sind das zwei for-schleifen, in denen Berechnungen ausgeführt werden. Das ganze läuft 400x300 mal, also 120000 Ausführungen der inneren Schleife.
Jetzt zum Problem: nach ca 300x3 Ausführungen wird es bei Hi Martin, was machst Du denn in der inneren Schleife? Allokierst Du vielleicht zuviel speicher? Hast Du das Programm auf beiden Systemen mit dem gleichen Compiler übersetzt?
Gruß, Sven ------------------------------------------------------- Sven Bergner E-Mail: bergner@fh-worms.de Live long and prosper! Registered Linux-User #65111 -------------------------------------------------------
Hi! Sven Bergner wrote:
On Mon, 8 Oct 2001, Martin Oehler wrote:
Wann? Ich schreibe grade einen kleinen Raytracer, der auf einem Rechner gleicher Hardware +/- RAM fehlerfrei läuft. Das ganze unter C++. Wer sowas noch nicht gemacht hat: mehr oder weniger sind das zwei for-schleifen, in denen Berechnungen ausgeführt werden. Das ganze läuft 400x300 mal, also 120000 Ausführungen der inneren Schleife.
Jetzt zum Problem: nach ca 300x3 Ausführungen wird es bei
was machst Du denn in der inneren Schleife? Allokierst Du vielleicht zuviel speicher? Hast Du das Programm auf beiden Systemen mit dem gleichen Compiler übersetzt?
Nein, die Triangulierungs-Daten werden in statische Arrays eingelesen und in der inneren Schleife läuft nix außer eher langweiliger Vektor-Arithmetik. Einige Arrays vom Typ double werden angelegt. Jegliche dynamische Speicherallokierung habe ich inzwischen rausgeschmissen und habe immer noch die selben Probleme. Ich habe auch mal einen kleineren Abschnitt der Szene geladen, das gab das gleiche Problem. Wenn ich das im ddd laufen lasse, reist es den mit runter und zwar ohne daß er mir irgendwelche Fehler ausspuckt (bevor er stirbt). Ja, ich habe den gleichen Compiler: gcc version 2.95.3 20010315 (SuSE) Äh, auf dem anderen Rechner halt ohne das (SuSE) hintendran, aber das sollte wohl keinen Unterschied machen. CU Martin
Martin Oehler wrote:
Wann? Ich schreibe grade einen kleinen Raytracer, der auf einem Rechner gleicher Hardware +/- RAM fehlerfrei läuft. Das ganze unter C++. Wer sowas noch nicht gemacht hat: mehr oder weniger sind das zwei for-schleifen, in denen Berechnungen ausgeführt werden. Das ganze läuft 400x300 mal, also 120000 Ausführungen der inneren Schleife.
Ahhh, da schlaegt mein Geophysiker-Herz hoeher.... :-) RayTracer brauchen wir hier auch ziemlich oft, wenn auch vielleicht nicht genau die gleichen wie Du sie einsetzt.
Jetzt zum Problem: nach ca 300x3 Ausführungen wird es bei mir dunkel, umschalten auf Konsole geht nicht mehr (anpingen kann man ihn vielleicht noch, habe hier aber nur einen Rechner stehen). [...] Der Fehler tritt auch nicht immer an der gleichen Stelle des Programms auf, sondern nach einer gewissen Anzahl von Schleifendurchläufen, den Speicher habe ich inzwischen auch statisch zugeteilt, STL wird auch nicht mehr benutzt. Ach ja, zu Tode swappen kann man auch ausschließen, der swap bleibt schön leer.
Du arbeitest nicht zufaellig mit Pointern oder aehnlichem? Damit kann man boese Dinge anstellen.... Du allokierst nicht zufaellig zu viel Speicher irgendwo? Dir laeuft nicht zufaellig eine Schleifenvariable aus dem Ruder? Mit C++ kann man auch ganz nett auf Feldelemente zugreifen, die gar nicht wirklich existieren (Fortran faengt so etwas IIRC ab, bei C++ ist dafuer der Programmierer selbst verantwort- lich). Wir entwickeln hier ein Migrationsprogramm in C++, da gab es auch zu Beginn merkwuerdige Abstuerze.... Hast Du das Programm schon mal "debuggt"? Auf Linux ist da ddd sehr zu empfehlen, ein Frontend fuer gdb. Prinzipiell koennte es schon etwas mit der Kernel-Version zu tun haben, evtl. bist Du da auf einen Bug gestossen..... Gruesse, Th. -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Hi! Thomas Hertweck wrote:
Martin Oehler wrote:
Wann? Ich schreibe grade einen kleinen Raytracer, der auf einem Rechner gleicher Hardware +/- RAM fehlerfrei läuft. Das ganze unter C++. Wer sowas noch nicht gemacht hat: mehr oder weniger sind das zwei for-schleifen, in denen Berechnungen ausgeführt werden. Das ganze läuft 400x300 mal, also 120000 Ausführungen der inneren Schleife.
Ahhh, da schlaegt mein Geophysiker-Herz hoeher.... :-) RayTracer brauchen wir hier auch ziemlich oft, wenn auch vielleicht nicht genau die gleichen wie Du sie einsetzt.
Hehe, wenn Du wüßtest...
Der Fehler tritt auch nicht immer an der gleichen Stelle des Programms auf, sondern nach einer gewissen Anzahl von Schleifendurchläufen, den Speicher habe ich inzwischen auch statisch zugeteilt, STL wird auch nicht mehr benutzt. Ach ja, zu Tode swappen kann man auch ausschließen, der swap bleibt schön leer.
Du arbeitest nicht zufaellig mit Pointern oder aehnlichem?
Inzwischen nicht mehr, der Schnittpunkttest wird sauber ausgeführt, die Intensitäten sauber berechnet. Abschnittsweise läuft das alles in Ordnung durch, halt aber nicht insgesamt.
Damit kann man boese Dinge anstellen.... Du allokierst nicht zufaellig zu viel Speicher irgendwo? Dir laeuft nicht zufaellig eine Schleifenvariable aus dem Ruder?
Die letzte Meldung meines "cout-debugging" ist die Ausgabe der Durchlauf-Variablen (jaja, alles mit endl hintendran), eine erste Meldung aus der Funktion kriege ich nicht mehr (cout << "foo" << endl; bevor irgendwas berechnet wird).
Mit C++ kann man auch ganz nett auf Feldelemente zugreifen, die gar nicht wirklich existieren (Fortran faengt so etwas IIRC ab, bei C++ ist dafuer der Programmierer selbst verantwort- lich). Wir entwickeln hier ein Migrationsprogramm in C++, da gab es auch zu Beginn merkwuerdige Abstuerze.... Hast Du das Programm schon mal "debuggt"? Auf Linux ist da ddd sehr zu empfehlen, ein Frontend fuer gdb.
Siehe meine andere mail, ddd hilft nix, bevor ich was sehe, wird's dunkel.
Prinzipiell koennte es schon etwas mit der Kernel-Version zu tun haben, evtl. bist Du da auf einen Bug gestossen.....
Was nun? Neuen Kernel? Wenn ja, welchen? (SuSE bietet als update den 2.4.7 an, oder soll ich einen von Kernel.org nehmen) CU und danke Martin
Am Montag, 8. Oktober 2001 16:23 schrieb Martin Oehler:
Hi!
Thomas Hertweck wrote:
Martin Oehler wrote:
Wann? Ich schreibe grade einen kleinen Raytracer, der auf einem Rechner gleicher Hardware +/- RAM fehlerfrei läuft. Das ganze unter C++. Wer sowas noch nicht gemacht hat: mehr oder weniger sind das zwei for-schleifen, in denen Berechnungen ausgeführt werden. Das ganze läuft 400x300 mal, also 120000 Ausführungen der inneren Schleife.
Ahhh, da schlaegt mein Geophysiker-Herz hoeher.... :-) RayTracer brauchen wir hier auch ziemlich oft, wenn auch vielleicht nicht genau die gleichen wie Du sie einsetzt.
Hehe, wenn Du wüßtest...
Der Fehler tritt auch nicht immer an der gleichen Stelle des Programms auf, sondern nach einer gewissen Anzahl von Schleifendurchläufen, den Speicher habe ich inzwischen auch statisch zugeteilt, STL wird auch nicht mehr benutzt. Ach ja, zu Tode swappen kann man auch ausschließen, der swap bleibt schön leer.
Du arbeitest nicht zufaellig mit Pointern oder aehnlichem?
Inzwischen nicht mehr, der Schnittpunkttest wird sauber ausgeführt, die Intensitäten sauber berechnet. Abschnittsweise läuft das alles in Ordnung durch, halt aber nicht insgesamt.
Damit kann man boese Dinge anstellen.... Du allokierst nicht zufaellig zu viel Speicher irgendwo? Dir laeuft nicht zufaellig eine Schleifenvariable aus dem Ruder?
Die letzte Meldung meines "cout-debugging" ist die Ausgabe der Durchlauf-Variablen (jaja, alles mit endl hintendran), eine erste Meldung aus der Funktion kriege ich nicht mehr (cout << "foo" << endl; bevor irgendwas berechnet wird).
Mit C++ kann man auch ganz nett auf Feldelemente zugreifen, die gar nicht wirklich existieren (Fortran faengt so etwas IIRC ab, bei C++ ist dafuer der Programmierer selbst verantwort- lich). Wir entwickeln hier ein Migrationsprogramm in C++, da gab es auch zu Beginn merkwuerdige Abstuerze.... Hast Du das Programm schon mal "debuggt"? Auf Linux ist da ddd sehr zu empfehlen, ein Frontend fuer gdb.
Siehe meine andere mail, ddd hilft nix, bevor ich was sehe, wird's dunkel.
Prinzipiell koennte es schon etwas mit der Kernel-Version zu tun haben, evtl. bist Du da auf einen Bug gestossen.....
Was nun? Neuen Kernel? Wenn ja, welchen? (SuSE bietet als update den 2.4.7 an, oder soll ich einen von Kernel.org nehmen)
Der 2.4.7-SuSE hat mir auf einem Laptop ne Menge Ärger gemacht. Versuchs mit 2.4.10 vanilla oder nimm den 2.4.10-SuSE7 aus Hubert Mantels FTP-Verzeichnis Robert
CU und danke Martin
-- Where do you want to be tomorrow? Entracom. Building Linux systems. http://www.entracom.de
Hallo! Robert Szentmihalyi wrote:
Am Montag, 8. Oktober 2001 16:23 schrieb Martin Oehler:
Was nun? Neuen Kernel? Wenn ja, welchen? (SuSE bietet als update den 2.4.7 an, oder soll ich einen von Kernel.org nehmen)
Der 2.4.7-SuSE hat mir auf einem Laptop ne Menge Ärger gemacht. Versuchs mit 2.4.10 vanilla oder nimm den 2.4.10-SuSE7 aus Hubert Mantels FTP-Verzeichnis
So wie ich das sehe, läuft wohl alles auf ein Kernel-Update hinaus. Hmmm, ich weiß nicht, ob der Vanilla meinen Promise-IDE-Controller mag...ich versuche mal den von Mantel. CU Martin
Am Montag, 8. Oktober 2001 16:48 schrieb Martin Oehler:
Hallo!
Robert Szentmihalyi wrote:
Am Montag, 8. Oktober 2001 16:23 schrieb Martin Oehler:
Was nun? Neuen Kernel? Wenn ja, welchen? (SuSE bietet als update den 2.4.7 an, oder soll ich einen von Kernel.org nehmen)
Der 2.4.7-SuSE hat mir auf einem Laptop ne Menge Ärger gemacht. Versuchs mit 2.4.10 vanilla oder nimm den 2.4.10-SuSE7 aus Hubert Mantels FTP-Verzeichnis
So wie ich das sehe, läuft wohl alles auf ein Kernel-Update hinaus. Hmmm, ich weiß nicht, ob der Vanilla meinen Promise-IDE-Controller mag...ich versuche mal den von Mantel.
Es gab ein großes Hickhack zwischen Andre Hedrick und einigen Promise-Jungs, aber die Promise-Treiber sind definitiv im 2.4.10 vanilla enthalten.
CU Martin
-- Where do you want to be tomorrow? Entracom. Building Linux systems. http://www.entracom.de
Robert Szentmihalyi wrote:
Am Montag, 8. Oktober 2001 16:48 schrieb Martin Oehler:
Hallo!
[schnipp]
So wie ich das sehe, läuft wohl alles auf ein Kernel-Update hinaus. Hmmm, ich weiß nicht, ob der Vanilla meinen Promise-IDE-Controller mag...ich versuche mal den von Mantel.
Es gab ein großes Hickhack zwischen Andre Hedrick und einigen Promise-Jungs, aber die Promise-Treiber sind definitiv im 2.4.10 vanilla enthalten.
Das waren sie auch schon in 2.4.4. Nur hat dort der Hardware-Raid nicht funktioniert. Der soll angeblich mittlerweile im 2.4.10 laufen, aber mangels 2. Festplatte konnte ich es noch nicht selbst ausprobieren. Zum eigentlichen Problem: SuSE hängt sich auf... Da kann ich nur sagen, daß es bei mir leider auch ab und zu ohne erkennbaren Grund hängen bleibt, was aber IMHO and den NVIDIA Treibern liegt. Ich habe allerdings den Verdacht, daß es in direktem Zusammenhang mit dem Suspend-Modus für den Monitor hängt. Solange ich am Computer arbeite, passiert nichts. Nur wenn ich ihn mal für ein paar Minuten alleine lasse, ist er mir schon des öfteren hängen geblieben. Mittlerweile habe ich den Suspend-Modus im Bios ausgeschaltet.
CU Martin
MfG Rene
Hi Rene On Mon, Oct 08, 2001 at 11:04:02PM +0200, Rene Broichmann wrote:
Das waren sie auch schon in 2.4.4. Nur hat dort der Hardware-Raid nicht funktioniert. Der soll angeblich mittlerweile im 2.4.10 laufen, aber mangels 2. Festplatte konnte ich es noch nicht selbst ausprobieren.
Es ist kein Hardware RAID und es wird auch keins, es ist bestenfalls Softraid mit marginaler Unterstützung durch den Chip. Wobei selbst die deutlich aufwändigeren 3ware Raids mit einem sehr viel höheren Unterstützungsgrad durch die HW je nach RAID Level deutlich CPU Leistung verbraten. Der Traum vom IDE HW-RAID darf weiter geträumt werden, HW-RAID mit deutlichem Performance Gewinn selbst bei R5 gibts leider nur bei SCSI für das entspr. Geld. -- MfG. Falk
Am Montag, 8. Oktober 2001 23:04 schrieb Rene Broichmann:
Robert Szentmihalyi wrote:
Am Montag, 8. Oktober 2001 16:48 schrieb Martin Oehler:
Hallo!
[schnipp]
So wie ich das sehe, läuft wohl alles auf ein Kernel-Update hinaus. Hmmm, ich weiß nicht, ob der Vanilla meinen Promise-IDE-Controller mag...ich versuche mal den von Mantel.
Es gab ein großes Hickhack zwischen Andre Hedrick und einigen Promise-Jungs, aber die Promise-Treiber sind definitiv im 2.4.10 vanilla enthalten.
Das waren sie auch schon in 2.4.4. Nur hat dort der Hardware-Raid
stimmt.
nicht funktioniert. Der soll angeblich mittlerweile im 2.4.10 laufen, aber mangels 2. Festplatte konnte ich es noch nicht selbst ausprobieren.
Ja, tut es.
Zum eigentlichen Problem: SuSE hängt sich auf...
Da kann ich nur sagen, daß es bei mir leider auch ab und zu ohne erkennbaren Grund hängen bleibt, was aber IMHO and den NVIDIA Treibern liegt. Ich habe allerdings den Verdacht, daß es in direktem Zusammenhang mit dem Suspend-Modus für den Monitor hängt. Solange ich am Computer arbeite, passiert nichts. Nur wenn ich ihn mal für ein paar Minuten alleine lasse, ist er mir schon des öfteren hängen geblieben. Mittlerweile habe ich den Suspend-Modus im Bios ausgeschaltet.
CU Martin
MfG
Rene
-- Where do you want to be tomorrow? Entracom. Building Linux systems. http://www.entracom.de
Hallo! Rene Broichmann wrote:
Robert Szentmihalyi wrote: Zum eigentlichen Problem: SuSE hängt sich auf...
Da kann ich nur sagen, daß es bei mir leider auch ab und zu ohne erkennbaren Grund hängen bleibt, was aber IMHO and den NVIDIA Treibern liegt. Ich habe allerdings den Verdacht, daß es in direktem Zusammenhang mit dem Suspend-Modus für den Monitor hängt. Solange ich am Computer arbeite, passiert nichts. Nur wenn ich ihn mal für ein paar Minuten alleine lasse, ist er mir schon des öfteren hängen geblieben. Mittlerweile habe ich den Suspend-Modus im Bios ausgeschaltet.
Also, das kann ich jetzt nach einigen Versuchen nicht bestätigen. Folgendes ist bei mir inzwischen geschehen: 1) Kernelupdate: Ich habe so sauber wie es in meiner Macht stand (und unter Beachtung von DHallers Multikernel-Homepage :-) alle vorgeschlagenen Kernel ausprobiert. Am weitesten bin ich mit dem "offiziellen" Update für die 7.2 auf 2.4.7 gekommen (hat die meisten Iterationen ge- halten). Stürzt aber trotzdem noch ab. Den 2.4.10 von Mantel hat mein System gar nicht gemocht (Tastatur blinkt wie wild, alles piepst, hängt beim booten). Da das Problem immer noch da ist, vermute ich mal, kann man den Kernel ausschließen (2.2.19 habe ich aus lauter Verzweiflung auch versucht, brachte nichts). 2) nochmal Memtest: Hier habe ich den extra-gründlichen Test gefahren, keine Probleme mit dem RAM. Danach ist jedoch meine Netzwerkkarte gestorben (nie wieder billige Netzwerkkarten :-( ). 3) Deinstallation von NVidia-Kerneltreibern und -GLX: Habe alles ordentlich runtergeschmissen und den Open-Source-Treiber genommen (NV). Alles auf Software-Rendering, brachte nichts. 4) XFree auf 4.1.0 upgedatet: Null Effekt. Die neuere Version vom Sax2 ist ganz nett. 5) Alles von USB auf PS/2-Betrieb umgestellt: Na ja, der Teufel ist ein Eichhörnchen... So sehr ich mich bemüht habe, mein System auf low-level-Betrieb umzustellen und ja nicht viele Module zu laden (Soundkarte deinstalliert...), möglichst konventionelle X-Server zu benutzen, es bleibt immer noch stehen. Das einzige, was sich wirklich geändert hat, ist, daß der Screen dabei nicht mehr schwarz wird. Das oben mit dem Monitor habe ich auch schon versucht (gute Idee), aber in meinem BIOS ist auch alles exotische inzwischen draußen. Das ist übrigens kein generelles Problem, ich habe hier ein Projekt aus ca. 200 Klassen durchkompiliert, ohne daß es Probleme gibt (nix offizielles, auch noch mit Bugs). Hat jemand noch eine Idee? Gibt es irgendwo RPM's zu anderen gcc/g++-Versionen für die SuSE oder kann ich nur die Versionen von der gcc-Homepage benutzen? CU Martin
Am Montag, 8. Oktober 2001 15:49 schrieb Martin Oehler:
Hi!
Ich habe im Moment ein sehr nerviges Problem: mein Linux stürzt richtig ab (ja, genau wie Windows, nur BlueScreen gibt's keinen, Linux stirbt leise). :-(
Wann? Ich schreibe grade einen kleinen Raytracer, der auf einem Rechner gleicher Hardware +/- RAM fehlerfrei läuft. Das ganze unter C++. Wer sowas noch nicht gemacht hat: mehr oder weniger sind das zwei for-schleifen, in denen Berechnungen ausgeführt werden. Das ganze läuft 400x300 mal, also 120000 Ausführungen der inneren Schleife.
Jetzt zum Problem: nach ca 300x3 Ausführungen wird es bei mir dunkel, umschalten auf Konsole geht nicht mehr (anpingen kann man ihn vielleicht noch, habe hier aber nur einen Rechner stehen). Das passiert sogar, nachdem ich alles mit OpenGL und den Bibliotheken der GUI, die ich verwende, rausgeschmissen habe, also nur noch ein reines "Rechenprogramm" laufen lasse. Bis hierhin passiert auch noch nichts wildes in der Szene (Hintergrundfarbe), also die wilden Berechnungen starten noch nicht. Der Fehler tritt auch nicht immer an der gleichen Stelle des Programms auf, sondern nach einer gewissen Anzahl von Schleifendurchläufen, den Speicher habe ich inzwischen auch statisch zugeteilt, STL wird auch nicht mehr benutzt. Ach ja, zu Tode swappen kann man auch ausschließen, der swap bleibt schön leer.
Zum System: SuSE 7.2, Kernel 2.4.4, Nvidia-GK (akt. Treiber, 3D und alles läuft), 256 MB RAM, XFree 4.0.3 switch2mesasoft ausgeführt
Das ist alles bis auf die Distri identisch mit dem Rechner, auf dem ich den Kram zum Laufen kriege (RedHat). Ich linke sogar gegen die gleichen Bibliotheks-Versionen.
Da ich aber im Moment wirklich nur Berechnungen laufen lasse (keine Speicherzugriffsfehler, RAM-Speicher habe ich schon mittels MEMTest gecheckt) wollte ich mal fragen, ob
a) schon mal jemand ähnliche Probleme hatte? b) jemand eine Idee hat, woran das liegen könnte?
Kann das am Kernel liegen???
Prinzipiell schon. Versuch mal 2.4.10 Wenn das nicht die Lösung sein sollte, weißt du wenigstens, dass es kein Kernel-Bug ist...
Ich bräuchte den 3D-Beschleunigungs-Kram nicht, Tips, wie ich ein mega-stabiles System hinkriege, wären mir super-recht (mesasoft reicht). Linux ständig rebooten hinterläßt ein komisches Gefühl beim Arbeiten...um eine Neuinstallation würde ich mich gerne drücken, mal abgesehen davon, daß das wohl nix bringt, denn alle Einstallungen, die was mit Grafik zu tun haben sind eh' "Standard".
CU und danke Martin
Gruss, Robert -- Where do you want to be tomorrow? Entracom. Building Linux systems. http://www.entracom.de
participants (6)
-
Falk Sauer -
Martin Oehler -
Rene Broichmann -
Robert Szentmihalyi -
Sven Bergner -
Thomas Hertweck