Ultra 80: Problem beim Laden des Solaris 64-Bit Kernels

[escimo]

Zumindest kann ich jetzt erst mal wieder eine Woche in FaM über Möglichkeiten nachdenken und nächstes WE mal schaun, ob mir bis dahin ein Licht aufgegangen ist, oder jemand anderem.

Die Frage an dieser Stelle, gehe ich jetzt noch ins Bett oder bleibe ich gleich wach bis mein Zug fährt? - Ja, so machen wir es.

Gruß
escimo

[escimo]

So funktioniert laut Sun der Boot-Prozess auf einem SPARC-basiertem System bei einem Solaris kleiner Version 10 vereinfacht:
[1] Boot PROM Phase

• PROM führt POST aus
• boot -Routine des PROM lokalisiert die Boot-Methode (z.B. Festplatte oder Netzwerk)
• boot liest vom Boot-Medium das Programm bootblk
• boot lädt das primäre Boot-Programm bootblk zur Ausführung und übergibt Kontrolle

[2] Boot-Progamm Phase

• bootblk beginnt mit dem Laden des sekundären Boot-Programms ufsboot vom Dateisystem und legt es im Arbeitsspeicher ab
• ufsboot lädt den zweigeteilten Betriebssystem-Kern genunix (Plattform-unabhängiger Teil) und anschließend kernel (Plattform-abhängiger Teil) als "unix" wobei die 64-Bit Variante dieser Kombination unter /platform/sun4u/kernel/sparcv9 zu finden ist.

Bei der Phase 2 scheitert es bereits. Während ich das schreibe, bin ich mir nicht mehr sicher, ob da überhaupt ein 64-Bit "genunix" lag. Zudem habe ich das System im 32-Bit Modus installiert. Eventuell fehlen alle 64-Bit-Erweiterungen. Ich will sofort wieder nach Hause! Wenn ich mich nur erinnern könnte. 

Beispiel eines anderen Solaris8-Systems:

Code: [Auswählen]

$ uname -a
SunOS **** 5.8 Generic_117350-39 sun4u sparc SUNW,****
$ pwd
/platform/sun4u/kernel/sparcv9
$ ls -l
total 6064
-rwxr-xr-x   1 root     sys      2182584 Jun 23  2006 genunix
-rwxr-xr-x   1 root     sys       893736 Jun 23  2006 unix
$ file genunix
genunix:        ELF 64-bit MSB relocatable SPARCV9 Version 1
$ file unix
unix:           ELF 64-bit MSB executable SPARCV9 Version 1, UltraSPARC1 Extensions Required, dynamically linked, not stripped

Zur Info dennoch den Rest:
[3] Kernel-Initialisierung

• Der Kernel liest die Konfigurationsdatei /etc/system zur eigenen Parametrisierung
• Der Kernel initialisiert sich und liest mit Hilfe des sekundären Boot-Programms ufsboot Modul-Dateien ein und lädt diese in den Arbeitsspeicher.
• sobald der Kernel genug Module (z.B. Geräte-Treiber, Dateisystem-Typen, Scheduling-Klasse ...) geladen hat, um das Root-Dateisystem zu laden, wird das sekundäre Boot-Prgramm ufsboot ausgeblendet

[4] Init-Phase

• kernel startet den Daemon-Prozess /etc/initinit (Link auf /sbin/init).
• init beginnt Informationen (Einträge) aus der Datei /etc/inittab einzulesen bis zum Skript sysinit; erst nach dessen Ablauf wird die Datei inittab weiter eingelesen und u.a. versucht auf die Konsole zuzugreifen
• init startet sogenannte "run controll" (rc) -Skripte, von denen jedes einzelne RC-Skript wiederum Skripte u.a. zum Einhängen (Mount) von Dateisystems uvm startet. Hierbei befinden sich S##<scriptname> (= Startskripte) und K##<scriptname> (Kill-Skripte) -Links in den jeweiligen Run-Level -Verzeichnissen (z.B. /etc/rc3.d/), die ihren Ursprung meistens im Verzeichnis /etc/init.d/ haben.

Hinweis: Diese Prozedur ist bis auf ein Paar Unterschiede in der Init-Phase mit Solaris 10 und höher identisch.

[escimo]

Bei der Phase 2 scheitert es bereits. Während ich das schreibe, bin ich mir nicht mehr sicher, ob da überhaupt ein 64-Bit "genunix" lag. Zudem habe ich das System im 32-Bit Modus installiert. Eventuell fehlen alle 64-Bit-Erweiterungen. Ich will sofort wieder nach Hause! Wenn ich mich nur erinnern könnte. 

Ok. Das war ein Irrtum. Es sieht genauso auf der Ultra 80 aus. In dieser Hinsicht ist alles ok. Auch die 64-Bit Pakete sind alle installiert.

[escimo]

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/messages

exura 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

[Sparky]

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?

Moin,
das kann nur jemand beantworten, der mit den Kernel sehr vertraut ist.
Meine Vermutung liegt darin, das durch den Kernel die Menge vorhandenen Speicher abgefragt (allocation) wird.
Davon dann ein Teil reserviert und überprüft wird. Das kann je nach Kernel möglicherweise mehr oder weniger sein.
Ich meine, das der 32er Kernel auf den alten SPARCs in der Lage war defekten Speicher auszublenden.
Ist genug Speicher vorhanden funktioniert das, ist der Speicher aber knapp bemessen dann gibt es Probleme.

Bei den vermeintlich defekten Modulen hilft oft die Radiergummi-Methode um diese zu "reparieren".
Einfach die Kontakte mit der rauhen Radiergummiseite reinigen.
Die Problematik liegt oftmals darin, das die Vergoldeten Kontakte anlaufen.
Ein weiteres Problem sind - wenn auch nur im 10tel Millimeterbereich - unterschiedlich dicke Speichermodule.
Die Kontakte im Speicherslot selber verlieren mit der Zeit auch ihre Vorspannung und das alles summiert sich dann auf.
Gruss
Jürgen

[escimo]

Moin Jürgen,

danke für deine Ideen. Die Kernel-Frage wird mir wirklich nur jemand mit genauerer interner Kenntnis beantworten können. Zumindest geht es jetzt wie es soll.

Das mit der "Radiergummi-Methode" klingt realistisch aber "unterschiedlich dicke" Speichermodule? Davon höre ich zum ersten Mal.
Hattest du jemals ein "abgemagertes" Speichermodul?

Gruß
Stephan

[Sparky]

Moin Jürgen,

Hattest du jemals ein "abgemagertes" Speichermodul?

Gruß
Stephan

...damit meine ich die Kontaktleiste des Speichermoduls.
SUN-Module sind da ziemlich konstant, aber Second-Source Module können davon abweichen.
Ich habe hier jede Menge Second-Source wie Data-RAM, Transcend usw.
Die lassen sich alle unterschiedlich leicht oder schwer in die Speicherslots einsetzen.

[escimo]

...damit meine ich die Kontaktleiste des Speichermoduls.

Ja das ist mir schon bewusst.

Du beziehst dich da auf kompatible Speichermodule anderer Hersteller. Die Module die ich hier einsetze sind alle original Sun-DIMMs. Bei denen erwartet man so etwas dann nicht.