Folgendes war passiert:
Mehrere Mikrocontroller wurden in baugleichen Steuerungen nacheinander
programmiert. Beim Verify der programmierten Mikrocontroller wurde kein
Fehler angezeigt. 25% der Steuerungen arbeiteten anschließend
einwandfrei, die anderen Steuerungen hatten offensichtlich einen kleinen
identischen Rechenfehler im Programm, für den ein gekipptes Bit in der
Software ausreichen würde. Nach erneuter Programmierung arbeiteten alle
Steuerungen wieder einwandfrei.
Für diesen Effekt habe ich keine eindeutige Erklärung. Kann es sein, daß
im PC-Arbeitsspeicher beim Programmieren ein Bit gekippt war, so dass
alle nachfolgend programmierte Steuerungen den Rechenfehler hatten?
Habt Ihr auch schon einmal so etwas erlebt?
Hast du die Controller mit dem "gekippten" Bit ausgelesen oder woher
weist du dass überall das gleiche Bit "gekippt" ist?
Nein sowas habe ich noch nie erlebt.
> Hast du die Controller mit dem "gekippten" Bit ausgelesen
leider nein
> woher weist du dass überall das gleiche Bit "gekippt" ist
das ist eine Vermutung, da sich alle Steuerungen bei einer Berechnung um
den offensichtlich gleichen Betrag verrechneten
>25% der Steuerungen arbeiteten anschließend>einwandfrei, die anderen Steuerungen hatten offensichtlich einen kleinen>identischen Rechenfehler im Programm, für den ein gekipptes Bit in der>Software ausreichen würde.
Ich würde sagen das bei den ersten 25% ein Bit so gekippt ist,
das die offensichtlich falsche Berechnung korrigiert wird.
Hi
>das ist eine Vermutung, da sich alle Steuerungen bei einer Berechnung um>den offensichtlich gleichen Betrag verrechneten
Nun, wenn alle das gleiche Programm abarbeiten, dann rechnen auch alle
gleich falsch. Oder hab ich da was mißverstanden...
So wie ich das lese, denke ich, ein Programmfehler oder besser gesagt
ein Programmierfehler.
Gruß oldmax
Ich würde ja erstmal alle Prozessoren auslesen (falls Du nicht schon
verfused hast) und vergleichen.
Oh - ich lese gerade, dass Du bereits alle forensisch verwertbaren
Spuren vernichtet hast.
> Beim Verify der programmierten Mikrocontroller wurde kein> Fehler angezeigt.
Dann würde ich mal vom Naheliegensten ausgehen:
Ein Fehler im Programm, der sich durch Zufall auf 25% der Prozessoren
nicht ausgewirkt hat. Zufall könnte zb sein, dass der eine Eingang ohne
Pullup-Widerstand zufällig sich aus der Radiostrahlung die notwendige 0
gesaugt hat, während alle anderen zufällig an diesem Pin just im Moment
des Auslesens eine 1 erhalten haben. Es könnte aber auch ganz banal eine
nicht initialisierte Variable sein :-)
Das heisst jetzt nicht, das das so war. Aber es wäre ein mögliches
Szenario. Und es ist als Szenario sehr viel wahrscheinlicher als ein
kosmisches Teilchen, welches sich ausgerechnet dieses eine Bit im PC
gesucht hat um es umzustellen und dann auch noch ein Bit erwischt hat,
welches im Programmfluss auf dem µC lediglich eine falsche Berechnung
verursacht. Die Wahrscheinlichkeit dafür ist zwar nicht 0, aber
wesentlich über ein paar tausendstel Prozent würde ich sie aus dem Bauch
heraus nicht ansiedeln.
Dagegen ist die Wahrscheinlichkeit eines Software oder Hardware-Fehlers
um ein paar Zehenerpotenzen größer und, wieder aus dem Bauch heraus,
irgendwo bei 95%
> Ein Fehler im Programm, der sich durch Zufall auf 25% der Prozessoren> nicht ausgewirkt hat.
Nach erneutem Programmieren arbeiteten alle Mikrocontroller einwandfrei!
Das schließt einen Programmfehler aus.
> Zufall könnte zb sein, dass der eine Eingang ohne> Pullup-Widerstand zufällig sich aus der Radiostrahlung die notwendige 0> gesaugt hat, während alle anderen zufällig an diesem Pin just im Moment> des Auslesens eine 1 erhalten haben.
Auch das kann nicht erklärt werden, wenn nach erneutem Programmieren
wieder alle in Ordnung war.
Wenn die Daten nach dem Programmieren auch verifiziert wurden, kann es
sich ja nur nachher verändert haben.
Falls das Programm sich auf dem PC verändert hat, wieso funktionierte es
denn beim nochmaligen Programmieren? Hast Du den Code am PC nochmal
übersetzt? Wenn ja, hast Du den alten (angeblich defekten) Code
überschrieben oder noch aufgehoben. Wenn letzteres, kannst Du die Codes
ja mal vergleichen.
Sandy schrieb:
>> Ein Fehler im Programm, der sich durch Zufall auf 25% der Prozessoren>> nicht ausgewirkt hat.> Auch das kann nicht erklärt werden, wenn nach erneutem Programmieren> wieder alle in Ordnung war.
Waren die Prozessoren vor dem erneuten Programmieren länger vom Strom
getrennt/EEProm gelöscht, etc...
Wenn der Stack z.B. in der falschen Reihenfolge programmiert wird, dann
funktioniert u.U. das Programm erst wieder nachdem es einmal neu
gestartet wurde...
Wenn du sicher bist das alles bei dir i.O. ist (was du ja nun nicht mehr
nachprüfen kannst bleibt ja nur folgendes:
- Illuminaten/Freimaurer!!
- EMP, Außerirdische, kleiner Quasar
- Verify/Programmer arbeiten inkorrekt
Sandy schrieb:
>> Ein Fehler im Programm, der sich durch Zufall auf 25% der Prozessoren>> nicht ausgewirkt hat.>> Nach erneutem Programmieren arbeiteten alle Mikrocontroller einwandfrei!> Das schließt einen Programmfehler aus.
Nein, das tut es nicht.
Leider nicht.
alte Merkregel:
Durch Testen kann man immer nur das Vorhandensein eines Fehlers
nachweisen. Niemals das Fehlen.
Wenn also ein Fehler von 'alleine verschwindet', ohne das eine
nicht-esoterische Erklärung dafür gefunden werden kann, ist Feuer am
Dach. Erfahrene Programmierer richten sich dann schon mal auf eine lange
Nachtschicht ein, in der sie die uninitialisierte Variable, den
Pointer-der-in-den-Wald-zeigt, den Array-Overflow der den Stack
zerschossen hat etc. suchen gehen.
Du hast zwar in allen Prozessoren jeweils das identische Programm, wenn
sich die Ergebnisse dann trotzdem unterscheiden kann nur noch die 2-te
notwendige Komponente den Unterschied ausmachen: Die Daten, die in die
Algorithmen hineingehen. Und hier kann der aus der Chaosthoerie bekannte
'Schmetterlingseffekt' zum tragen kommen. Sind die Daten eben nicht
identisch (zb weil ein ADC Wnadler involviert ist und die selbst auf ein
und demselben Prozessor bei konstanter Eingangsspannung unterschiedliche
Ergebnisse bringen), dann wirkt sich auf dem einen µC ein Programmfehler
aus und auf dem anderen nicht.
(*) Ein Fehler der dadurch verschwindet, indem man das gleiche Programm
ein 2-tes mal in den µC brennt, fällt zunächst unter eosterisch.
Entweder ist der Brennprogramm korrekt gelaufen oder er ist es nicht.
Ein Verify würde das aber zutage bringen. Da bei dir der Verify nicht
angeschlagen hat, kann man sicherlich zunächst davon ausgehen, dass die
Programmübertragung fehlerfrei war.
> Wenn die Daten nach dem Programmieren auch verifiziert wurden, kann es> sich ja nur nachher verändert haben.
Mit was verifiziere ich? Es sind doch die Daten, die im
PC-Arbeitsspeicher stehen, oder?
> Btw; ist in den Hex-Daten nicht eine Prüfsumme mit drin? Und überprüft> der Programmer (welchen verwendest Du?) diese nicht beim Brennen?
Um nicht versehentlich die im Mikrocontroller abgelegten EEPROM-Daten zu
ändern, wurde folgende Reihenfolge gewählt:
1) Alle Daten aus dem Mikrocontroller auslesen
2) Neu assemblieren
3) Mikrocontroller neu beschreiben
So ist auf einen Blick und in absoluten Stresssituationen
sichergestellt, dass der Mikrocontroller sowohl das richtige Programm
(sichtbar im Programmkopf) als auch seine alten EEPROM-Daten erhält.
> Durch Testen kann man immer nur das Vorhandensein eines Fehlers> nachweisen. Niemals das Fehlen.
Es ist aber ein Fehler, der offensichtlich nicht im Programm zu suchen
ist. Die Arbeitsumgebung blieb unverändert. Auch waren eine ganze Anzahl
von Mikrocontrollern betroffen; es war kein Einzelfall.
Sandy schrieb:
>> Durch Testen kann man immer nur das Vorhandensein eines Fehlers>> nachweisen. Niemals das Fehlen.>> Es ist aber ein Fehler, der offensichtlich nicht im Programm zu suchen> ist.
Für dich vielleicht.
Für mich ist der Fehler ziemlich offensichtlich im Programm zu suchen.
> Die Arbeitsumgebung blieb unverändert.
Inklusive zb. thermischen Rauschen, Handystrahlung und Radiowellen?
Also wenn ich bei meinem Mega einen Pullup vergesse, passieren die
tollsten Dinge, je nachdem ob meine Freundin hinter mir ihre neuen
Nylons spazieren trägt oder nicht :-)
> Auch waren eine ganze Anzahl> von Mikrocontrollern betroffen; es war kein Einzelfall.
Umso schlimmer.
Und du hast bei allen gleich eine Neuprogrammierung gemacht, ohne erst
mal bei einem auf Spurensuche zu gehen?
Na wenn du meinst.
Sagst du mir noch welche Firma das ist?
Speicherfehler sind nicht grundsätzlich auszuschliessen, zumindest wenn
ein normaler PC ohne ECC-Speicher verwendet wurde. Aber da alle Spuren
vernichtet wurden lässt sich das nicht mehr nachweisen. Sollte
allerdings der zum Programmieren verwendete PC in den nächsten Monaten
eine gewisse Neigung zu Abstürzen haben, solche die man aus alter
Gewohnheit gerne Microsoft in die Schuhe schiebt, dann könnte ein
Zusammenhang bestehen.
Allerdings spricht die Wahrscheinlichkeit dafür, dass beispielsweise
beim Programmieren versehentlich ein falsches Image/Hexfile verwendet
wurde.
> Und du hast bei allen gleich eine Neuprogrammierung gemacht, ohne erst> mal bei einem auf Spurensuche zu gehen?
Leider gab es Randbedingungen, die eine effektive Spurensuche
verhinderten.
> Inklusive zb. thermischen Rauschen, Handystrahlung und Radiowellen?
Wie erzeugst Du damit in 75% aller unmittelbar benachbarter Steuerungen
einen Rechenfehler und läßt die anderen 25% unbeeinflußt?
Wieso sollen diese Beeinflussungen nach Neuprogrammierung plötzlich
keinen Einfluß mehr haben?
Sandy schrieb:
> Es ist aber ein Fehler, der offensichtlich nicht im Programm zu suchen> ist. Die Arbeitsumgebung blieb unverändert. Auch waren eine ganze Anzahl> von Mikrocontrollern betroffen; es war kein Einzelfall.
Was nochmal auf einen Fehler im Quellcode hindeutet. Ein gekipptes Bit
im Controller kann sich ja nicht überall an der gleichen Stelle
befinden.
Da Du aber die alten Daten (also das zuerst programmierte Binär- oder
Hex-File) gelöscht oder überschrieben hast, und diese nicht mehr mit den
aktuell verwendeten vergleichen kannst, ist es eh zu spät, den Fehler
einzukreisen. Das einzige, was bleibt, ist der aktuelle Quellcode, den
es auf eventuelle Programmierfehler (ja ich weiß, es gibt eine)
abzusuchen ist.
Oder hast Du nur die "defekten" Prozessoren neu beschrieben und kommst
noch an die (alten) Daten der anderen Prozessoren ran?
Ja => alte Prozessoren auslesen, neue Prozessoren auslesen und alle drei
Binaries (alt, neu und auf dem pc) mittels binärem Diff vergleichen
(alternativ reicht auch eine MD5- oder SHA-Prüfsumme, wobei man dabei
die genaue Stelle des Unterschieds nicht finden kann).
> Allerdings spricht die Wahrscheinlichkeit dafür, dass beispielsweise> beim Programmieren versehentlich ein falsches Image/Hexfile verwendet> wurde.
Auch eine Verwechslung schweidet aus, da es genau 1 Programmfile gab.
Karl heinz Buchegger schrieb:
> passieren die> tollsten Dinge, je nachdem ob meine Freundin hinter mir ihre neuen> Nylons spazieren trägt oder nicht :-)
Das ist aber doch unabhängig vom Prozessor oder ;-)
Christian H. schrieb:
> Was nochmal auf einen Fehler im Quellcode hindeutet. Ein gekipptes Bit> im Controller kann sich ja nicht überall an der gleichen Stelle> befinden.
Je nachdem wie und womit programmiert wurde. Wenn das unabhängig
Vorgänge sind, dann ist das mit Sicherheit auszuschliessen. Wenn das
eine Serienfertigung mit entsprechender Programmiersoftware war, dann
reicht ein einziger Fehler aus. Wobei das dann ggf. auch ein
Übertragungsfehler gewesen sein kann.
Sandy schrieb:
>> Und du hast bei allen gleich eine Neuprogrammierung gemacht, ohne erst>> mal bei einem auf Spurensuche zu gehen?>> Leider gab es Randbedingungen, die eine effektive Spurensuche> verhinderten.>>> Inklusive zb. thermischen Rauschen, Handystrahlung und Radiowellen?>> Wie erzeugst Du damit in 75% aller unmittelbar benachbarter Steuerungen> einen Rechenfehler und läßt die anderen 25% unbeeinflußt?
Zum Beispiel in dem nicht alle Prozessoren zum auf die Nanosekunde exakt
gleichen Zeitpunkt in Bezug auf die Phasenlage der Störsignale gestartet
wurden!
Da gibt es elektromagnetische Wellen ohne Ende in der Luft!
Je nachdem ob der eine µC die Welle gerade in einem Nulldurchgang und
ein anderer die Welle an ihrem Maximum erwischt, liest er vom Port was
anderes ein!
Auch hast du erwähnt, dass die EEPROM Daten (per Design) bei jedem Proz
erhalten blieben. Wer sagt dir, dass die alle identisch waren?
> Wieso sollen diese Beeinflussungen nach Neuprogrammierung plötzlich> keinen Einfluß mehr haben?
Hat sie.
Aber so ist das nun mal mit Zufällen. Einmal treten sie auf ein anderes
mal nicht.
A. K. schrieb:
> Wobei das dann ggf. auch ein> Übertragungsfehler gewesen sein kann.
...der sich aber beim Verify gezeigt hätte.
> Speicherfehler sind nicht grundsätzlich auszuschliessen, zumindest wenn> ein normaler PC ohne ECC-Speicher verwendet wurde.
Kommt drauf an, wie programmiert wurde.
Alles nacheinander; dann kommen die Dateien von der Platte.
Da wäre es gut zu wissen, ob nur die zuerst programmierten Prozessoren
oder die Letzten fehleraft waren (Seriennummer?).
Sicherlich lässt sich aber auch das nicht mehr nachprüfen.
Aber es bringt ja sowieso nichts. Alle sachdienlichen Spuren sind
vernichtet und der Programmierer besteht auf Korrektheit des Programms
(obwohl kein Programm mit mehr als 0 Byte Größe fehlerfrei ist).
> Auch hast du erwähnt, dass die EEPROM Daten (per Design) bei jedem Proz> erhalten blieben. Wer sagt dir, dass die alle identisch waren?
Waren sie nicht. Wir haben sie sogar munter geändert, um ggf. eine
Abhängigkeit zu finden. Den Rechenfehler hat das aber nicht
interessiert. Erst die Neuprogrammierung brachte den Erfolg.
> dann kommen die Dateien von der Platte.
Beim Starten der Programmierumgebung wurde die Platte nur einmal
gelesen. Danach kamen alle Daten aus dem PC-Arbeitsspeicher.
Aloah,
auch wenn es nicht ganz zum Thema passt...
Ich erinnere gern an eine Defekte/ falsch Programmierte South(North?)
Bridge bei älteren PC's . Wurde damals eine Datei > 100 MB von Platte A
nach Platte B kopiert waren die Daten geschreddert !
Wollte hier nur anmerken, auch auf den PC is nich immer verlass !!!
Ahoi
Steff
Sandy schrieb:
>> Auch hast du erwähnt, dass die EEPROM Daten (per Design) bei jedem Proz>> erhalten blieben. Wer sagt dir, dass die alle identisch waren?>> Waren sie nicht. Wir haben sie sogar munter geändert, um ggf. eine> Abhängigkeit zu finden. Den Rechenfehler hat das aber nicht> interessiert. Erst die Neuprogrammierung brachte den Erfolg.
Ahja, ihr habt das Programm also geändert, der Fehler war aber immer
noch da.
Aber nur ein anschließendes (erneutes) Programmieren mit dem
original-Programm hat das Problem gelöst.
Warum hat das programmieren mit dem veränderten Programm also nicht
geholfen?
Ahja, eins wär da noch: Selbst wenn da ein Bit im Arbeitsspeicher
umgekippt ist, dann müssten die 25% mit korrekter Funktion vor den
restlichen Programmiert worden sein.
> Warum hat das programmieren mit dem veränderten Programm also nicht> geholfen?
Zum Verständnis: im EEPROM liegen Daten und nicht das Programm!
Es waren natürlich Mikrocontroller mit Flash-Speicher, in dem das
Programm abgelegt war. Es gab nur eine Programmversion.
> Selbst wenn da ein Bit im Arbeitsspeicher> umgekippt ist, dann müssten die 25% mit korrekter Funktion vor den> restlichen Programmiert worden sein.
Ja, der Fehler stellte sich offensichtlich während der Programmierung
der Mikrocontroller ein.
>Ja, der Fehler stellte sich offensichtlich während der Programmierung>der Mikrocontroller ein.
Der Fehler sitzt vor der Tastatur. Da kannst du annehmen
was du willst ;)
Steff schrieb:
> Ich erinnere gern an eine Defekte/ falsch Programmierte South(North?)> Bridge bei älteren PC's . Wurde damals eine Datei > 100 MB von Platte A> nach Platte B kopiert waren die Daten geschreddert !>> Wollte hier nur anmerken, auch auf den PC is nich immer verlass !!!
Es ist ziemlich gut darauf Verlass, dass ein mit dem PC programmierter
Controller der falsch rechnet nicht das erste Symptom ist mit dem sich
ein fehlerhafter PC-Speicher bemerkbar macht.
Beispielerklärung: offener Pullup/Kabelbruch an 25% der Platinen. Beim
Stecken/rausziehen des Programmierkabels berührst du die offenen
Eingänge, speist kurz Ladung ein und das Programm liest wieder den von
dir erwarteten Wert... bis wieder zufällig was kippt und du erneut
umflashst/berührst...
sandy, du bist ja ein lustiger Vogel :-)
Funny Story zum gute Nacht Bier ;-)
Nur noch mal, damit ich auch nix verpasst habe:
du programmierst ein paar Geräte. Das Binary lädst du mit deinem
Programmiertool in deinen "defekten" Arbeitsspeicher also nicht du,
sondern natürlich dein Betriebssystem und dein Prozess sagt er hätte
gern Speicher.. ok, nun gut. Also nun programmierst du deinen
Controller.. und hoppla ein Bit im Arbeitsspeicher ist gekippt.. so ein
Mist aber auch - verflixt und zugenäht- nun gut, davon weiß unser
Controller ja nix. Der wird schön programmiert und ist zufrieden - zum
glück gibt es ja das verify, dass das verflixte Bit aus dem Controller
zurückliest und - oh - zufälligerweise an exakt die gleiche stelle in
deinen pc arbeitsspeicher schreibt - was ein glück, dass dein
arbeitsspeicher so arbeitet! und natürlich kommt das gleiche heraus -
und die checksumme berücksichtigen wir mal nicht - die stört ja sowieso
nur :-)
Aber mal ehrlich, wenn ich so einen 75 % bei meiner Firmware entdecke
beschuldige ich doch nicht den Arbeitsspeicher meines PCs ;-)
Überleg dir mal: Dein uC hat auch einen RAM und der ist beim Start
deines Controllers uninitialisiert - jedes mal, wenn du die spannung weg
nimmst und wieder anlegst, kippen die bits im ram neu - und du hast da
ein anderes bild. Vielleicht benutzt du ja eine uninitialisierte
Variable oder einen uninitialisierten Pointer... das kann mal gut gehen,
mal nicht...
;-)
have fun!
>Beim Stecken/rausziehen des Programmierkabels berührst du die offenen>Eingänge, speist kurz Ladung ein und das Programm liest wieder den von>dir erwarteten Wert... bis wieder zufällig was kippt und du erneut>umflashst/berührst...
Das ist ja genau das was Karl Heinz oben schon erwähnt hat.
Beispiel:
Das Programm enthält Routinen zum Empfang per UART.
Im Endprodukt braucht man die aber nicht mehr.
Sie bleiben aber trotzdem drin. Macht ja nix.
Der Empfang erfolgt per Interrupt. Die Interrupt Routine
checkt aber z.B. die Arraygrenzen für den Empfangspuffer
nicht ab. Dann wird noch der Pin für RxD nicht mit
externem oder internem Pullup beschaltet und floatet vor sich hin.
Irgendwann im Betrieb kommt irgendwas dem RxD Pin zu nahe und
löst dauernd den RxD Interrupt aus. Folge: Der Pointer für den
Empfangspuffer läuft Amok im RAM.
Das sind zu viele Zufälle um an solche zu glauben.
Ich halte das definitiv für einen Programmierfehler.
Bitte sag uns noch, von welcher Firma Wir keine Geräte mnehr kaufen
sollten.
Frank
So jetzt hat jeder mal seinen mehr oder weniger vorbelasteten Senf dazu
abgegeben.
Durchaus kann der Inhalt eines Memory durch verschiedene Probleme
ungewollt den Zustand ändern.
Das sehen wir des öfteren in Logdateien von Servern die ECC Memory
benutzen.
Von noch harmlosen "Correctable Memory Error" bis auch zu "Uncorrectable
Memory Error" ist da alles dabei.
Wobei der erstere Typ ja bei ECC erstmal keine direkten Probleme
verursacht, sondern man sollte nur sehen wie häufig das auftritt und
durchaus proaktiv mal den Speicher ersetzen. Bei manchem Hersteller ist
solches Verhalten auch durch Firmware beinflussbar.
Beim uncorrectable Error kommt es nun darauf an, in welchem
Speicherbereich das ganze passiert. Tritt es im Programmcode vom Kernel
auf rauscht die ganze Maschine in den Abgrund, Tritt es "nur" in einem
Userprogramm im Programmcode auf stürzt der Prozess mit verschiedenen
Auswirkungen ab.
Auf vielen PC's wird meines Wissens nach ohne ECC Memory gearbeitet,
teils weil es das Motherboard nicht unterstützt, neuere Boards bieten
aber inzwischen häufiger an ECC zu unterstützen, oder weil ECC auch ein
Kostenfaktor ist.
Wenn der Rechner nun ohne ECC Memory betrieben wird, können Memoryfehler
durchaus vorkommen ohne dass sie vom Betriebssystem oder der Applikation
erkannt werden, ausser es wird Programmcode oder Daten so verändert das
es unzulässige Speicherzugriffe oder dergl. ergibt.
Also wer hier generell behauptet das könnte nicht vorkommen setzt hier
schon mal Scheuklappen auf.
Je nach Zustand/Alter des PC's dürfte die Wahrscheinlich sich erhöhen
dass man einem solchen Fehler aufsitzen kann.
Das Szenario wurde ja wie folgt beschrieben:
Schritt1: hex-file von Disk lesen
Schritt2: µC programmieren mit Daten aus dem Memory
Schritt3: Verifikation mit den hexfile-Daten im Memory
Schritt 2 + 3 entsprechend Anzahl der zu programmierenden µC
wiederholen, ggf mit Pausen dazwischen was das Risiko weiter erhöhen
kann,
da selbst ein Rechner der "nichts tut" schon ziemlich viel macht.
Ggf. laufen noch andere Vorgänge die durchaus Seiteneffekte hervorrufen
können. Einige der beobachteten Speicherprobleme bei Servern liessen
sich dadurch mindern oder beheben indem die entsprechenden Memorymodule
gezogen und neu gesteckt wurden, was auf schlechten Kontakt schliessen
lies.
Nachdem die Daten demzufolge nicht immer wieder auf ihre Konsistenz
geprüft wurden bei jedem neuen Vorgang ist das angefragte Szenario
nicht unmöglich. Über die Wahrscheinlichkeit kann man dann auch noch
tagelang diskutieren.
bob schrieb:
> Nachdem die Daten demzufolge nicht immer wieder auf ihre Konsistenz> geprüft wurden bei jedem neuen Vorgang ist das angefragte Szenario> nicht unmöglich. Über die Wahrscheinlichkeit kann man dann auch noch> tagelang diskutieren.
Doch werden sie! Der Programmer liest das programm einaml zurück um zu
prüfen ob das programmieren gklappt hat und es gibt eine Chekcsumme. Ein
gekiptes Bit im Arbeitsspeicher oder eins im Kontroller ist dabei egal
es sollte auffallen... es sei den das Verify arbeitet nicht korrekt!
Die passiert bei JEDEM programmiervorgang.
Schon lustig, das hier zu lesen. Trotz vieler Fehler beim Programmieren
ist es mir nie gelungen, einen Bitfehler im PC nachzuweisen :-)
Meine Empfehlung: den µC-Code mit einer Prüfsumme zu versehen und diese
beim Programmstart zu verifizieren. Mir ist es lieber, wenn ein Programm
nicht startet, als wenn es mittendrin 'spinnt'. Das war bei den
BASIC-Interpretern seinerzeit ein großes Manko: Schreibfehler fielen
erst dann auf, wenn die Programmstelle ausgeführt wurde - werden sollte.
Auch Daten in EEPROMs können defekt werden, sodaß Prüfsumme und doppelte
Speicherung auch sinnvoll sein können.
Gast schrieb:
> Schon lustig, das hier zu lesen. Trotz vieler Fehler beim Programmieren> ist es mir nie gelungen, einen Bitfehler im PC nachzuweisen :-)
Weil die üblichen Standard-PCs das meist in Form abstürzender Systeme
feststellen und defekte Daten nicht sofort als solche erkennbar sind.
Folglich ist es schon prinzipbedingt kaum möglich, das nachzuweisen. Und
wenn er dann mal im Bluescreen sitzt, dann ist bekanntlich Microsoft
Schuld, nach dem Motto "weiss ja jeder, dass Windows gelegentlich
abstürzt".
Anders sieht es aus wenn man mit Geräten mit ECC-Speicher zu tun hat.
Das sind letztlich die gleichen Speicherchips wie bei Desktops ohne ECC,
aber ein paar mehr davon. Da gut betriebene Server auch transiente und
korrigierte Speicherfehler an die Admins melden, kriegt man das bei
genug Servern ab und zu mit.
@ A. K.
Vor "ewigen Zeiten" hat meine Tochter - damals 16 - ihren ersten PC
zusammengestöpselt. Das Ding stieg allerdings bei der
Betriebssystem-Installation reproduzierbar aus. Speicherriegel hin- und
hergewechselt; der Fehler wanderte. MEMTEST86 laufen lassen,
Fehler-Adresse aufgeschrieben, Riegel gewechselt, ...
Tochter hat Speicher zum Händler zurückgebracht und von Fehler
überzeugt. Neuer Speicher eigebaut, und siehe da: die Kiste lief
problemlos!
@ Karl heinz Buchegger
>>
Wenn also ein Fehler von 'alleine verschwindet', ohne das eine
nicht-esoterische Erklärung dafür gefunden werden kann, ist Feuer am
Dach. Erfahrene Programmierer richten sich dann schon mal auf eine lange
Nachtschicht ein, in der sie die uninitialisierte Variable, den
Pointer-der-in-den-Wald-zeigt, den Array-Overflow der den Stack
zerschossen hat etc. suchen gehen.
<<
Ob da eine Nachtschicht ausreicht??? Nach meiner Erfahrung kosten
derartige Fehler mindestens 2 (i.W. zwei) Wochen und verschleißen dabei
täglich mindestens einen Kollegen, der ausschließlich die Aufgabe hat,
die "Betriebsblindheit" des Fehler-Suchers zu kompensieren.
Bernhard
Bernhard R. schrieb:
> Ob da eine Nachtschicht ausreicht??? Nach meiner Erfahrung kosten> derartige Fehler mindestens 2 (i.W. zwei) Wochen und verschleißen dabei> täglich mindestens einen Kollegen, der ausschließlich die Aufgabe hat,> die "Betriebsblindheit" des Fehler-Suchers zu kompensieren.
Ich wollte Sandy nicht allzusehr frustrieren.
Aber die ganze Diskussion erinnert mich immer mehr an die berühmten
Compilerfehler, die ausgerechnet und ausschliesslich nur bei Newcomern
auftreten. Denn das eigene Programm ist ja 100% korrekt.
Aber ich bin da jetzt sowieso raus. Wenn Sandy unbedingt an ihren
Speicher-Bit-Fehler im PC glauben will, soll sie das tun. Die
Wahrscheinlichkeit dafür, dass es tatsächlich so etwas war ist nicht 0,
allerdings auch nicht grossartig größer als 0. Die Erfahrung zeigt, dass
in 9999 von 10000 Fällen sporadisch auftretendes seltsames Verhalten
praktisch immer auf einen noch nicht entdeckten Programmfehler
zurückzuführen ist. Und daran halte ich mich im Zweifelsfall. Ich halte
die Bit-gekippt Variante für nicht besonders seriös, aber das Gegenteil
wird sich nicht beweisen lassen.
Nun, nachdem, wie schon häufig bemerkt wurde, keine gesicherten Aussagen
darüber getroffen werden können was nun wirklich im µC war ist alles im
Reich der Spekulation.
Ich sage ja nicht dass es so war, aber es ging ja um die Frage ob es
jemandem schon passiert ist, also ob es potentiell passieren kann.
Und nachdem dass in unserem Rechenzentrum nicht selten vorkommt,
wir betreiben mehrere hundert Server.
Wir haben mit Fehlern im Main-Memory, CPU-Cache usw. teilweise auch
länger zu tun bis der Hersteller dann den Austausch durchführt.
Teilweise treten Memoryprobleme auch erst zutage wenn man mehr Memory
als
normal benutzt, oder die Last steigt. Manchmal gibt es Probleme ohne
dass eine Fehlermeldung zu finden ist oder Diagnosesoftware etwas
findet. Wenn man Glück hat ist der Fehler persistent und lässt sich
beliebig wiederholen, manche Fehler sind aber auch "Eintagsfliegen".
Es gibt durchaus auch im Bereich von RAID-Systemen oder Filesystemen
ähnliche Probleme.
Bislang ist mir nur ein "self-healing" filesystem bekannt, alle anderen
liefern entweder korrumpierte Daten oder das ganze Filesystem hat schon
in sich Probleme das die Dateistruktur nicht mehr funktioniert.
Das merkt man dann meist erst wenn der Fehler schon lange drin steckt da
man ggf. nicht so oft auf die Daten zugreift.
In der heutigen Zeit sind solche Probleme auch für jedermann eine Gefahr
wenn man nur noch digitalisiertes Material (Urlaubsfotos usw.)
aufbewahren muss.
Allerdings dürfte sich das Problem bei Festplatten wohl durch "false
writes" ergeben oder anderen "logischen Fehlern" (bugs) im Code für
Festplatten oder Filesystemzugriffe.
> Aber die ganze Diskussion erinnert mich immer mehr an die berühmten> Compilerfehler, die ausgerechnet und ausschliesslich nur bei Newcomern> auftreten. Denn das eigene Programm ist ja 100% korrekt.
In der Hinsicht kann ich Dich beruhigen. Ich blicke mittlerweile auf
über 30 Jahre Programmiererfahrung zurück. Natürlich weiß ich und kann
es auch bestätigen, daß mindestens 99,9% aller Fehler im Programm zu
finden sind.
Ich habe aber auch schon undokumentierte Fehler in Compilern und in
Mikrocontrollern selbst nachweisen können. Der beschriebene Fehler wäre
der erste Fehler, für den ich den PC verantwortlich mache.
Ich finde das wesentliche wurde bereits von kundigen Leuten weiter oben
erwähnt:
Nämlich dass Speicherfehler bei heutigen PCs durchaus üblich sind. Dies
liegt daran, dass die Speicher mittlerweile unglaublich gross sind und
somit die Wahrscheinlichkeit steigt, dass irgend ein Bit kippt. Zum
anderen liegt es daran, dass die heutigen Speicher-Kondensatoren so
winzig klein sind und nur noch wenige Elektronen als Speicher haben,
sodass diese viel anfälliger auf kosmische Strahlung (ja die penetriert
uns tatsächlich andauernd) sind.
Fakt ist: Bei heutigen PCs kippt immer wieder Mal irgendwo ein Bit. Im
Normalfall fällt das Niemandem auf. Deshalb ist es heute für Server
immanent, dass diese ECC-RAMs haben. Früher war das nicht so wichtig, da
die Speicher eben noch stabiler waren. Mittlerweile haben sogar die
Cache-Lines der CPU's ECC.
So gesehen ist das obige Szenario auf den ersten Blick gar nicht soo
unwahrscheinlich.
Unwahrscheinlicher macht es dann eben der Zufall, dass genau dort ein
Bit kippen musste, wo der Programmcode war.
Bzgl Verify:
Das gekippte Bit würde bei einem Verify nicht auffallen!!!
Da normalerweise die meisten Programmer die CRC immer laufend beim
Programmieren nebenher berechen. D.h. der PC würde dann einfach die
Checksumme des bitgekippten Programmcodes rechnen und dieser würde dann
natürlich mit dem CRC des uC übereinstimmen.
Selbst bei einem 1:1 Verify (alles zurücklesen) würde der Fehler nicht
auffallen, da ja eben der Programmcode im PC Speicher falsch ist.
Ulli schrieb:
> Nämlich dass Speicherfehler bei heutigen PCs durchaus üblich sind.
"Üblich" ist ein starkes Wort. Die meisten Server, auch solche mit zig
GB Speicher, erleben in jahrelangem Betrieb keinen einzigen Bitfehler.
> sodass diese viel anfälliger auf kosmische Strahlung (ja die penetriert> uns tatsächlich andauernd) sind.
Wobei die klassische Quelle von strahleninduzierten Bitfehlern jene
Strahlung ist, die vom Gehäusematerial der Chips selbst produziert wird.
Nicht die Umweltradioaktivität.
> immanent, dass diese ECC-RAMs haben. Früher war das nicht so wichtig, da> die Speicher eben noch stabiler waren.
Umgekehrt. Die Zuverlässigkeit ist trotz gesteigerter Kapazität
gewachsen. Anfangs war die Strahlung des Gehäusematerials viel grösser
als heute.
> Selbst bei einem 1:1 Verify (alles zurücklesen) würde der Fehler nicht> auffallen, da ja eben der Programmcode im PC Speicher falsch ist.
Allerdings müsste es sich dabei um eine Art automatisierter
Programmierung handeln, denn der Fehler ist ja nicht nur einmal
aufgetreten. Normale Programmierung ist ein einzelner Vorgang, d.h. das
zu programmierende File wird jedesmal neu geladen, da ist das kaum
möglich.
>>"Üblich" ist ein starkes Wort. Die meisten Server, auch solche mit zig>>GB Speicher, erleben in jahrelangem Betrieb keinen einzigen Bitfehler.
OK "üblich" ist relativ. C't hat's Mal ausgerechnet und da kam man dann
je nach PC auf einen zu erwartenden Fehler von 0.5-3 Jahren.
Das Server eine bessere Quote haben ist auch klar, da diese
normalerweise mehr Luft übrig lassen und nicht an die Grenze des
Möglichen gehen, da eben Lebensdauer und Langzeitstabilität wichtiger
sind. Zudem sind die Boards und Ihre Umgebung meist besser designt.
>>Umgekehrt. Die Zuverlässigkeit ist trotz gesteigerter Kapazität>>gewachsen. Anfangs war die Strahlung des Gehäusematerials viel grösser>>als heute.
Kommt darauf an, wie weit du zurückgehst. Es werden nicht ohne Grund
z.B. für Weltraumelektronik (stark erhöhte Strahlen-Belastung) auch
Heute noch riesige "alte" Strukturen verwendet.
>>Normale Programmierung ist ein einzelner Vorgang, d.h. das>>zu programmierende File wird jedesmal neu geladen, da ist das kaum>>möglich.
Wie bereits erwähnt wurde, wurde während des Programmierens nichts mehr
von der HD nachgeladen. Selbst wenn die Programmier-SW so geschrieben
wäre, dass Sie jedesmal das File neu laden würde, würde der Cache des
Betriebssystems das abfangen.
Hab mir gerade noch ein Paper dazu reingezogen. Interessant ist, dass
die Fehlerrate stark von der Höhe abhängt (mehr kosmische Strahlung)
>>Error rates rise with altitude: SER is 5 times as high at 2600 feet as >>at sea
level, and 10 times as high in
>>Denver (5280 feet) as at sea level [26]. “SRAM tested at 10,000 feet >>above sea
level will record SERs
>>that are 14 times the rate tested at sea level [11].”
>>Wobei die klassische Quelle von strahleninduzierten Bitfehlern jene>>Strahlung ist, die vom Gehäusematerial der Chips selbst produziert wird.
Laut Wiki stimmt das nicht wirklich:
Electrical or magnetic interference inside a computer system can cause a
single bit of DRAM to spontaneously flip to the opposite state. It was
initially thought that this was mainly due to alpha particles emitted by
contaminants in chip packaging material, but research [6] has shown that
the majority of one-off ("soft") errors in DRAM chips occur as a result
of
background radiation, chiefly neutrons from cosmic ray secondaries which
may change the contents of one or more memory cells, or interfere with
the
circuitry used to read/write them.
A. K. (prx) schrieb:
> Normale Programmierung ist ein einzelner Vorgang, d.h. das> zu programmierende File wird jedesmal neu geladen, da ist das kaum> möglich.
Siehe: Beitrag "Re: Bit im PC-Arbeitsspeicher beim Programmieren gekippt?"
Da schrieb Sandy:
> Beim Starten der Programmierumgebung wurde die Platte nur einmal> gelesen. Danach kamen alle Daten aus dem PC-Arbeitsspeicher.
Gruß,
Frank
Es kommt ganz darauf an, welches Programmiertool verwendet wurde.
Und bezüglich cache, kommt es auch drauf an, ob dieser nicht durch
andere Lesevorgänge anderweitig verwendet werden musste. Wenn ja, wird
der Cache für weitere Programmiervorgänge wieder von der Platte befüllt.
Das gleiche ist auch, wenn das System Speicher benötigt und diesen nicht
mehr frei hat. In diesem Fall wird Cache/Speicherinhalt auch gerne auf
die Platte geswapt.
Nur so als Idee.
Kann ich insoweit bestätigen, als in meiner Server-Praxis harte Fehler
häufiger sind als temporäre. Besonders bei einer Reihe aus 2 Dutzend
gleichen Servern, die mittlerweise an die 5 Jahre alt sind und bei denen
innerhalb der letzten Monate reihenweise defekte Speichermodule
aufgetreten sind.
Erkennbar ein Serienfehler mit Zeitzünder. Aber die Uhr in dem Zünder
läuft zu schnell, denn die Wartung läuft 5 Jahre. ;-)
Die übrigen Server (andere Fabrikate, teils bis zu 10 Jahre alt) sind
dagegen viel friedlicher als die verlinkte Statistik hergibt. Aber so
ist Statistik eben - meistens ziemlich friedlich wird sie durch einen
Seriendefekt wieder ausgeglichen. ;-)
