Ist eine Fehlerkorrektur via Software bei Fehlern im RAM möglich?

[RAMFehler]

Nehmen wir mal ein auf einer CPU mit Harvard Architektur ist der RAM Riegel, auf dem die Daten gespeichert werden defekt.
D.h. insgesamt 10 Bits im 1 GB Riegel sind an unterschiedlicher Stelle im Speicher fehlerhaft und kann keine Zustände mehr annehmen.

Kann man via Software nun so eine Art Software ECC machen?
Z.B. in dem bei einer Variable eine Weitere Variable zur Fehlerkorrektur verwendet?

[;fricky]

^^ warum nicht, mit 'nem 'hamming code' oder sowas. kommt drauf an, wieviele bitfehler du korrigieren oder erkennen willst.

[rapso]

klar, gibt ja auch software raid um das selbe fuer festplatten zu machen.

[naja]

RAM Zugriffe sollen schnell sein, da wäre es schlecht noch aufwendige Fehlerkorrektur zu machen.

[;fricky]

naja schrieb:

RAM Zugriffe sollen schnell sein, da wäre es schlecht noch aufwendige Fehlerkorrektur zu machen.

er will es ja so.

[abc.w]

Fehlerkorrektur via Software bei Fehlern im RAM?

Wie soll denn so was gehen?

int func(void)
{
    int i = 0;
    int i_checksum = compute_checksum(i);

    for (i = 0; i < N; ++i, i_checksum = compute_checksum(i))
    {
        if (0 == checksum_ok(i, i_checksum))
        {
            // Fehler im RAM...
        }
        else
        {
            // Kein Fehler :)
    ...

Das ist verrückt

[;fricky]

abc.w schrieb:

Wie soll denn so was gehen?

^^ so ja nun nicht. die fehlerkorrektur-routine darf doch nicht schon für eigene variablen den angeschlagenen RAM-baustein benutzen. so vielleicht:

int read_with_error_correction (void *from, void *to, size_t length);

kopiert aus schadhaftem RAM von adresse 'from' in heiles RAM nach 'to', gibt 1 zurück, wenn's geklappt hat.

[hustbaer]

ja, ist ziemlich verrückt, vor allem da das programm ja auch irgendwo im RAM stehen muss. und wenn einer der bitfehler das programm selbst betrifft...

[;fricky]

hustbaer schrieb:

...vor allem da das programm ja auch irgendwo im RAM stehen muss. und wenn einer der bitfehler das programm selbst betrifft...

^^ das sollte man auch vermeiden. sich selbst an den haaren aus dem sumpf ziehen konnte nur münchhausen. *fg*

[hustbaer]

naja, selbst wenn das programm in einem ROM steht. der stack muss auch irgendwo hin. in software ist sowas einfach problematisch.

[abc.w]

Man könnte es vielleicht so hinkriegen, dass man das Programm komplett im ROM (echtem ROM, Flash usw.) stehen hat und man keine Funktionsaufrufe macht, wegen Rücksprungadressen auf dem Stack, die dann ja fehlerhaft sein könnten. Aber ob sich der Aufwand lohnt

[Assembler rules]

abc.w schrieb:

Fehlerkorrektur via Software bei Fehlern im RAM?

Wie soll denn so was gehen?

int func(void)
{
    int i = 0;
    int i_checksum = compute_checksum(i);

    for (i = 0; i < N; ++i, i_checksum = compute_checksum(i))
    {
        if (0 == checksum_ok(i, i_checksum))
        {
            // Fehler im RAM...
        }
        else
        {
            // Kein Fehler :)
    ...

Das ist verrückt

Nö, dein Programm ist falsch.

Denn du verwendest ja die Variable, die ja fehlerhaft ist.
Damit es funktioniert müßtest du aber die checksumme aus dem Inhalt des Registers erstellen, daß der Variable zugewiesen wird.

Mit Assembler geht so etwas.

[Harvard]

hustbaer schrieb:

ja, ist ziemlich verrückt, vor allem da das programm ja auch irgendwo im RAM stehen muss. und wenn einer der bitfehler das programm selbst betrifft...

Nein, da es eine Harvard Architektur ist und das Programm seinen eigenen unabhängigen und funktionierenden Speicher besitzt.

[NASA]

PS:

Die Frage hat natürlich ein reales Anwendungsgebiet.

Stellt euch einfach mal vor, das RAM einer Sonde der NASA ist defekt und nun würde man mit einem SW Patch das Problem beheben wollen.

[;fricky]

Assembler rules schrieb:

Mit Assembler geht so etwas.

stimmt ja, wenn sich alles in CPU-registern abspielt, brauchste kein externes RAM für den ECC, dann kann der ganze speicher vermackelt sein.

NASA schrieb:

P
Die Frage hat natürlich ein reales Anwendungsgebiet.
Stellt euch einfach mal vor, das RAM einer Sonde der NASA ist defekt und nun würde man mit einem SW Patch das Problem beheben wollen.

naja, die nehmen doch redundante systeme. wenn ein rechner schlapp macht, springt dafür ein anderer ein.

[abc.w]

Assembler rules schrieb:

...
Nö, dein Programm ist falsch. Denn du verwendest ja die Variable, die ja fehlerhaft ist.

Ach so, stimmt, Du hast Recht, die Funktion ist falsch. Kein Respekt vor dem Code!

;fricky schrieb:

NASA schrieb:

Die Frage hat natürlich ein reales Anwendungsgebiet. Stellt euch einfach mal vor, das RAM einer Sonde der NASA ist defekt und nun würde man mit einem SW Patch das Problem beheben wollen.

naja, die nehmen doch redundante systeme. wenn ein rechner schlapp macht, springt dafür ein anderer ein.

Hi, hi, um die Hardware muss man sich keine Sorgen machen. Die Frage müsste eher heissen: "Stellt euch einfach mal vor, die Software in der Sonde ist toll, doch sie beinhaltet ein Modul, das in Zoll und Meilen rechnet..."

[hustbaer]

Harvard schrieb:

hustbaer schrieb:

ja, ist ziemlich verrückt, vor allem da das programm ja auch irgendwo im RAM stehen muss. und wenn einer der bitfehler das programm selbst betrifft...

Nein, da es eine Harvard Architektur ist und das Programm seinen eigenen unabhängigen und funktionierenden Speicher besitzt.

Dass der Speicher unabhängig ist, bedeutet noch lange nicht, dass er auch funktioniert.
Davon abgesehen: wo liegt bei einer Harvard Architektur der Stack? Im Programm-Bereich oder im Daten-Bereich?

[hustbaer]

NASA schrieb:

Stellt euch einfach mal vor, das RAM einer Sonde der NASA ist defekt und nun würde man mit einem SW Patch das Problem beheben wollen.

Wenn man die defekten Stellen im RAM kennt, ist das denke ich kein Problem.
Auch defekte Stellen zu finden sollte kein Problem sein.

Schwierig bis unmöglich wird es erst dann, wenn man spontan auftretende Fehler "verlustfrei" überstehen können möchte, wie das eben mit ECC RAM recht gut geht.

[rapso]

hustbaer schrieb:

Schwierig bis unmöglich wird es erst dann, wenn man spontan auftretende Fehler "verlustfrei" überstehen können möchte, wie das eben mit ECC RAM recht gut geht.

was, ausser der performance, sollte in software anders sein?

[hustbaer]

rapso schrieb:

hustbaer schrieb:

Schwierig bis unmöglich wird es erst dann, wenn man spontan auftretende Fehler "verlustfrei" überstehen können möchte, wie das eben mit ECC RAM recht gut geht.

was, ausser der performance, sollte in software anders sein?

Naja, wo willst du z.B. die ECC Lines zur Überprüfung hinladen? Alles in Register? Oder willst du dich darauf verlassen dass der CPU interne Cache eh ECC hat, daher zuverlässig funktioniert, und dass eine ECC Line zwischen Überprüfung und Verwendung eh nicht aus dem Cache fliegen wird?

Und was ist mit Stack-Zugriffen? Alles per Hand selbst machen? Also alle "call" Befehle ersetzen durch Rücksprungadresse sichern + "jmp"? Und was weiter mit Interrupts/Exceptions/Traps?

Eine 100%ige Lösung kann ich mir einfach nicht vorstellen.

Was ginge wäre ein Kompromiss, der sich darauf beschränkt einen grossen Teil der Fehler zu finden. Sowas könnte man dann vermutlich auch halbwegs performant hinbekommen, dafür könnte in bestimmten Situationen ein Fehler übersehen werden.