SD-Karte nicht mehr beschreibbar

Am 06.02.19 um 20:33 schrieb Gerrit Heitsch:

Tatsächlich kann ECC-RAM in diesem Umfeld sogar kontraproduktiv sein,
weil bei nicht korrigierbaren Fehlern das System hart angehalten wird,
statt nur einen harmlosen Bildfehler zu riskieren.

Was du bei nicht korrigierbaren Fehlern machst bleibt deiner Software
Ăźberlassen, es ist nicht Pflicht eine Systempanic hinzulegen.
Click to expand...

Wenn ECC versagt, hast du es nicht mehr mit einzelnen Bitfehlern zu tun,
sondern mit einem komplett zufälligen Wort. Sprich: Der Fehler wurde
sogar verstärkt.
Es hat schon seinen Grund, warum darauf Ăźblicherweise mit Panic reagiert
wird.

Aber ja, bei einem Mediaplayer ist das nicht so das Problem. Der gibt
Ăźblicherweise nur Daten wieder die woanders noch existieren.
Click to expand...

Bei Spielen wird es ähnlich aussehen. Da sind >95% des RAM-Inhalts
irgendwelche Grafikressourcen, und wenn darin mal ein Bit kippt, fällt
das in den meisten Fällen nicht mal auf.

Hergen
 
On 2/7/19 1:05 AM, Hergen Lehmann wrote:
Am 06.02.19 um 20:33 schrieb Gerrit Heitsch:

Tatsächlich kann ECC-RAM in diesem Umfeld sogar kontraproduktiv sein,
weil bei nicht korrigierbaren Fehlern das System hart angehalten
wird, statt nur einen harmlosen Bildfehler zu riskieren.

Was du bei nicht korrigierbaren Fehlern machst bleibt deiner Software
Ăźberlassen, es ist nicht Pflicht eine Systempanic hinzulegen.

Wenn ECC versagt, hast du es nicht mehr mit einzelnen Bitfehlern zu tun,
sondern mit einem komplett zufälligen Wort. Sprich: Der Fehler wurde
sogar verstärkt.
Click to expand...

Ohne ECC weisst du gar nicht was du da hast, es kann alles von einem
korrekten Wert zu allen Bits invertiert sein. Mit ECC weisst du
zumindest, daß was kaputt ist.

Abgesehen davon gibt es ECC-Implementationen die auch Mehrbitfehler
korrigieren kÜnnen. Hängt davon ab wieviele extra Bits du zur Verfßgung
hast. Mein System hier meldet:

EDAC amd64: using x8 syndromes.

Also 8 Bit extra, mein älteres nur 4. Ich hab noch nicht rausgefunden ob
das einen realen Unterschied macht.



Es hat schon seinen Grund, warum darauf Ăźblicherweise mit Panic reagiert
wird.
Click to expand...

Man kann das auch feiner abstufen:

Im Kernel? => Panic
Im Prozess? => Prozess abschiessen.

Man muss nicht das ganze System abschiessen nur weil ein Prozess
kaputten Speicher benutzt. Es reicht den Prozess abzuschiessen und die
Page mit den kaputten Bits als unbenutzbar zu markieren.

Gerrit
 
Am 07.02.19 um 07:09 schrieb Gerrit Heitsch:

Ohne ECC weisst du gar nicht was du da hast, es kann alles von einem
korrekten Wert zu allen Bits invertiert sein.
Click to expand...

Was fĂźr ein Fehlermechanismus soll das sein, der alle Bits invertiert
(noch dazu, wo sich ein Wort meist Ăźber mehrere Speicherbausteine
erstreckt)?

Nein, so wie ein RAM arbeitet, hast du in aller Regel einzelne, gekippte
Bits. Im Fall ionisierender Strahlung als StĂśrquelle ggf. auch mal
mehrere benachbarte Bits.

Man kann das auch feiner abstufen:

Im Kernel?  => Panic
Im Prozess? => Prozess abschiessen.

Man muss nicht das ganze System abschiessen nur weil ein Prozess
kaputten Speicher benutzt. Es reicht den Prozess abzuschiessen und die
Click to expand...

FĂźr den Desktop-Anwender macht das keinen Unterschied. Seine Daten sind weg.

> Page mit den kaputten Bits als unbenutzbar zu markieren.

Macht das jemand? Ist das sinnvoll?
Bei *kaputtem* RAM wird die Maschine so instabil, das sie eh nicht mehr
zu verwenden ist. Und einzelne zufällig gekippte Bits sollten
wiederverwendbar sein.

Hergen
 
On 2/7/19 9:50 AM, Hergen Lehmann wrote:
Am 07.02.19 um 07:09 schrieb Gerrit Heitsch:

Ohne ECC weisst du gar nicht was du da hast, es kann alles von einem
korrekten Wert zu allen Bits invertiert sein.

Was fĂźr ein Fehlermechanismus soll das sein, der alle Bits invertiert
(noch dazu, wo sich ein Wort meist Ăźber mehrere Speicherbausteine
erstreckt)?
Click to expand...

Schon klar, aber ohne ECC weisst du es eben nicht.


Nein, so wie ein RAM arbeitet, hast du in aller Regel einzelne, gekippte
Bits. Im Fall ionisierender Strahlung als StĂśrquelle ggf. auch mal
mehrere benachbarte Bits.
Click to expand...

Wobei physikalisch benachbarte Bits das nicht unbedingt auch logisch
sein mĂźssen.


Man kann das auch feiner abstufen:

Im Kernel?  => Panic
Im Prozess? => Prozess abschiessen.

Man muss nicht das ganze System abschiessen nur weil ein Prozess
kaputten Speicher benutzt. Es reicht den Prozess abzuschiessen und die

FĂźr den Desktop-Anwender macht das keinen Unterschied. Seine Daten sind
weg.
Click to expand...

Nur die seit dem letzten Save und nur die in diesem Prozess. Das ist
deutlich besser als ein Reboot.



Page mit den kaputten Bits als unbenutzbar zu markieren.

Macht das jemand? Ist das sinnvoll?
Click to expand...

Ja, ich erinnere mich da noch ein einen Eintrag im Syslog einer SPARC
mit Solaris 10. Die hatte in einem Modul an einer Adresse ein schwaches
Bit welches immer mal wieder einen ECC-Fehler warf. Bei längeren Uptimes
konnte man im Syslog was von 'retiring page' (oder so ähnlich) nach
einem korrigierbaren ECC-Error lesen. Zumindest Solaris fĂźhrt also
intern Buch welche Page wie oft ungebĂźhrlich aufgefallen ist. Wenn sie
das zu oft tut wird sie nicht mehr benutzt.

Fand ich schon sinnvoll.



Bei *kaputtem* RAM wird die Maschine so instabil, das sie eh nicht mehr
zu verwenden ist.
Click to expand...

Kommt drauf an wie kaputt... Es gibt ein ECC-Verfahren von IBM welches
nicht umsonst 'Chipkill' heisst. Damit ist der Ausfall eines kompletten
ICs kompensierbar.

Wenn der Chip natĂźrlich Kernschmelze hat und die Busleitungen belegt hat
man verloren.

Gerrit
 
Gerrit Heitsch <gerrit@laosinh.s.bawue.de> schrieb:

Ohne ECC weisst du gar nicht was du da hast, es kann alles von einem
korrekten Wert zu allen Bits invertiert sein. Mit ECC weisst du
zumindest, daß was kaputt ist.

Abgesehen davon gibt es ECC-Implementationen die auch Mehrbitfehler
korrigieren kÜnnen. Hängt davon ab wieviele extra Bits du zur Verfßgung
hast. Mein System hier meldet:

EDAC amd64: using x8 syndromes.

Also 8 Bit extra, mein älteres nur 4. Ich hab noch nicht rausgefunden ob
das einen realen Unterschied macht.
Click to expand...
Es macht keinen. FrĂźher hattest du ein 32Bit-System -> 1 Bit pro Byte
sind 4 Bit fĂźrs ECC. Jetzt sinds 64 Bit (amd64), immer noch 1 bit pro
Byte macht 8 Bit fĂźrs ECC.

Siegfried
 
On 2/7/19 12:06 PM, Siegfried Blos wrote:
Gerrit Heitsch <gerrit@laosinh.s.bawue.de> schrieb:

Ohne ECC weisst du gar nicht was du da hast, es kann alles von einem
korrekten Wert zu allen Bits invertiert sein. Mit ECC weisst du
zumindest, daß was kaputt ist.

Abgesehen davon gibt es ECC-Implementationen die auch Mehrbitfehler
korrigieren kÜnnen. Hängt davon ab wieviele extra Bits du zur Verfßgung
hast. Mein System hier meldet:

EDAC amd64: using x8 syndromes.

