Hardware > Sun SPARC

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

<< < (7/11) > >>

escimo:

--- Zitat von: maal am 10. Februar 2008, 18:59:21 ---Die Idee mit dem Kernel-Debugger ist mir auch gekommen, nur hast du damit schon gearbeitet ?
--- Ende Zitat ---
Öhhh, ... ::) nein! ;D - 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:

--- Zitat von: Drusus am 10. Februar 2008, 21:41:41 ---Soweit ich das auf den ersten Blick sehe hast du aber (ausser der Grafikkarte) keine weiteren Karten eingebaut, richtig?
--- Ende Zitat ---
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.


--- Zitat von: Drusus am 10. Februar 2008, 21:41:41 ---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).
--- Ende Zitat ---
Das wäre eine gute Nachricht.


--- Zitat von: Drusus am 10. Februar 2008, 21:41:41 ---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.
--- Ende Zitat ---
Das habe ich bereits vermutet. Woher hast du denn diese Informationen (Bedeutung für die Abkürzung/Akronym)?  ::)


--- Zitat von: Drusus am 10. Februar 2008, 21:41:41 ---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)?
--- Ende Zitat ---
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,


--- Zitat von: escimo am 11. Februar 2008, 10:19:48 ---
--- Zitat von: Drusus am 10. Februar 2008, 21:41:41 ---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.
--- Ende Zitat ---
Das habe ich bereits vermutet. Woher hast du denn diese Informationen (Bedeutung für die Abkürzung/Akronym)?  ::)

--- Ende Zitat ---

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: ---{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
--- Ende Code ---
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: ---kadb[2]: moddebug/W 0xe0000000
moddebug:     0x0     =     0xe0000000
kadb[2]: :c
<und tschüss>
--- Ende Code ---

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete