Ich rätsle nach wie vor warum mein Rechner nur mit transcode abstürzt. Man empfahl mir nomce. Kann ich diese Option einfach an den Schluß anfügen oder muß sie vorher stehen? nomce - no memory check exception checks hört sich problematisch an. Könnte dadurch Datenverlust entstehen? Sollte es danach funktionieren, kann ich dann davon ausgehen, dass der Speicher schadhaft ist? Das ist ein Teil meiner augenblicklichen /boot/grub/menu.lst color white/blue black/light-gray default 0 gfxmenu (hd1,0)/message timeout 8 title linux kernel (hd1,0)/vmlinuz root=/dev/hdb8 vga=0x314 splash=verbose showopts apm=off acpi=off initrd (hd1,0)/initrd Al
Al Bogner schrieb:
Ich rätsle nach wie vor warum mein Rechner nur mit transcode abstürzt. Man empfahl mir nomce. Kann ich diese Option einfach an den Schluß anfügen oder muß sie vorher stehen?
nomce - no memory check exception checks hört sich problematisch an. Könnte dadurch Datenverlust entstehen?
Sollte es danach funktionieren, kann ich dann davon ausgehen, dass der Speicher schadhaft ist?
Wer hat Dir erzaehlt, dass MCE fuer "memory check exception" steht? MCE steht fuer "machine check exception" - damit wird dem Prozessor erlaubt, dem Kernel etwas mitzuteilen, z.B. "hallo kernel, mir wird gerade zu heiss, wir muessen was da- gegen unternehmen!"... Der Kernel kann dann z.B. eine Warnung ausgeben oder, in einem ganz schlimmen Falle, sogar die Ma- schine anhalten. Allerdings ist das alles AFAIK noch im An- fangsstadium und bei Pentium-Systemen per default auf "off". Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
On Wednesday 14 May 2003 21:02, Thomas Hertweck wrote:
Ich rätsle nach wie vor warum mein Rechner nur mit transcode abstürzt. Man empfahl mir nomce.
Wer hat Dir erzaehlt, dass MCE fuer "memory check exception" steht?
"Wer" bringt die Diskussion wohl auch nicht weiter. Ich bin froh, dass mir überhaupt wer einen Tip gegeben hat, was ich noch probieren könnte, warum der Rechner mit transcode mit gar nicht so geringer Wahrscheinlichkeit mit einem Athlon einfriert, mit einem Celeron aber noch nie.
MCE steht fuer "machine check exception" - damit wird dem Prozessor erlaubt, dem Kernel etwas mitzuteilen, z.B. "hallo kernel, mir wird gerade zu heiss, wir muessen was da- gegen unternehmen!"... Der Kernel kann dann z.B. eine Warnung ausgeben oder, in einem ganz schlimmen Falle, sogar die Ma- schine anhalten. Allerdings ist das alles AFAIK noch im An- fangsstadium und bei Pentium-Systemen per default auf "off".
Wenn ich dich also richtig verstanden habe, dann bringt nomce nichts, weil das sowieso default ist. An ein Temperaturproblem kann ich schwer glauben. Nach ein paar Minuten kann die CPU ausgehend von 45 Grad mit transcode nicht so heiß werden, dass es Probleme gibt, wenn es in anderen Fällen nach Stunden mit transcode überhaupt keine Probleme gibt, transcode 0.6.3 und 0.6.4 macht auf Celerons installiert diese Probleme nicht. Daher drehen sich meine Gedanken in Richtung Board bzw. Chipsatz (Asus A7N8X), XP2400+ und Speicher bzw. Kernel. Nachdem es mit dem Kernel von 8.2 Probleme gab, habe ich ftp://ftp.suse.com/pub/people/mantel/next/RPM/k_athlon-2.4.20-62.i586.rpm installiert, das aber keine Änderung brachte. Sollte ein Default-Kernel, also nicht ein Athlon-spezifischer auch laufen? Jede Anregung ist willkommen! Al
Al Bogner schrieb:
On Wednesday 14 May 2003 21:02, Thomas Hertweck wrote:
[...] Wer hat Dir erzaehlt, dass MCE fuer "memory check exception" steht?
"Wer" bringt die Diskussion wohl auch nicht weiter.
Da magst Du Recht haben. Aber es ist nicht gerade hilfreich, wenn jemand so etwas verbreitet: wie man bei Dir sieht, hast Du sofort auf den Speicher zu- rueck geschlossen, was aber bei korrekter Interpre- tation der Abkuerzung MCE (siehe Kernel-Source und Kernel-Dokumentation) kaum der Fall gewesen waere...
Ich bin froh, dass mir überhaupt wer einen Tip gegeben hat, was ich noch probieren könnte, warum der Rechner mit transcode mit gar nicht so geringer Wahrscheinlichkeit mit einem Athlon einfriert, mit einem Celeron aber noch nie.
Versuche es mal mit einem Default-Kernel, nicht mit einem Athlon-spezifischen Kernel. Da geht natuerlich etwas an Optimierung verloren, aber Du weisst immer- hin, ob es dann damit in Zusammenhang steht.
MCE steht fuer "machine check exception" - damit wird dem Prozessor erlaubt, dem Kernel etwas mitzuteilen, z.B. "hallo kernel, mir wird gerade zu heiss, wir muessen was da- gegen unternehmen!"... Der Kernel kann dann z.B. eine Warnung ausgeben oder, in einem ganz schlimmen Falle, sogar die Ma- schine anhalten. Allerdings ist das alles AFAIK noch im An- fangsstadium und bei Pentium-Systemen per default auf "off".
Wenn ich dich also richtig verstanden habe, dann bringt nomce nichts, weil das sowieso default ist.
Auf Pentium-Systemen, ja. Du kannst den Parameter ru- hig auch mal ausprobieren (z.B. am Boot-Prompt ueber- geben oder in die Konfigurationsdatei des Bootloaders schreiben), vielleicht bringt es ja doch etwas, was mich allerdings verwundern wuerde. Passieren kann Dir dabei nichts - das war es ja, was Du glaube ich be- fuerchtet hattest.
[...] Nachdem es mit dem Kernel von 8.2 Probleme gab, habe ich ftp://ftp.suse.com/pub/people/mantel/next/RPM/k_athlon-2.4.20-62.i586.rpm installiert, das aber keine Änderung brachte. Sollte ein Default-Kernel, also nicht ein Athlon-spezifischer auch laufen?
Siehe oben. Er wird laufen, es geht aber etwas Optimierung und damit Performance verloren. Aber teste das ruhig mal aus. Falls es damit gehen sollte, dann hat Dein Problem wohl etwas mit Athlon-Optimierung zu tun. Eventuell soll- test Du auch mal die Option "mem=nopentium" testen... Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
On Wednesday 14 May 2003 21:54, Thomas Hertweck wrote:
Versuche es mal mit einem Default-Kernel, nicht mit einem Athlon-spezifischen Kernel.
Kann ich das mit --force ignorieren? # rpm -Uvh k_deflt-2.4.20-62.i586.rpm error: failed dependencies: k_athlon conflicts with k_deflt-2.4.20-62 k_deflt conflicts with k_athlon-2.4.20-62 Al
Al Bogner schrieb:
On Wednesday 14 May 2003 21:54, Thomas Hertweck wrote:
Versuche es mal mit einem Default-Kernel, nicht mit einem Athlon-spezifischen Kernel.
Kann ich das mit --force ignorieren?
# rpm -Uvh k_deflt-2.4.20-62.i586.rpm error: failed dependencies: k_athlon conflicts with k_deflt-2.4.20-62 k_deflt conflicts with k_athlon-2.4.20-62
Beim Kernel-RPM ist es IMHO gestattet, eine inkonsistente RPM Datenbank zu riskieren. Du solltest wie in Davids Multikernel-Howto[1] beschrieben, erst einmal den bis- herigen Kernel/System.map/initrd umbenennen (mit Versions- nummer versehen) und damit sichern, ansonsten wird der Kernel naemlich ueberschrieben. Installierst Du anschlies- send das k_deflt RPM via "rpm -ihv --nodeps --force" o.ae. dann landen die Module in einem neuen Verzeichnis, und der neue Kernel und dessen System.map landen in /boot (und ueberschreiben nicht den alten Kernel, da Du den ja umbenannt hast). Anschliessend Bootloader anpassen zum Booten beider Kernel und initrd evtl. neu erstellen (falls nicht automatisch beim Einspielen des RPM ge- schehen), und dann rebooten (bei lilo vorher natuerlich /sbin/lilo aufrufen). Cu, Th. [1] http://www.dhaller.de/linux/multikernel.html -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
On Thursday 15 May 2003 22:46, Thomas Hertweck wrote:
erst einmal den bis- herigen Kernel/System.map/initrd umbenennen (mit Versions- nummer versehen) und damit sichern, ansonsten wird der Kernel naemlich ueberschrieben.
Den augenblicklich installierten Athlon-Kernel von Mantel habe ich auf der HD und kann denn von dort aus wieder installieren.
Installierst Du anschlies- send das k_deflt RPM via "rpm -ihv --nodeps --force" o.ae. dann landen die Module in einem neuen Verzeichnis, und der neue Kernel und dessen System.map landen in /boot (und ueberschreiben nicht den alten Kernel, da Du den ja umbenannt hast).
Spricht also was dagegen den Default-Kernel einfach darüber zu installieren und bei Problemen bzw. ähnlich unerklärlichen Abstürzen mit safe-settings zu booten und dann wieder den "mehr oder weniger" funktionierenden Athlon-Kernel zu installieren?
Anschliessend Bootloader anpassen zum Booten beider Kernel und initrd evtl. neu erstellen (falls nicht automatisch beim Einspielen des RPM ge- schehen), und dann rebooten (bei lilo vorher natuerlich /sbin/lilo aufrufen).
Ich sehe in der von dir beschriebenen Vorgehensweise den Vorteil, dass ich mir beim Booten den Kernel aussuchen kann, oder ist da sonst noch ein Vorteil? Seit heute Abend bis morgen früh läuft mal ein memtest. Bis jetzt wurden keine Fehler angezeigt. Al
Al Bogner wrote:
[...]
Ich sehe in der von dir beschriebenen Vorgehensweise den Vorteil, dass ich mir beim Booten den Kernel aussuchen kann, oder ist da sonst noch ein Vorteil?
Nein, das ist der Haupt-Vorteil. Wenn Du gerne (falls was schief geht) mit dem Rettungssystem hantierst etc., dann steht Dir das natuerlich frei und Du kannst auf Multi-Kernel verzichten. CU, Th. -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Hallo Al, hallo Leute, Am Donnerstag, 15. Mai 2003 15:05 schrieb Al Bogner:
On Wednesday 14 May 2003 21:54, Thomas Hertweck wrote:
Versuche es mal mit einem Default-Kernel, nicht mit einem Athlon-spezifischen Kernel.
Kann ich das mit --force ignorieren?
# rpm -Uvh k_deflt-2.4.20-62.i586.rpm error: failed dependencies: k_athlon conflicts with k_deflt-2.4.20-62 k_deflt conflicts with k_athlon-2.4.20-62
Nö, bitte nicht! Verwende bitte rpm -e k_athlon # k_athlon löschen und sofort danach rpm -Uhv k_deflt_2.4.20-62.i586.rpm Das k_deflt_*.rpm sicherheitshalber vor dem Deinstallieren von k_athlon auf die Festplatte kopieren ;-) Dass Du ohne installiertem Kernel keinen Reboot probieren solltest, ist wohl genauso klar wie die Tatsache, dass Du nach dem Installieren des neuen Kernels einmal "lilo" aufrufen musst, falls Du lilo als Bootmanager verwendest ;-) Gruß Christian Boltz -- Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch. [Anselm Lingnau]
Christian Boltz wrote:
[...] Nö, bitte nicht! Verwende bitte rpm -e k_athlon # k_athlon löschen und sofort danach rpm -Uhv k_deflt_2.4.20-62.i586.rpm Das k_deflt_*.rpm sicherheitshalber vor dem Deinstallieren von k_athlon auf die Festplatte kopieren ;-)
Wenn man mehrere Kernel (evtl. testweise) instal- lieren will, kommt man nicht umhin, fuer das Kernel-RPM eine inkonsistente RPM-Datenbank zu riskieren (oder man verwendet halt RPM gar nicht und greift zu den Sourcen ;-) IMHO ist in diesem Falle so etwas erlaubt - in diesem Falle sollte derjenige, der das macht, aber auch genau Be- scheid wissen und dann ist das ja OK... Gruesse, Thomson *der eigentlich immer mehrere Kernel in- stalliert hat, wenngleich eher aus den Quellen compiliert denn mit RPM aufge- spielt* -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
participants (3)
-
Al Bogner -
Christian Boltz -
Thomas Hertweck