Also 8 Bit extra, mein älteres nur 4. Ich hab noch nicht rausgefunden ob
das einen realen Unterschied macht.

Es macht keinen. FrĂźher hattest du ein 32Bit-System -> 1 Bit pro Byte
sind 4 Bit fĂźrs ECC. Jetzt sinds 64 Bit (amd64), immer noch 1 bit pro
Byte macht 8 Bit fĂźrs ECC.
Click to expand...

Ah, OK, dann liegt es einfach daran wie die Speichercontroller benutzt
werden.

Das System mit 4 Bit extra ist auch ein amd64.

Gerrit
 
Am 07.02.19 um 09:50 schrieb Hergen Lehmann:

Page mit den kaputten Bits als unbenutzbar zu markieren.

Macht das jemand? Ist das sinnvoll?
Bei *kaputtem* RAM wird die Maschine so instabil, das sie eh nicht mehr
zu verwenden ist.
Click to expand...

Warum? Ich hab zufällig letztens einen Blick auf den Nagios-Server der
Firma geworfen, der loggte sekĂźndlich (!) ECC-Fehler, seit 3 Wochen. Ich
habs nicht genauer analysiert, aber meiner Interpretation nach ist
(mindestens) 1 Bit dauerhaft und vĂśllig im Arsch, aber halt per ECC
korrigierbar, und Ăśfter als einmal pro Sekunde wird nicht geloggt.

Ich hab der Nachbarabteilung, die den Server betreut, dann halt den Tip
gegeben, das mal zu fixen und Nagios sich auch selber Ăźberwachen zu
lassen :)

Hanno
 
On 2/8/19 3:12 PM, Hanno Foest wrote:
Am 07.02.19 um 09:50 schrieb Hergen Lehmann:

Page mit den kaputten Bits als unbenutzbar zu markieren.

Macht das jemand? Ist das sinnvoll?
Bei *kaputtem* RAM wird die Maschine so instabil, das sie eh nicht
mehr zu verwenden ist.

Warum? Ich hab zufällig letztens einen Blick auf den Nagios-Server der
Firma geworfen, der loggte sekĂźndlich (!) ECC-Fehler, seit 3 Wochen. Ich
habs nicht genauer analysiert, aber meiner Interpretation nach ist
(mindestens) 1 Bit dauerhaft und vĂśllig im Arsch, aber halt per ECC
korrigierbar, und Ăśfter als einmal pro Sekunde wird nicht geloggt.
Click to expand...

Wundert mich, daß Linux noch kein page retirement macht wenn eine Page
zuviele Fehler produziert.

Gerrit
 
Am 08.02.19 um 15:16 schrieb Gerrit Heitsch:

Wundert mich, daß Linux noch kein page retirement macht wenn eine Page
zuviele Fehler produziert.
Click to expand...

Kommt wahrscheinlich zu selten vor, und die Leute tauschen dann eher das
RAM. Per GRUB geht es jedenfalls. Aus /etc/default/grub:

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

Hanno
 
On 2/8/19 3:32 PM, Hanno Foest wrote:
Am 08.02.19 um 15:16 schrieb Gerrit Heitsch:

Wundert mich, daß Linux noch kein page retirement macht wenn eine Page
zuviele Fehler produziert.

Kommt wahrscheinlich zu selten vor, und die Leute tauschen dann eher das
RAM. Per GRUB geht es jedenfalls. Aus /etc/default/grub:

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that
obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
Click to expand...

Ja, OK, das muss man von Hand einfĂźgen. Solaris hat das automatisch
gemacht. Im Logfile stand dazu natĂźrlich eine Meldung.

Die Idee dahinter war wohl, daß man nicht gleich ins RZ rennen muss wenn
der Fehler dauerhaft wird sondern sich die Zeit nehmen kann und erst bei
der nächsten geplanten Downtime das fehlerhafte Modul wechselt.

Gerrit
 
Am 08.02.2019 um 16:17 schrieb Gerrit Heitsch:

Die Idee dahinter war wohl, daß man nicht gleich ins RZ rennen muss wenn der
Fehler dauerhaft wird sondern sich die Zeit nehmen kann und erst bei der
nächsten geplanten Downtime das fehlerhafte Modul wechselt.
Click to expand...

Das war wohl noch in Zeiten vor Hotplug-fähigen Speicherslots.

Bernd
 
Hanno Foest wrote:
> aber halt per ECC korrigierbar,

