Hardware > Sun SPARC

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

<< < (8/11) > >>

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) ---kadb[2]> :s
stopped at     
_start:     sethi     %hi(0x10006c00), %g1
--- Ende Code ---

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:

--- Zitat von: Drusus am 24. Februar 2008, 15:11:43 ---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.
--- Ende Zitat ---
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...


--- Zitat von: Drusus am 24. Februar 2008, 15:11:43 ---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.
--- Ende Zitat ---
...bei Solaris 10 und höher der Fehler nicht auftritt.


--- Zitat von: Drusus am 24. Februar 2008, 15:11:43 ---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.
--- Ende Zitat ---
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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete