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

[escimo]

Die Idee mit dem Kernel-Debugger ist mir auch gekommen, nur hast du damit schon gearbeitet ?

Öhhh, ... nein! - Ich versuche zumindest, es zu begreifen. Das kann nicht verkehrt sein. Danke für die Literatur-Hinweise Micheal. Das Buch von Frank Hofmann ist mir bereits bekannt, bin hier aber noch nicht groß in Versuchung gekommen. Hingegen das Buch von Chris Drake und Kimberly Brown ist mir neu. Das habe ich mir heute gleiche besorgt.

Moin Drusus!
Uff, du scheinst mit dieser Materie recht gut vertraut zu sein. Respekt. Um mal ein Paar Fragen deiner Seite zu beantworten:

Soweit ich das auf den ersten Blick sehe hast du aber (ausser der Grafikkarte) keine weiteren Karten eingebaut, richtig?

Im Moment ist verbaut: 1x 450 MHz CPU, 2 GByte RAM, XVR-1000. Im Normalfall - weil das leider keinen Unterschied gemacht hat - sind vier CPU's zu je 450 MHz/4MB eCache, XVR-1000 (UPA), SunPCi-IIpro (5V / 64-Bit / 33 MHz PCI-Slot) und eine Quad-FastEthernet (3,3V / 64-Bit / 66 MHz PCI-Slot) verbaut.

ich bezweifel, dass es etwas mit 32 vs. 64 Bit Kernel zu tun hat. Es kann aber sein, dass in den 64bit Versionen ein Treiber neu dabei ist,der sich hier aufhaengt (oder aber die CPU eine Macke hat).

Das wäre eine gute Nachricht.

Das "SPOR" in der ersten Anschaltmeldung steht fuer "Software Power on Reset" (d.h. da hast du einfach "reset" bzw. "boot" im OBP eingegeben). Das ist normal und harmlos.

Das habe ich bereits vermutet. Woher hast du denn diese Informationen (Bedeutung für die Abkürzung/Akronym)? 

Hast du an dem System kuerzlich was mit den CPUs gemacht? Z.B. Upgrade von 360 auf 450Mhz (erfordert einen Jumper auf dem Board umzustellen)?

Ein Upgrade nicht, aber einen CPU-Tausch (ich habe 4 450MHz CPUs) in Slot 2 (für 1-CPU-Konfiguration) habe ich mehrmals durchgeführt, da ich auch von einem CPU- oder Mainboard-Defekt ausgegangen bin. Im POST-Output weiter oben habe ich keine Abnormalität feststellen können.

Am Freitag werde ich mit den umfangreichen Angaben einen Versuch starten, da ich zur Zeit wieder in Frankfurt (Main) bin.

Vielen Dank. Bis dann.

Grüße
escimo

[Drusus]

Moin,

Das "SPOR" in der ersten Anschaltmeldung steht fuer "Software Power on Reset" (d.h. da hast du einfach "reset" bzw. "boot" im OBP eingegeben). Das ist normal und harmlos.

Das habe ich bereits vermutet. Woher hast du denn diese Informationen (Bedeutung für die Abkürzung/Akronym)? 

Ich weiss nicht mehr wo ich diese Sachen gefunden hatte. Ist schon eine Weile her als ich mich mal auf die Suche gemacht hatte was denn bei dem "prtconf -vp" Output die "reset-reason" Zeile zu sagen hat. Genau dort kommen dann naemlich auch diese Kuerzel vor.

Die mir bekannten:

SPOR = Software Power on Reset (reboot, reset im OBP etc.)
BPOR = Button Power on Reset (Einschalttaste auf der Tastatur oder am Geraet gedrueckt)
SXIR = Software external Reset (Watchdog Reset vom Solaris oder OBP)
BXIR = Button external Reset (haengt vom System ab, z.b. 3-5 Sekunden lang Powertaste gedrueckt halten oder so aehnlich)
FATAL = Hardware Defekt fuehrte zum Reset

Tschau,
  Drusus.

[escimo]

Danke für die Aufklärung über die Bedeutung der SC-Zeile Drusus.

Zur Verifikation versuche ich den kadb von Solaris 8 HW4 (2/04) mit dem 64-Bit Kernel zu nutzen:

Code: [Auswählen]

{0} boot kadb -d
Boot device: /pci@1f,4000/scsi@3/disk@0,0   File and args: kadb -d
kadb: /platform/sun4u/kernel/sparcv9/unix
Size: 361160+91197+77967 Bytes
/platform/sun4u/kernel/sparcv9/unix loaded - 0xea000 bytes used
stopped at     _start:     sethi     %hi(0x10006c00), %g1
kadb[0]: moddebug/W 0xe0000000
moddebug:     0x0     =     0x0
kadb[0]: :c
<Hänger - das war es dann wieder>

...<nach Neustart>...

kadb[0]: $<threadlist
                ============= thread_id     10408000
mutex_exit_critical_size+0x4ac:     data address not found
kadb[0]: $q
Type ´go´ to resume
{0} ok Das sieht aber kritisch aus. Was bedeutet das? Kann man da schon etwas erkennen? 

Gruß
escimo

[Drusus]

Moin,

die Aktivierung von moddebug hat nicht geklappt. Bei der Bestaetigungszeile im kadb siehst du, dass aus dem 0x0 ein 0x0 wurde (sich also nichts geaendert hat). Grunde dafuer ist das verwendete "moddebug/w" was aber ein "moddebug/W" sein muss (also grosses W statt dem kleinen).

Lass dich von dem Funktionsnamen (mutex_exit_critical_size) nicht verwirren. Das ist eine ganz normele Locking-Funktion. Was mich allerdings wundert ist die Tatsache, dass die verwendete Adresse nicht gefunden wird.
Auch diese Ausgabe (ebenso wie die vorherigen Informationen) deuten IMHO alle auf ein Problem mit der CPU hin...

Hast du wirklich zum Test nur eine 450Mhz CPU in Slot 2 (das ist der zweite Slot von oben)?

Ich kenn die Ultra 80 nicht so gut aber bei meiner Ultra 60 hatte ich einmal aehnliche Probleme (wobei das dann auch teilweise den Start generell also unabhaengig von 32 vs. 64Bit betraf). Das Problem dabei war, dass die Plastikfuehrungen der CPUs nicht ganz so exakt waren wie gewuenscht. In meinem Fall konnte man die CPU problemlos einsetzen, schoen verriegeln aber das Problem war trotzdem da. Ein genauer Blick auf die Platine hat dann gezeigt, dass bei dem CPU-Sockel auf dem Board (bei der U60 so ein brauner Querbalken) die Schlitze einmal durch Platisk unterbrochen waren (was normal ist) aber dieser Trenner schon auf beiden Seiten (durch das mehrfache CPU tauschen) angekratzt war. Das deutete dann auf Probleme mit der CPU-Fuehrung hin und ich hatte sie dann dadurch geloest, dass ich die CPU exakt gerade per Hand eingesetzt hatte und dabei nicht die beiden schwarzen Hebel an der Seite genutzt hatte (nur natuerlich nachher nochmal nachgedrueckt).
Eventuell hilft dieser Erfahrungsbericht hier ja auch (da bisher alles bei dir auf CPU (oder RAM) Probleme hindeutet).

Tschau,
  Drusus.

[escimo]

Hi Drusus,

du hattest Recht, ich hatte bis dato 4 CPU's verbaut. Jetzt habe ich wirklich nur eine CPU und den Grafikbeschleuniger zusammen mit 2 GByte RAM drin. Die Anzeige des kadb steht jetzt auf "kadb[2]". Ich habe das Beispiel von dir wiederholt. Jetzt mit diesem Ergebnis:

Code: [Auswählen]

kadb[2]: moddebug/W 0xe0000000
moddebug:     0x0     =     0xe0000000
kadb[2]: :c
<und tschüss>
Ich habe auch nochmal die einzige CPU in Slot 2 neu händisch eingesetzt bis kein Spielraum mehr war.

Ich setze den Debug mit kadb fort, in der Hoffnung auf den Fehler zu stoßen. Das ist nicht gerade der Weg des geringsten Widerstandes, doch das schreckt mich nicht. Ich stelle den Output von kadb hier zur Verfügung. Vielleicht hat noch jemand eine Idee, einen Vorschlag oder einen Tipp.

Grüße
escimo

[escimo]

Kennt sich wer mit den Solaris Kernel Internals etwas aus, vorallem mit dem Boot-Prozess im Detail? Ich bin jetzt dazu übergegangen mittels des kadb den Boot-Vorgang Steb-by-Step (einzelne Assembler-Anweisung) durchzunehmen, in der Hoffnung irgendwann die Anweisung (und damit die betroffene Routine/Funktion) ausfindig zu machen, die das Problem bei Benutzung des 64-Bit Betriebsmodus verursacht.

Beispiel für Anweisungsschritt:

Code: (asm) [Auswählen]

kadb[2]> :s
stopped at     
_start:     sethi     %hi(0x10006c00), %g1
Haltepunkte (Breakpoints) lassen sich auch prima setzen, wenn ich nur wüsste was noch so an Routinen aufgerufen wird. Oder anders: es dauert mir zu lange.

Lässt sich die Suche eventuell eingrenzen?

Der mdb (Modular Debugger) sollte bereits ab Solaris 8 verfügbar sein. Den habe ich bestimmt vergessen zu installieren. Das muss ich nächstes Wochenende unbedingt nachholen, falls jemand weitere Tipps für den mdb hat. Alternativ soll sich über den OBP ebenfalls ein Debugging (set forthdebug=1 in der /etc/system) durchführen lassen.

Grüße
escimo

EDIT: Ich habe gerade noch etwas zum kadb nachgelesen. Das war dann doch keine gute Idee. Siehe hier, Seite 67 "3.7.2.2 Implementation As a Kernel Module". Ich werde dann doch mal lieber auf den (k)mdb schwenken.

[escimo]

Wie kann ich den (k)mdb im OBP unter Solaris 8 aufrufen? Warum gibt es keine statisch-gelinkte mdb-Variante?

Installiert ist der Modular Debugger jedenfalls unter /usr/bin/mdb und /usr/bin/sparcv9/mdb als dynamisch gelinktes Programm. kadb ist statisch gelinkt und liegt unter /platform/sun4u/kernel.

Daran anschließend, wie lässt sich dann ein Hardware- oder Software-Bug komfortabel auffinden, ohne jede Instruktion über ":s" ("next Step" wie bei kadb) einzeln zu durchlaufen. Ich besitze keine genaue interne Kenntnis des Solaris 8/9-Kernels.

Gruß
escimo

[Drusus]

Moin,

mit Solaris 8 kam erstmal der mdb aber erst ab Solaris 10 gibt es auch den kmdb (fuer alle aelteren Releases musst du kadb verwenden). Der mdb wurde im Rahmen der diversen Solaris releases auch deutlich verbessert und erst ab Solaris 10 macht das so richtig Spass ;-)

Da du das Problem ja offenbar auch bei dem Boot von CD nachstellen kannst wuerde ich dir hier empfehlen von einer Solaris 10 CD den kmdb zu booten.

Solange du noch keinen Anhaltspunkt fuer eine weitere Suche hast macht es keinen Sinn einzelne Breakpoints zu setzen. Statt dessen solltest du einfach den Boot durchlaufen lassen bist du zu dem Haenger kommst. Dann am besten noch ein paar Minuten warten und dann mittels STOP-A (oder send break bei serieller Console) in den kmdb fallen. Dann kannst du dort mit dem Befehl "$<threadlist" (oder in der neuen Syntax "::threadlist -v") nachsehen wo die einzelnen Threads gerade stehen (was sie machen, auf was sie warten etc.). Diese Liste muss man sich erstmal durchsehen um danach im naechsten Schritt ggf. genauere Untersuchungen einleiten zu koennen.

Du kannst ja mal die Ausgabe dieser "$<threadlist" im kmdb beim Haenger irgendwo ablegen (nach der ersten Seite einfach "c" druecken um die Liste komplett anzeigen zu lassen ohne sich da seitenweise durchzukaempfen). Dann schau ich da mal rein.

Tschau,
  Drusus.

[escimo]

Da du das Problem ja offenbar auch bei dem Boot von CD nachstellen kannst wuerde ich dir hier empfehlen von einer Solaris 10 CD den kmdb zu booten.

Hi Drusus, vielen Dank für deine bisherige Unterstützung zu diesem Problem.

Kann man denn den kmdb vom Solaris10-Medium nutzen, um damit den Solaris8-Kernel auf der Festplatte zu debuggen? Ansonsten wird es unmöglich den Fehler überhaupt nachzustellen, da...

Solange du noch keinen Anhaltspunkt fuer eine weitere Suche hast macht es keinen Sinn einzelne Breakpoints zu setzen. Statt dessen solltest du einfach den Boot durchlaufen lassen bist du zu dem Haenger kommst.

...bei Solaris 10 und höher der Fehler nicht auftritt.

Dann am besten noch ein paar Minuten warten und dann mittels STOP-A (oder send break bei serieller Console) in den kmdb fallen. Dann kannst du dort mit dem Befehl "$<threadlist" (oder in der neuen Syntax "::threadlist -v") nachsehen wo die einzelnen Threads gerade stehen (was sie machen, auf was sie warten etc.). Diese Liste muss man sich erstmal durchsehen um danach im naechsten Schritt ggf. genauere Untersuchungen einleiten zu koennen.

Nur das das System beim Auftritt des Fehlers auf keine Eingaben mehr reagiert, auch nicht auf Stop+A. 

Grüße
escimo

[Drusus]

Moin,

sorry - dann hatte ich das uebersehen (das unter Solaris 10 der Fehler nicht auftritt).
Den Kernel-Debugger musst du schon von der passende Solaris-Release starten. In deinem Fall also der "kadb" (kmdb gibts in Solaris 8 noich nicht). Wenn allerdings auch auf Stop-A nicht reagiert wird, dann ist die Frage ob das viel hilft...

Meine beiden Vorschlaege: erstmal in /etc/system den Eintrag "set snooping=1". Das aktiviert einen Watchdog und dann erkennt das System evtl. selber den Haenger (und faellt dann in den Debugger wenn dieser zuvor gestartet wurde). Danach ein "boot kadb" und sehen ob man automatisch in den kadb kommt (oder ob man per stop-a bzw. send break in den kadb kommt). Falls ja, dann dort "$<threadlist" eingeben.
Wenn das nichts hilft, dann bleibt noch der Boot mit dem setzen der moddebug Variable (hatte ich ja schon erwaehnt).

Tschau,
  Drusus.

[escimo]

[1] Vorgehen bei /etc/system:
Start von Solaris 8 mit 32-Bit Kernel
Editieren und Einfügen von "set snooping=1", abspeichern, vi beenden
Kommando halt
am OBP "boot kadb -d"
im kadb ":c"
<keine Reaktion mehr, Stop+A wirkungslos>

[2] Vorgehen Moddebug:
ok boot kadb -
kadb: kenel/sparcv9/unix
Size: 361160+91197+77967 Bytes
/platform/sun4u/kernel/sparcv9/unix loaded - 0xea000 bytes used
stopped at _start: sethi %hi(0x10006c00), %g1
kadb[2]: moddebug/W 0xe0000000
moddebug: 0x0 = 0xe0000000
kadb[2]: :c
<keine Reaktion mehr>