Weil völlig nicht mein Fachgebiet und ich gar keine Ahnung habe:
Wie kann ich mit einem bit pro Byte korrigieren? Einzelfehler (und alle
höheren ungeraden) erkennen ist klar, aber korrigieren?

--
/Ż\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --
 
Am 08.02.2019 um 16:59 schrieb Axel Berger:

Wie kann ich mit einem bit pro Byte korrigieren? Einzelfehler (und alle
hĂśheren ungeraden) erkennen ist klar, aber korrigieren?
Click to expand...

Gar nicht. Aber die Speicherbänke sind zu 64bit zusammengefasst, also 8
Pritätsbits pro Wort (es werden eigentlich nur 7 benÜtigt). Damit lassen
sich dann 1bit-Fehler im Wort erkennen und korrigieren und 2bit-Fehler
erkennen. Siehe Hamming-Code.

Bernd
 
Gerrit Heitsch <gerrit@laosinh.s.bawue.de> schrieb:

On 2/7/19 12:06 PM, Siegfried Blos wrote:
Gerrit Heitsch <gerrit@laosinh.s.bawue.de> schrieb:

Ohne ECC weisst du gar nicht was du da hast, es kann alles von einem
korrekten Wert zu allen Bits invertiert sein. Mit ECC weisst du
zumindest, daß was kaputt ist.

Abgesehen davon gibt es ECC-Implementationen die auch Mehrbitfehler
korrigieren kÜnnen. Hängt davon ab wieviele extra Bits du zur Verfßgung
hast. Mein System hier meldet:

EDAC amd64: using x8 syndromes.

Also 8 Bit extra, mein älteres nur 4. Ich hab noch nicht rausgefunden ob
das einen realen Unterschied macht.

Es macht keinen. FrĂźher hattest du ein 32Bit-System -> 1 Bit pro Byte
sind 4 Bit fĂźrs ECC. Jetzt sinds 64 Bit (amd64), immer noch 1 bit pro
Byte macht 8 Bit fĂźrs ECC.

Ah, OK, dann liegt es einfach daran wie die Speichercontroller benutzt
werden.

Das System mit 4 Bit extra ist auch ein amd64.
Click to expand...
Da gibt es ja verschiedene Methoden. Die von mir angedachte war eine
der Einfachsten, sie dient nur zur Erkennung, nicht zur Korrektur. Das
geht natĂźrlich auch mit mehr als 8 Bit zu 1 ECC-Bit. Nur je mehr Bit
zu einem Ergebnis im ECC-Bit fĂźhren, desto hĂśher ist die
Wahrscheinlichkeit, dass 2 Bit kippen und das nicht erkannt wird.

Siegfried
 
On 2/8/19 4:57 PM, Bernd Laengerich wrote:
Am 08.02.2019 um 16:17 schrieb Gerrit Heitsch:

Die Idee dahinter war wohl, daß man nicht gleich ins RZ rennen muss
wenn der Fehler dauerhaft wird sondern sich die Zeit nehmen kann und
erst bei der nächsten geplanten Downtime das fehlerhafte Modul wechselt.

Das war wohl noch in Zeiten vor Hotplug-fähigen Speicherslots.
Click to expand...

Die gibt es nur bei High-End-Servern, der Ăźbliche Rackmountserver kann
das nicht. Ausserdem kann es sein, daß der OS-Kernel auf dem fraglichen
Modul zu finden ist. Den musst du vor dem Wechsel erst einmal umziehen.

Bei einer VM natĂźrlich einfach, aber wenn es nicht die VM sondern das
Host-OS ist sieht es anders aus. Solaris konnte das schon um 2002.

Gerrit
 
On 2/8/19 4:59 PM, Axel Berger wrote:
Hanno Foest wrote:
aber halt per ECC korrigierbar,

Weil vĂśllig nicht mein Fachgebiet und ich gar keine Ahnung habe:
Wie kann ich mit einem bit pro Byte korrigieren? Einzelfehler (und alle
hĂśheren ungeraden) erkennen ist klar, aber korrigieren?
Click to expand...

Kannst du nicht. Aber mit 4 Bit extra pro 32 Bit geht eine Korrektur von
1-Bit-Fehlern und eine Erkennung von 2-Bit-Fehlern.

Netterweise reichen dazu immer noch 1 Bit extra pro 8 Bit, man muss sie
nur immer als Gruppe von 32 Bit betrachten.

Gerrit
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top