Sun 3/50 - Problemboard 1 - Err 11: Parity error

  • Ich habe 2 Boards mit Ram Problemen. Hier gehts es um das erste mit Parity Error 11.

    Die Boards haben eine Ram Matrix aus 18x8 Ram Chips 41256 = 1 Bit x 256k Adressen.


    Meldungen an serieller Konsole:


    Parity Test

    Memory Size = 0x00000004 Megabytes

    Memory Test (Testing 0x00000004 MBytes) Testing.

    Err 11: Parity Error at address 0x00186814

    Exp 0x5A972C5A, Obs 0x7A972C5A, Xor 0x20000000


    ---


    Ich habe darauf versucht, die Ram Matrix aufzudröseln, in dem ich einen Stecker (IC-Fassung) jeweils aufgesteckt hatte an dem DO mit VCC (+5V) über Widerstand auf High gezogen wurde

    und somit einen Ram Fehler hervorrief. Anhand der KOnsolen Fehlermeldung konnte ich sehen, wo/was sich ändert.


    Die Bit Pos habe ich im anliegenden LibreOffice Calc in einer Matrix erfasst. (Aller erste Alpha Version!)

    Die Adresse in Spalte A dürfte nicht von Relevanz sein hier, da durch den Fehlerstecker ALLE Adressen an diesem Bit/Chip fehlerhaft sind!

    Wenn man die Rückseite vor sich hat ist die Ram Matrix hinten rechts.

    Von links nach rechts kommen erst 8 RAM Bits, dann ein Parity Ram/Bit. Dann wieder 8 RAM Bits, dann ein Parity Ram/Bit.


    Und die Ram Bits und Parity Bits scheinen sich dann zu wiederholen?! D.h. die unteren 4 Reihen wiederholen sich in der oberen 4 Reihen (und/oder umgekehrt).


    (Man sieht, verstanden habe ich das noch NICHT)


    Braucht man das um Parity Fehler zu erkennen (bzw. ggf. sogar zu korrigieren?


    ---


    Die Frage bleibt, wie man heraus findet, welches / welche Ram Chips defekt sind.


    VG Peter

  • Ich habe die xor 0x... mal durch D1..32 ersetzt.

    Jetzt wird es etwas klarer.

    Es gibt D1 bis D32 = 32 Bit Datenbus.

    Jedes Datenbit gib es genau 4 mal (aber an unterschiedlichen Adressen!):

    4 x 256kbit x 4 (x 8 bit) = 4 MB - passt also.


    Xor 0x20000000 von der Fehlermeldung oben entspricht schon mal Datenbit D30 in Reihe 15 = 4 mögliche Chips.


    Jetzt werde ich an den jeweils 4 x D1 z.B. sehen, welche Adressen dann dort bei einem Fehler gemeldet werden.


    Frage: Bedeutet Parity Fehler hier, das ein Ram Chip oder ein Parity Chip defekt ist?

    (Es gibt bei dem 2ten Board Err 2: Ram Error at Addr...)


    VG Peter

  • Also ich würde "Parity Error" immer als Fehler im normalen RAM lesen. Es muß aber irgendwo Infos zum "Err 11" geben. Das ist vielleicht einfacher die zu suchen als rumzurätseln.


    Daß jedes Bit wirklich 4x da sein soll schient mir auch für Sun Verhältnisse ein wenig übertrieben. Später zumindest gibt es das nicht mehr, da ist das nur noch normales ECC RAM und der Faktor 4, der auch da auftaucht, bezieht sich immer darauf, daß es i.a. 4 Banks sind die parallel angesprochen werden - also Datendurchsatz erhöht, aber nicht Sicherheit.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Zitat

    Parity Test

    Memory Size = 0x00000004 Megabytes

    Memory Test (Testing 0x00000004 MBytes) Testing.

    Err 11: Parity Error at address 0x00186814

    Exp 0x5A972C5A, Obs 0x7A972C5A, Xor 0x20000000

    ^ da fehlen doch sicherlich Zeilen beim Output, vor den Meldungen?


    Mindestens die beiden Manuals könnten sich durchaus auch als nützlich für weitere Analysen erweisen:


    Sun 3 Customer Maintenance Training Manual

    Sektion IV, S. 4-4f gibt Infos u.a. über die Selbsttestdiagnose und auch die Verbindung über serielle Konsole unter Nutzung der SIO-A (ist hier schon realisiert) preis.


    Err 11 sieht wie eine Test- oder Subtest-Nummer aus, ein Teil des Memory Test oder Parity Error Test.


    0..11, dann wäre 11 der 12. Test


    "12 PARITY ERROR TEST - writes then reads to a specified address to verify that writing and reading does not cause a parity error. A second part of this test sets the parity test bit in the parity register so that it generates incorrect parity. A write then read will be executed in sequence to the specified address and will expect to generate a parity error. This is the last test reported to the LEDS"


    Dummerweise fehlt Sektion VIII (8) zur Sun 3/50, die u.a. beschreibt, was in dem Fall zu tun oder zu eben nicht zu tun sein könnte.


    Sun-3 Architectur Manual Ver 2.0 May 85


    S.26ff, Kapitel 5.5 Memory Error Registers


    ----


    Was zeigt das 8-Bit LED-Anzeigefeld des Boards von links gelesen? Bei Memory Test sollte 0000100 aufleuchten. Muster 00000001 bedeutet Fehler. Sieht man überhaupt was, wenn auf SIO-A umgeleitet wird? Neuere Non-VME Systeme habe, i.d.R kein LED-Feld mehr (exkl Sun386i). Eigentlich schade.


    Wenn man ggf die Werte der EEPROM Adressen 0x14 (# MB installed memory) und 0x15 (# MB to selftest) anpasst, ist man u.U. im NORM Modus auch in der Lage die Position weiter einzugrenzen. Für DIAG-Modus wird das ignoriert und alles getestet. Sind Bänke überhaupt ausgeschildert auf dem Board? Für bspw die späteren Sun-4 Systeme konnte man anhand der virtuellen Adresse schon sehen welche Bank, welches SIMM Probleme macht, sofern die Doku (Field Service Manual) passend nebenbei lag.

  • Auf dem Board ist ja leider nichts ausgeschildert woraus man eben von einer Adresse auf den Defekten Chip kommen könnte.


    Ja. Leider fehlt genau das Kapitel für die Sun 3/50.


    Wie oben schon ausgeführt:

    32 Chips für die Datenbreite von 32 Bit. Da 256kbit Chips macht das:

    256kbit x 32 / 8 = 1MB.

    Das 4 x ergibt 4 MB.


    Jetzt muss ich nur noch ermitteln, wie ich von der Fehleradressse zu genau dem einen der vier Chips komme.


    Das die Err Nr. eine Testnummer ist,

    Ist schon mal ein guter Hinweis.

    Würde heißen, das jeweils immer der gemeldete RAM Chip defekt ist.

    (Was die Frage aufwirft, was wenn der Parity Chip defekt ist?)


    Und das Ganze in DIAG Modus.


    VG Peter

    github.com/petersieg

  • Zitat

    Jetzt muss ich nur noch ermitteln, wie ich von der Fehleradressse zu genau dem einen der vier Chips komme.

    Das die Err Nr. eine Testnummer ist,

    Ist schon mal ein guter Hinweis.

    Würde heißen, das jeweils immer der gemeldete RAM Chip defekt ist.

    (Was die Frage aufwirft, was wenn der Parity Chip defekt ist?)


    Das sind ja bestimmt virtuelle Adressen, so wie üblich bei den (proprietären) Sun MMU - Implementierungen. D.h. die Adresse die man beim Test bekommt ist wahrscheinlich keine physikalische Adresse. Das muss nicht bedeuten, das ein Mapping nicht teilweise von virtuell auf physikalisch schließen liese. Wie das geht, beantwortet u.a. auch wieder das Sun-3 Architecture Manual Ver2.0 oder im "Sun-3 Customer Maintenance Training Sep88, S. 1-6 bis 1-14".


    Ich würde es auch gern verstehen: Reihe 15? - Das mit dem 4x vorhanden kommt mir irgendwie bekannt vor aus dem SPARCstation-1 Programmers Model Jul89

    Liese sich ggf. die Positionierung/Lokalisierung nicht anhand der Board-Vordrucke exakter angeben?

    Bspw - keine Ahnung ob das so hinkommt - sowas wie die nachfolgende Anordung


    Zitat

    Err 11: Parity Error at address 0x00186814

    Exp 0x5A972C5A, Obs 0x7A972C5A, Xor 0x20000000

    Expected, Observed, Xor-Wert/Diff

    0x [0010] [0] [0] [0] [0] [0] [0] [0]

    Was für Auswirkung und Fehlerursache ein "parity error" haben kann, hat mir G***** hier ausgespuckt. Könnte durchaus ein defektes DRAM-DIP sein, "cell leakage"? - Aber k.A., ich nix HW. Soll eher eine Anregungen schaffen für Dich/euch. :)

    https://www.techwalla.com/arti…fix-a-memory-parity-error


    Was zeitgt die LED aus im DIAG-Modus an? (würde mich grundsätzlich interessieren)

    https://www.sun3arc.org/Errormsg/3_50error.phtml


    Ich versuche mal für mich die Position aufzudrösseln

    Einmal editiert, zuletzt von escimo () aus folgendem Grund: [0000.0010] -> [0010] 8Bit -> 4Bit (2^4 = 16 Zustände)

  • Mich würde auch interessieren, was die LED Anzeige dazu sagt.



    Außerdem: Kommt der Error selbsttätig (wird einfach so angezeigt) oder bekommst Du den nur, wenn Du bereit im Diagnostic Program bist ?



    Zu MMU: Ich würde mal vermuten, daß man innerhalb des MemoryDiagnostic Tools kein Paging nach irgendwohin macht, man sollte da (vermutlich) einfach lineare Adressen haben, die dann auch immer an den gleichen Stellen in den RAMs sind.


    Die "DusselVariante" da jetzt was rauszubekommen wäre evtl. mal mit dem Diagnostic ( -> x + Return) Tool zu versuchen alle Stellen zu finden, evtl ist es ja auch nur die eine und dann dort einen massiven Filltest in diesem Speicherbereich (?) laufen zu lassen, also z.B. 100 Wiederholungen, dann kann man evtl. schon am Warmwerden der Chips die Tabelle aufbauen. Eigentlich muß man ja nur mal für eine der 4 Bänke rausbekommen, wie das so aufgebaut ist.


    Bei "Err 11: Parity Error at address 0x00186814" ist ja eigentlich sogar auch bißchen unklar, worauf sich die Nummer nun bezieht. Ob das nun Bytes sind oder nicht evtl. der Logik im Aufbau folgend die Adresse in 32Bit durchnummeriert.




    Interessantes Thema, irgendwie. Wäre ganz einfach zu lösen, wenn das Kapitel 8 aus dem Manual auftauchen würde. ;)


    So wie sich das in den Service Manuals liest, war das aber auch ein Thema, was der "Field Technician" nicht angefaßt hat. Der hatte wohl nur die Aufgabe, das richtige (kaputte) Memory Board zu finden und zu tauschen. Und je nachdem haben sie das dann vielleicht einfach weggeworfen.


    Auch die alte SUN FAQ hat da irgendwie nix Erhellendes zum Thema

    http://www.sunhelp.org/faq/sunref1.html

    bzw.

    http://www.sunhelp.org/faq/sunref4.html


    vielleicht ja aber die Seite obendrüber. Da findet sich manchmal solches Info"Zeugs". Google und Co schwiegen sich mittlerweile auch zu Sun Skizzen und Techinfos aus, leider.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Hatte etwas Zeit..

    Habe den Fehlerstecker nacheinander auf D30 Ram-Chip von "unten" nach "oben" gesteckt - siehe testlog.txt (---- xxx ---- Zeilen habe ich eingefügt).

    (Unten = zur Rückseite hin; Oben = zum P3 Stromstecker hin)

    1+2 sind Hardcopies von minicom.

    diag-leds zeigt die Leds nach der Fehlermeldung.


    Ich verstehe die gemeldeten Adressen einfach überhaupt nicht!?

    Wenn ich einen Ram Test und eine Fehlermeldung programmiere, so möchte ich doch, das man möglichst direkt und einfach auf den defekten Chip schließen kann..?


    Einzig die Xor = Datenbits erschließen sich mir (scheint zumindest so ;) )


    Wenn ich die im Fehler gemeldete Adresse nehme und 1MB abziehe, so sollte der Fehler in der 2ten "1MB-Bank" sein.

    Damit wären es nur noch 2 Chips, da mir immer noch nicht klar ist, ob Bank1 unten oder oben liegt :(

    Siehe LibreOffice Calc Hardcopy.


    Falls mich sonst niemand weiter erhellen kann, wie man von der Adresse, den defekten Chip ermittelt,

    werden ich wohl die Tage mal mich den 2 Chips im Verdacht widmen - Ist ja eine 50% Chance und danach 100% ;)

    (Oder ich bin halt völlig auf dem Holzweg)


    VG

  • Kommt das Bild Nr 2 so wie angezeigt ?? Dann ist das vielleicht ja auch gar kein RAM Fehler.

    Deswegen war auch die Frage nach den LEDs. Meiner Meinung nach würde Bild 2 auch nicht zum gezeigten LED Bild passen.


    Begründung: das LED Bild zeigt nach Tabelle

    https://shrubbery.net/~heas/su…01_Sun-3-50-SelfTest.html


    einerseites einen durchgelaufen Systemtest, der Position 16 (Memory) erreicht hat = LED 5 ist ON und der dann dabei hängenbleibt = LED 8 ist ON. Beides paßt dann auch zu dem Error 11 der ausgegeben wird (was immer er genau heißen mag, aber da ist auch die Bildschirmanzeige soweit daß sie am Memory Test angelangt ist).


    Dagegen scheint auf Bild 2 irgendwie mehr im Argen zu sein. Das ist irgendwie ein richtiger CPU oder MMU Fehler. Es sieht ja auch so aus, als würde der den gesamten Selbsttest nochmal starten. Und dann doch den Error 2 wieder finden. Wenn das das Bild vom künstlichen Fehler ist, dann bildet der irgendwie den eigentlichen Fehler nicht direkt nach.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Einmal editiert, zuletzt von ThoralfAsmussen ()

  • Vielleicht kann man auch mal den Jumper auf J108 Pin 1-2 entfernen. Dann läuft die Maschine ohne Memorytest hoch. Und man kann vielleicht gezielter selbst testen.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Ja scheint so: das LED-Bild mit...


    0000*00* Test 16 Initiates memory tests Resident memory + Self test error report / CPU


    ... passt nicht zum häufiger auftretenden Fehler beim Memory Path Data Test, auch Bestandteil des Memory Test

    Memory Path Data Test

    Err 2: Addr 0x00000404, Exp 0x00000000, Obs 0x20000000, Xor 0x20000000

    bzw.

    Memory Path Data Test

    Err 2: Addr 0x00000400, Exp 0x00000001, Obs 0x20000001, Xor 0x20000000


    Da hätte ich sowas erwartet...


    ***0000* Test 7 Checking memory data path resident momory + Self test error report / CPU


    Die Adresse des Parity Error könnte durchaus auf einen DIP im zweite MByte zeigen

    1 megabyte = 0x00100000 = 1048576 bytes

    megabyte #1 = 0x00000000..0x000FFFFF

    megabyte #2 = 0x00100000..0x001FFFFF -> 0x00186814

    megabyte #3 = 0x00200000..0x002FFFFF

    megabyte #4 = 0x00300000..0x003FFFFF



    NACHTRAG:


    Du könntest im Diag-Switch NORM starten und die EEPROM Pos 0x15 (# MB for selftest) auf 1MB begrenzen (wenn das überhaupt geht), dann den Memory Test durchführen. Wenn da keine Fehler auftauchen, also weder beim Memory Path Data Test noch Parity Test. ist das ... i.O. (?) :/ (das ist aber auch kompliziert)


    Der "Fehlerstecker" ist für mich im ersten, nicht im zweiten MByte aufgesteckt. Wenn du nach dem Schema ^ mit absoluten Positionen gehst, sollte dann dieser gebastelte Fehlerstecker nicht eher bei einem DRAM in der Reihe S..T anliegen?

    Einmal editiert, zuletzt von escimo () aus folgendem Grund: Nachtrag

  • Mit dem ersten MByte - das würde ich auch so sehen. Die Fehleradresse sollte nach aktueller Theorie in S+T sein.

    Das gilt aber auch nur, wenn die Annahme stimmt, daß die MBytes in "waagerechter" Reihe angeordnet sind, d.h. also immer zwei Zeilen (z.B. Q+R fürs erste MByte) zuständig sind. Bisher scheint mir das aber eine reine Annahme zu sein.


    Vielleicht sollte man auch mal den seltsamen Testaufsatz mit dem Widerstand entlang einer solchen Zeile bewegen. Vielleicht ändert sich ja dann ja auch die Adresse tatsächlch mal in der Fehlermeldung.


    Die Idee dahinter wäre, daß das erste MByte dann die 32 Chips am rechten Boardrand sind. Wenn dem so wäre, dann würde nämlich ein Umsetzen des Testers so wie jetzt gemacht, also immer auf D30 in verschiedenen "Höhen", genau den Fehler bringen, wie er jetzt auch kommt. Da für den Path Data Test geshiftet und verglichen wird, wäre ja, egal auf welchem D30 der Tester sitzt, das Testergebnis des Shiftens gestört und daher würde dann immer ein Fehler ganz unten gemeldet. Man würde natürlich möglicherweise dann auch eine $0000 und nicht ein $0400 als Adressangabe erwarten, aber wer weiß das schon.


    Hier als Anhang mal noch die komplette Seite aus dem Buch


    das hier ist eben nicht der normale Memorytest, sondern noch eine Vorstufe davon. Es wird auch nur geschaut, ob die Chip überhaupt da sind. Der Err11 dagegen käme dann aus dem Test 16 und der kommt erst später dran.

  • Bild 2 ist natürlich direkt gestern so aufgenommen (wie alle Bilder). Aber dazwischen wurde natürlich jeweils ausgeschaltet, dann erst der Fehlerstecker umgesteckt und dann wieder eingeschaltet.

    Nach jeder Fehlermeldung geht die Sun3 in eine Endlosschleife - so wie im Manual beschrieben.


    Diese „komischen“ Adressen 400/404 hatte ich ja schon im Calc Sheet für ALLE Positionen ermittelt!?

    (Aber natürlich nur einige Positionen wirklich und nicht alle 144)


    Wenn der Schalter auf NORM steht,

    Gelingt es mir NICHT durch senden von Break (CTRL-a-f) in den Monitor zu kommen.


    VG

    github.com/petersieg

    Einmal editiert, zuletzt von PeterSieg ()

  • HYB41256.pdf

    Zitat

    [...] in dem ich einen Stecker (IC-Fassung) jeweils aufgesteckt hatte an dem DO mit VCC (+5V) über Widerstand auf High gezogen wurde

    Begreife ich nicht. Könnt ihr mich bitte abholen: Data Out mit "Vcc/high" verbunden.

    Ich frage mich was passiert, wenn man Write Enable blockiert also auf "Vss/Ground/low" schaltet, so das es ein "Immer-Lesesmodus" (?) ergibt. Geht das auch so einfach? Dann würde jeglicher Schreibtest an diesen Speicherbereich scheitern und man die Position im Type-0 Address Space feststellen?


    Wäre wahrscheinlich genauso oder mehr Aufwand, aber man könnte die Theorien verproben, wie die Bänke in dem Schema ^ angeordnet sind.


    Mal andersrum gefragt: bekommt man Fehler beim Memory Path Data Test, wenn der Teststecker deinstalliert/raus ist?


    Zitat

    Mit dem ersten MByte - das würde ich auch so sehen. Die Fehleradresse sollte nach aktueller Theorie in S+T sein.

    Das gilt aber auch nur, wenn die Annahme stimmt, daß die MBytes in "waagerechter" Reihe angeordnet sind, d.h. also immer zwei Zeilen (z.B. Q+R fürs erste MByte) zuständig sind. Bisher scheint mir das aber eine reine Annahme zu sein.

    Klar, ist auch nur angenommen, könnte auch andersrum oder durchmischt sein. Weiß man halt erst, wenn man es schon weiß, es liest, verprobt, oder als Profi wahrscheinlich einfach einen geschulten Blick auf die Leitungen wirft. Ich gehöre in der Kategorie (leider noch) zur nicht aufgeführten Abteilung Debütant - ok Stümper, ich nix mit E-Technik:nixwiss:, und bin doch gewillt dazuzulernen, sofern es sich auch im kleineren Maßstab begreifen lässt. :grübel:

  • J0108 Jumper 1-2 entfernt - reduziert das zu testende Ram auf 2MB:

    Boot PROM Selftest


    PROM Checksum Test

    Context Reg Test

    Segment Map Wr/Rd Test

    Segment Map Address Test

    Page Map Test

    Memory Path Data Test

    NXM Bus Error Test

    Interrupt Test

    TOD Clock Interrupt Test

    MMU Access Bit Test

    MMU Access/Modify Bit Test

    MMU Invalid Page Test

    MMU Protected Page Test

    Parity Test

    Memory Size = 0x00000002 Megabytes

    Memory Test (Testing 0x00000002 MBytes) Testing.

    Err 11: Parity Error at address 0x00186814

    Exp 0x5A972C5A, Obs 0x7A972C5A, Xor 0x20000000


    VG

    github.com/petersieg

  • Heureka! 😀👍

    Habe zuerst den vermeintlich unteren - Mitte D30 Chip getauscht.


    Und… Trommelwirbel… läuft!


    D.h. Die Bit/Chip Positionen scheinen zu stimmen.

    Auch die Annahmen zu den 1MB „Banken“ und die Annahmen wo unten und oben ist auch.


    Danke an alle.


    VG Peter

  • Gegenprüfung ausgelötetes DRAM - meldet Fehler - wie zu erwarten war:


    Willkommen zu minicom 2.7.1


    Optionen: I18n

    Übersetzt am Dec 23 2019, 02:06:26.

    Port /dev/ttyUSB0, 13:50:59


    Drücken Sie CTRL-A Z für Hilfe zu speziellen Tasten


    DRAM TESTER 256Kx1 . FAILED 0x30D00



    VG

    github.com/petersieg