Mmm...

[Drusus]

Moin,

hm - wenn bei dem moddebug keinerlei Ausagbe kommt, dann scheitert bereits das Laden (bzw. Initialisieren) von unix/genunix (wir kommen hier ja noch nichtmal dazu die anderen Kernelmodule zu laden).

Wenn ich das richtig verstnaden habe, dann tritt das Problem auch dann auf, wenn du Solaris 8 von der CD bootest, richtig? Das wuerde dann auch Einstellungen in /etc/system etc. ausschliessen. Wenn zudem noch STOP-A nicht mag, dann faellt mir auch nichts mehr ein.

Tschau,
  Drusus.

[escimo]

hm - wenn bei dem moddebug keinerlei Ausagbe kommt, dann scheitert bereits das Laden (bzw. Initialisieren) von unix/genunix (wir kommen hier ja noch nichtmal dazu die anderen Kernelmodule zu laden).

Ja, so sieht es leider aus. Deshalb bin ich auch der Ansicht, dass es etwas mit dem 64-Bit-Kernel zu tun haben könnte.

Hast du tiefere Kenntnis bei der Anwendung von kadb vor allem bezüglich meiner Fragen?

Daran anschließend, wie lässt sich dann ein Hardware- oder Software-Bug komfortabel auffinden, ohne jede Instruktion über ":s" ("next Step" wie bei kadb) einzeln zu durchlaufen. Ich besitze keine genaue interne Kenntnis des Solaris 8/9-Kernels.

Wie kann ich effektiv durch den Code "manövrieren" mittels Breakpoints (:b)? Wie weis ich, welche Funktionen alles beim Laden des Kernels aufgerufen werden, ohne in Einzelschritten (und mittels der Stack-Anzeige "$c" und der Thread-Liste "$<threadlist") vorgehen zu müssen?

Gruß
escimo

PS: Ich fürchte, wenn sich der Fehler nicht finden lässt, habe ich für die Ultra 80 keine Verwendung mehr, da ich unter keinen Umständen Solaris 10 auf diesem System laufen lassen würde. Wenn es ein generelles Problem wäre, würde ich keine Anstände machen aber das ist nicht der Fall. Gelobt sei meine SS20, die funktioniert wenigstens. Meine Ultra 80 ist aber auch "verwanzt" und widerspenstig bei der Verwendung von Solaris kleiner Version 10.

[Padde]

PS: Ich fürchte, wenn sich der Fehler nicht finden lässt, habe ich für die Ultra 80 keine Verwendung mehr, da ich unter keinen Umständen Solaris 10 auf diesem System laufen lassen würde.

Keine Angst, dann würde ich das Ding gerne nehmen.    Mir fehlt sowieso noch eine einigermaßen schnelle SPARC-Kiste, auf der Solaris 10 und FreeBSD läuft. Bei e*ay sind U80 irgendwie Mangelware. Jaja, ich bin ja schon wieder weg. 

[Toktar]

PS: Ich fürchte, wenn sich der Fehler nicht finden lässt, habe ich für die Ultra 80 keine Verwendung mehr, da ich unter keinen Umständen Solaris 10 auf diesem System laufen lassen würde.

Keine Angst, dann würde ich das Ding gerne nehmen.    Mir fehlt sowieso noch eine einigermaßen schnelle SPARC-Kiste, auf der Solaris 10 und FreeBSD läuft. Bei e*ay sind U80 irgendwie Mangelware. Jaja, ich bin ja schon wieder weg. 

Das erinnert mich ein ganz klein wenig an Leichenfledderei....

@escimo: Ich hoffe Du findest den Fehler noch und nein, ich habe mit meiner U60 und demnächst der 2ten genug Spielkrams.