Hallo, Am Sam, 13 Jun 2009, Arno Lehmann schrieb:
12.06.2009 21:42, Stefan Plenert wrote: [..]
Der RAM führt jetzt
Nein. RAM führt nie was aus.
Jup. Die CPU holt sich Daten aus den L1 und L2, ggfs. auch L3 Caches, in ihre Register. Die Caches werden via Speichercontroller (bei AMD Athlon 64 mit in der CPU) aus dem RAM. Ausgeführt werden die Befehle aus den Registern (die dazu dekodiert, umsortiert ... werden), auf Daten die ebenfalls in Registern stehen müssen.
die Befehle des ROM aus, das Lesen der andren Hardware, das Lesen des Betriebssystem von der Festplatte. ... Windows 3.x musste ziemlich viele *.tmp anlegen, die oft beim herunterfahren auf der Festplatte liegen blieben.
Das hat mit der Speichergröße erst mal wenig zu tun - auch Vista legt haufenweise temporäre Dateien an. Bzw. die Anwendungsprogramme die man so nutzt.
Das hat mit dem RAM genau gar nichts zu tun. Einen einzigen Zusammenhang gibt es: das Swapfile / die Swappartition, in die der RAM-Inhalt bei einem Suspend 2 Disk geschrieben wird.
Jetzt ist der Speicher größer. Beim Runter fahren bleiben die Daten in RAM.
Nein. Wirklich nicht. Nicht anders als "früher".
Jup.
Beim Warmstart sind noch Daten im RAM
Jein.
Es sind immer Daten in RAM, in dem Sinne dass jede Speicherzelle jederzeit ausgelesen werden kann und einen Wert zurückgibt.
Auch bleiben Daten im RAM nach Abschalten der Stromzufuhr bzw. Ausbleiben des Refreshs eine Zeit lang unverändert - irgendwo im Bereich von Sekundenbruchteilen bis Minuten (Kältespray -> länger -> forensisch auswertbar).
Typisch sind es glaub ca. 30s, nach denen man davon ausgehen kann, daß die HW "aus" ist.
Wann kann ich vom Kaltstart sprechen. Nach 5 Std. sind die Hälfte der Daten raus. Nach 10-12 Std so gut wie alle. Dann muss alles neu von ROM und der Festplatte in RAM geschrieben werden.
Sorry, aber das ist völliger Unsinn.
Genau. Ich frag mich schon den ganzen Thread lang, wie Stefan auf diese abstruse Idee kommt.
Ein Kaltstart ist es, wenn der Rechner seine komplette Hardware-initialisierung durchführt. Aus- und Einschalten oder Resetknopf machen das. Dazu reichen im Fall des Resetknopfes normalerweise Zeiten im Bereich von Sekundenbruchteilen.
Manchmal reicht das nicht, aber so 4-5s den Resettaster halten reicht meist.
Ein Warmstart ist das was typischerweise dann passiert wenn Du z.B. im Bootmenü Strg-Alt-Entf drückst - hier wird nicht die komplette Initialisierung durchgeführt.
Jup, IIRC landete man bein Win9x fast verzögerungsfrei, ohne POST (Power On Self-Test), wieder beim Bootmanager (so vorhanden ;).
Jetzt wo der PC über 24 Stunden ohne Strom war, hat sich der Speicher entladet und alles ist wieder in Ordnung.
Der Datenmüll ist aus dem Speicher.
Das ist Unfug.
Ich fang' an mich zu Wiederholen, aber das Problem dürfte eher in defekter oder schlecht designter anderweitiger Hardware liegen - Grafikkarte die sich nicht korrekt initialisiert, zu schwaches Netzteil, defekter Speicher, ...
Eben.
memtest, lasttest, mencoder und dd's ? Ja. Erst mal memtest - das läuft ohne Betriebssystem dahinter, also per se als einziges Programm (kann man bei SUSE bei Bedarf per Paket installieren, glaube ich, und wird im grub- oder lilo-Menü ausgewählt).
Wenn das keine Fehler findet, dann normal linux starten und parallel mencoder und ddss laufen lassen.
Von den Test habe ich keine Ahnung.
memtest bzw. memtest86+ kann man mit SUSE-Bordmitteln installieren und dann im Startmenü auswählen. Vermutlich gibt es auch irgendwo eine Dokumentation.
mencode ist ein media encoder, sprich hervorragend geeignet um lange hohe CPU-Last zu erzeugen. David Haller hat mehrfach beschrieben wie er das nutzt um Speicherfehler zu finden.
Mein Standard: ein Video, das ich hier mal als "EINGABEDATEI" bezeichne mit 30min Länge (oder länger) nehmen. mencoder verarbeitet fast alles (.avi, .mkv, .mov mit fast allen Codecs), nur sollte die Datei schon lokal auf der Festplatte liegen. Dann schickt man mencoder ans Werk. ==== for i in $(seq 1 $(grep -c '^processor' /proc/cpuinfo)); do mencoder -oac copy -ovc lavc -lavcopts vcodec=mpeg4 \ -o "Ausgabe${i}.avi" EINGABEDATEI ; done ==== Man sollte dabei ggfs. mal gucken, ob die Festplatte ins Schwitzen bekommt, aber normalerweise sollte es nix machen, daß mehrere mencoder die gleiche Eingabedatei verwenden. Andernfalls die relevante Angabe eben anpassen: -o "Ausgabe${i}.avi" "Eingabe${1}.avi" ; (dazu muß man eben die Eingabedateien passend durchnummerieren, ein symlink reicht, ein hardlink sowieso). Das startet auf jedem CPU-Kern einen mencoder-Prozess (ich verwende hier (und auch sonst meist) absichtlich keine Threads) und kodiert die Ausgabe-Datei als Divx-MPEG4 im AVI-Container. Warum mencoder? Ich hab bei Speicherprobleme vermutet. memtest 4h laufen lassen (auf 1 GB oder hatte ich da schon einen Riegel draussen, also auf nur 512 MB?). Keine Fehler. Aber wenn ich auf dem Dual-Core auch nur ein mencoder (wie oben) laufen ließ semmelte mencoder in ca. 60% der Versuche mit einem "SEGFAULT" ab, einige Male gab's sogar nen komplett-Absturz des Rechners. Mit 2 mencodern konnte ich den mencoder-Segfault meist innerhalb von 10min, selten erst nach über 30min provozieren -- und es lief praktisch kein mencoder (Dauer ca. 60min) komplett durch. Dann hab ich einen der 2 (als Paar / Kit verkauften) Speicherriegel ausgebaut. Da lief dann ein einzelner mencoder öfter durch (Abstürze nur noch in ca. 30-40% der Versuche). Aber ein CPU-Kern hat sich dabei natürlich gelangweilt. Schließlich hab ich dann den Speicher komplett getauscht (war noch Garantie :), und, oh Wunder, seitdem kann ich mit 2 oder gar mehr mencoder-Prozessen (auch mit Threads, nur bringt das nix, 2 lasten beide Kerne aus) Stundenlang beide CPU-Kerne unter Volllast laufen lassen -- ohne auch nur einen SEGFAULT / Absturz. Das Problem war also ganz eindeutig das kaputte RAM. Warum auch immer memtest (in der einen oder evtl. den 2 Runden) nix gefunden hat, aber mencoder dieses Verhalten zeigt -- ich weiß es nicht. Aber es scheint das RAM auf eine Weise zu belasten, die eben Fehler "aufdeckt".
Manual-Seiten gibts natürlich auch. Und vorsicht - wer als root mit dd arbeitet und if und of verwechselt lernt den Wert von Backups kennen ;-)
*hurhur* Tip: dd, fdisk, mkfs*, rm -rf und Co. vertragen sich weder mit Alkohol noch Müdigkeit! Wer das ignoriert hat nicht zu heulen ... -dnh, der damit Erfahrungen hat ... -- Momentan vermitteln sie mir die geistige Frische einer Tigerente. -- Günter Jauch zu einer Kandidatin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org