Ich habe mir mal die Zeit genommen die Hardware einer direkten Fehlersuche über den Austausch von Komponenten zu unterziehen. Dabei konnte mir das damals erworbene Ersatz-Mainboard einer E420R wertvolle Dienste erweisen.
Folgende Komponenten habe ich sequenziell ausgetauscht und nach der Durchführung des Boot-Vorganges (Test) wieder auf den alten Hardware-Zustand versetzt:
1. OBP einer Enterprise 420R mit identischer Firmware - Problem bestand immer noch
2. eine von Ebbi's neuen UltraSPARC-II 450MHz CPUs - Problem bestand immer noch
3. anderes Memory Riser Board mit einer bestückten Bank (4x 256MB DIMM = 1024MB) - Solaris 8 bootet mit 64-Bit Kernel
4. altes Memory Riser Board mit identischen Modulen (4) und identischer Bank - System bootet mit 64-Bit Kernel
5. altes Memory Riser Board mit anderen DIMM's in der selben Bank - System friert ein. Aha! Der Speicher ist der Übeltäter.
6. System wird über 32-Bit Kernel gestartet. - Mehrere Fehlermeldungen erscheinen wie im Thema "
Speicherproblem bei Ultra 80" bereits angegeben.
Da ich die Interna von Solaris (8/10) nicht kenne, stelle ich mir eine Frage: Warum lässt sich mit einem defekten DIMM - unabhängig von der Bank und weiterer funktionsfähiger DIMMs in benachbarten Bänken - Solaris mit dem 32-Bit Kernel booten, beim 64-Bit Kernel jedoch nicht? Warum tritt ferner dieses Verhalten bei Solaris 10 und höher nicht auf?
Die Beantwortung dieser Frage ist für mich alles andere als trivial. Darum stelle ich einige Vermutungen an:
A) für Solaris 10 auf SPARC-Plattformen existiert einzig der 64-Bit Kernel und dieser kann mit dem fehlerhaften DIMM umgehen, was der 64-Bit Kernel von Solaris 8 nicht schafft, weil dieser wiederum eventuell vor einem Check schon beim Booten darauf zugreift und damit der Boot fehlschlägt (?)
B) Solaris 10 besitzt das Feature "
Predective Self-Healing", welches Solaris in die Lage versetzt, den defekten Speicherbereich des DIMM (ECC, registered DIMM) noch vor dem ersten Zugriff für den weiteren Betrieb von Solaris auszublenden und stattdessen andere Speicheradressen anspricht.
C) Solaris 8 bootet den generischen Teil des Kernels (genunix) erfolgreich und beim Laden des Plattform-abhängigen Teils (kernel) in den beschädigten Speicherbereich mit Anschließendem Zugriff hängt sich das System "scheinbar" auf.
Wer andere Ideen hat, ich bin da sehr neugierig...
Hier ein Teil des Outputs der Datei
/var/adm/messagesexura genunix: [ID 540533 kern.notice] SunOS Release 5.8 Version Generic_117350-44 32-bit
exura genunix: [ID 913632 kern.notice] Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved.
exura genunix: [ID 678236 kern.info] Ethernet address = 8:0:20:f0:2c:19
exura genunix: [ID 389951 kern.info] mem = 1048576k (0x40000000)
exura genunix: [ID 930857 kern.info] avail mem = 1034420224
exura rootnex: [ID 349649 kern.info] root nexus = Sun Ultra 80 UPA/PCI (2x UltraSPARC-II 450MHz)
...
exura SUNW,UltraSPARC-II: [ID 550400 kern.info] [AFT0] Corrected Memory Error detected by CPU1, errID 0x00000030.1babe45d
exura AFSR 0x00000000.00100000<CE> AFAR 0x00000000.3d2c16c8
exura AFSR.PSYND 0x0000(Score 05) AFSR.ETS 0x00 Fault_PC 0x1007e024
exura UDBL Syndrome 0xa8 Memory Module U0301
exura unix: [ID 220797 kern.warning] WARNING: [AFT0] Sticky Soft err encountered on Memory Module U0301
exura unix: [ID 618185 kern.notice] NOTICE: Scheduling removal of page 0x00000000.3d2c0000
exura SUNW,UltraSPARC-II: [ID 183645 kern.info] [AFT0] errID 0x00000030.1babe45d Corrected Memory Error on U0301 is Sticky
exura SUNW,UltraSPARC-II: [ID 740803 kern.info] [AFT0] errID 0x00000030.1babe45d ECC Data Bit 23 was in error and corrected
...
<in Abständen wiederholt sich dieser DIMM-Fehler>
Die CPU erkennt, dass ein Bit-Fehler erfolgreich per ECC beseitigt werden konnte. -
Aber sind wir mal ehrlich zueinander meine "Kleine": du hast eine "64-Bit Solaris 8"-betriebsbedrohende Krankheit: das "UDBL-Syndrom 168". Das ist an sich unheilbar sobald es an der betroffenen "Funktionseinheit" auftritt. Da hilft nur eins: Amputation des defekten DIMM und anbringen einer funktionsfähigen DIMM-Prothese. Es tut mir leid aber eine andere Möglichkeit sehe ich nicht mehr.Man, dieses Problem zog sich über 4 Monate hin und dann liegt es an einem popligen DIMM. Da habe ich in den USA also wieder mindestens 50% Elektroschrott erworben. Klasse.
Gruß
escimo