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?
Vieleicht war ja genau da irgendwie EMP eventuell außerirdische oder ein kleiner Quasar??
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
Ich würde auf die Illuminaten tippen - oder die Freimaurer!!
>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
Btw; ist in den Hex-Daten nicht eine Prüfsumme mit drin? Und überprüft der Programmer (welchen verwendest Du?) diese nicht beim Brennen?
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.
@ Christian H. Leider wurden alle Spuren vernichtet (dafür aber das Projekt gerettet und den Kunden glücklich gemacht).
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.
> das zu programmierende File wird jedesmal neu geladen
aus dem Dateicache im RAM
>>"Ü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.
Ich muss die Diskussion noch mal wieder aufwärmen: http://www.heise.de/newsticker/meldung/Hauptspeicherfehler-sehr-viel-haeufiger-als-bisher-angenommen-828883.html Und jetzt? _.-=: MFG :=-._
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. ;-)
Toll, der Link steht zwei Posts weiter oben schon mal... _.-=: MFG :=-._
sorry, hatte extra durchgeblättert und ihn trotzdem übersehen :-(
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.