sonnenblen.de - Das unabhängige Sun User Forum
Hardware => Sun SPARC => Thema gestartet von: escimo am 14. Januar 2008, 20:21:18
-
Hallo zusammen,
die Ultra 80 hat ein neues Problem. Und das ist echt mal Sch**** >:(
Ausgangssituation:
System = Sun Ultra 80 Workstation
Firmware = OpenBoot 3.31
2x 36GB Festplatten
1x Toshiba SD-M1401 mit Firmware Rev. 1009
Fehlerbeschreibung:
{1} probe-scsi
...
Target 6
Unit 0 Removable Read Only device Toshiba DVD-ROM SD-M14011009
{1} ok boot cdrom
Boot device: /pci@1f,4000/scsi@3/disk@6,0:f File and args:
[|]
Das wars! Jetzt könnte man nach Hause gehen. Das Fortschritts-Symbol [|] bleibt stehen. Es erfolgt kein Zugriff mehr auf das CD-/DVD-Laufwerk und es wird ein manueller Auswurf der CD-/DVD-ROM möglich. Die Tastatur ist für weitere Eingaben jeglicher "<STOP>"-Sequenzen oder anderer Eingabe gesperrt, so dass nur noch der Griff zum Netzschalter für einen Reboot/Reset hilft.
Der Witz daran: Sobald ich die aktuelle OpenSolaris XE DVD in das Laufwerk einlege und von dieser booten möchte, hat es bis jetzt immer funktioniert. Nur von den Boot-Medien (DVD und CD-ROM) von Solaris 9 9/04 geht nix, obwohl die in gutem Zustand sind. ???
Ich habe zwischendurch sogar noch ein anderes CD-ROM Laufwerk probiert. Da klappt es mit der Boot-fähigen CD-ROM von oben genannten Solaris 9 auch nicht. Das selbe Verhalten.
Unter OpenSolaris konnte ich eine CD-RW mit Forte 6 zwar mounten aber nicht mit Erfolg das Installationsprogramm dazu überreden über das erste Wizard-Fenster mit dem [Weiter]-Button zu kommen.
Unter dem OBP wurde ein...
{1} ok eject cdrom
...belohnt mit...
Bus fault
Bus fault...in einer Dauerschleife, das sich über die Tastatur ebenfalls nicht abbrechen lässt.
In den Dokus und bei sunshack.org habe ich dazu nichts gefunden.
Mir sind die Ideen ausgegangen, woran es noch liegen könnte.
Über Vorschläge, Ideen und Ratschläge bin ich dankbar.
Grüße
escimo
-
vllt hilft was davon:
http://docs.sun.com/app/docs/doc/816-6189/6mc9h89ae?l=de&a=view
-
Hi DukeNuke2,
danke für den Link. Leider ist der einzige Hinweis die Firmware. Doch die bezieht sich beim SD-M1401 auf Version 1007. Mein Laufwerk ist mit der Version 1009 bespielt. Aber es könnte durchaus möglich sein, dass es an den Medien liegt. Ganz ausschließen kann ich das net.
Vielleicht liegt ein Hardware-Fehler vor, der mit meinen Mitteln nicht feststellbar ist.
Bei einem alternative Laufwerk (Toshiba CD-ROM) konnte ich von der Installations-CD (Solaris 9 Media 9/04) ebenfalls nicht booten. Es trat ebenfalls das beschriebene Verhalten auf. Ich versuche nochmal von der Software-CD #1 zu booten, obwohl ich nicht glaube das es etwas bringt.
Morgen versuche ich es mal mit dem Konsolenkabel und lasse den Output in einer Datei aufzeichnen.
Gruß
escimo
-
Wie sieht's mit dem Jumper für die Blocksize aus?
-
Wie sieht's mit dem Jumper für die Blocksize aus?
oh, der jumper wird auf der seite gar nicht erwähnt... ja, den sollte man auch prüfen! guter hinweiss.
-
Hallo,
ich glaube beim Sun SD-M1401 macht die Jumperstellung keinen Unterschied.
Die alte Firmware 1.07 hatte mit Rücksicht auf ältere Solaris-Versionen die Blockgröße passend für CDs eingestellt. Genaues steht in InfoDocs.
Wenn sein Laufwerk auch keine CDs booten kann, ist der Jumper nicht die Ursache. Vielleicht einmal das Signal-Kabel zwischen Systemboard und Laufwerk prüfen/wechseln. Die Terminierung könnte versuchsweise auch auf dem Laufwerk erfolgen.
Etwas off-topic: Falls jemand ein solches defektes Laufwerk hat, hätte ich Interesse daran. Einzig die Schublade sollte rein-/rausfahren. Ich habe nämlich ein Laufwerk bei dem das Zahnrad am Schubladen-Motor einen Haarriß hat, sonst ist es ok.
Michael
-
Hi Michael!
ich glaube beim Sun SD-M1401 macht die Jumperstellung keinen Unterschied.
Die alte Firmware 1.07 hatte mit Rücksicht auf ältere Solaris-Versionen die Blockgröße passend für CDs eingestellt. Genaues steht in InfoDocs.
Wenn sein Laufwerk auch keine CDs booten kann, ist der Jumper nicht die Ursache.
Ich meine schon, denn:
Mein Laufwerk ist mit der Version 1009 bespielt.
Wäre es nicht trotzdem einen Versuch wert? :)
-
Ich werde die Steckverbindung (Jumper) bezüglich der Block-Größe dann überprüfen.
Was ich mich aber Frage: warum funktionierte der Boot von CD-ROM über ein CD-ROM Laufwerk nicht und bricht mit den selben zuvor beschriebenen Erscheinungen ab? ???
Ich vermute auch ein Kabel oder Board-Defekt, wie maal schon geschrieben hat. Das wäre dann allerdings absolute ... :-\
-
Die "Block-Size" Steckverbindung (Jumper) war gesetzt auf 512k.
Nach Entfernen des Jumper (2048k-Modus) war leider keine Änderung zu verzeichnen.
Auch der Test mit der Software CD #1 (von Solaris 9) brachte einen Misserfolg.
Bis vor diesem Thread habe ich nie eine älteren Version als Solaris 10 auf der U80 getestet. Das war ein Fehler.
Jetzt mal eine ganz abstruse Vorstellung: könnte eventuell das OBP entsprechend angepasst sein, dass es die Installation einer niedrigeren Version von Solaris nicht zulässt? - Das würde dann aber immer noch nicht erklären, warum die Tastatur dann keine Eingaben (z.B. Abbruch der Installation) zulässt.
Morgen bringe ich wie schon geschrieben das KAP ("Konsolen-Adapter-Paar") mit und schaue mal was sich ergibt.
Wenn das dann keine befriedigenden Ergebnisse erzielt, dann sehe ich effektiv nur noch eine Möglichkeit: ich nutze einen zusätzlichen SCSI-Controller samt Kabel und umgehe die Backplane-Platine. Denn ein Tausch des Kabels in einer Ultra 80 ist nicht möglich, da das CD-ROM-Kabel mit dem HDD-Backplane-Board verlötet ist. Natürlich könnte man auch die Backplane austauschen. Leider habe ich kein Ersatz dafür zur Hand. :-\
Hoffentlich ist es nicht die Hauptplatine. ::)
Gruß
escimo
-
Mit einem anderen Satz Datenträger hast Du es schon versucht?
Lässt sich denn Solaris 10 installieren oder bricht die Installation da auch ab?
-
Hallo Stephan,
schau dir doch nochmal den DVD-Inhalt bezüglich der Ultra 80 an. Eines der Dokumente (I0723-1) beschreibt die Problematik mit dem DVD-Laufwerk.
Der dritte Jumper von rechts ist für 512/2K zuständig und bei mir gesteckt. Außer diesem sind nur noch die beiden für die
SCSI-ID gesteckt.
Bei dem Pioneer mußte auf 2048 Byte gejumpert werden, sonst klappte kein Booten von DVD (Lesen ging immer).
Das mit der Einheit aus Backplane und SCSI-Kabel zum CD-/DVD-Laufwerk ist mir jetzt auch bewußt. Ein internes Kabel dürfte aber äußerst selten ausfallen, eher der aktive Terminator am Ende. Alle anderen Komponenten (Kabel, Widerstände) sind passiv.
Der sporadische Speicherfehler könnte auch an einem defekten Netzteil oder defekter CPU liegen. Evtl. solltest du einmal die Speicherslots mit Kontakt-Reiniger behandeln. Die Riser-Karte wegen der äußerst empfindlichen Kontakte aber besser nicht entfernen !
Beim Hantieren mit Speichermodulen sollte man sich gut erden um statische Aufladung zu vermeiden. Ein Bekannter schwört, daß die Nichtbeachtung Ursache solcher Speicherfehler sein könnte. Vielleicht hatte er aber auch nur zuviele High-End Server bei Kunden installiert.
Michael
-
Mit einem anderen Satz Datenträger hast Du es schon versucht?
Lässt sich denn Solaris 10 installieren oder bricht die Installation da auch ab?
Ich habe zur Abwechslung mal einen Solaris 8 2/02 CD-Satz zur Installation zwingen wollen. Keine Chance. - Also um Irrtümer auszuschließen: nach "boot cdrom" erscheintnur noch die eine Zeile mit dem Boot-Device und das Fortschrittssymbol, dass dann nach 7 Sekunden stehen bleibt. ;)
schau dir doch nochmal den DVD-Inhalt bezüglich der Ultra 80 an. Eines der Dokumente (I0723-1) beschreibt die Problematik mit dem DVD-Laufwerk.
Der dritte Jumper von rechts ist für 512/2K zuständig und bei mir gesteckt. Außer diesem sind nur noch die beiden für die
SCSI-ID gesteckt.
Danke dir Michael aber die Jumper sind identisch zu deinen Angaben gesteckt. ;)
Das Problem ist, eine ältere Solaris-Version (z.B Solaris 8 / 9) von CD-ROM zu booten. Mit Solaris 10 (von DVD-R) gibt es kaum Probleme, bis auf die Tatsache, dass die Schublade des DVD-ROM Laufwerks bei mir auch "rumzickt". Das ist ja das kuriose. :)
Die Speicherfehler betreffen bis jetzt ein DIMM in Bank 0. Es könnte schon möglich sein, dass ein CPU-Fehler vorliegt. Doch habe ich beim Stöbern in den Unterlagen (FIN's, SRDB's, FCO's und InfoDocs) die Ausgaben verglichen. Diese stimmen nicht mit bekannten CPU-Fehlern überein. Es verhält sich anders.
Ich versuche es morgen dann wie angedeutet mit dem seriellen Kabel und stelle den die Ausgaben ein.
Gruß
Stephan
-
Ich versuche es morgen dann wie angedeutet mit dem seriellen Kabel und stelle den die Ausgaben ein.
Gut, ich habe in Frankfurt den falschen Adapter (D-Sub25 Buchse anstatt Stecker) mitgenommen. Damit hatte sich die Diagnose zunächst erledigt. Kommt aber noch.
Jetzt habe ich zur Abwechslung mal die internen und externen DVD-/CD-ROM-Laufwerke an einem Extra-SCSI-Controller in der Ultra 80 angeschlossen. - Erstaunen bei mir: selbes Verhalten. Dazu die Gewissheit, dass der Onboard-Chip und die Kabel von der Hauptplatine zur HDD-Backplane und von da zum internen Laufwerk nicht die Ursache sein können. Auch ein Laufwerks-Defekt bei 4 optischen Laufwerken kann dann ausgeschlossen werden. Zudem habe ich es gleich noch mit Solaris 2.5.1 versucht. Hier konnte er jetzt den Kernel nicht finden, was hoffen lässt.
Dieses Mal lautete der OBP-Befehl:
{0} ok boot /pci@1f,4000/scsi@5,1/disk@6,0:fNo Chance. Ich bin am Ende meiner gewohnten Reaktionen für eine diesbezügliche Problematik. :'(
Auch der Wechsel der CPU's (4 Einzel-CPU's abwechselnd in Slot 0 als Mono-Prozessor-Konfiguration) brachte keine Änderung.
Zusammenfassung
Folgende Aktionen führten zu dem im Startbeitrag beschriebenen Fehlverhalten der Ultra 80:
- Jumper für Block-Size auf 512 kB und 2048 kB
- Änderung der Terminierung
- Wechsel der internen Laufwerke (4 verschiedene CD-/DVD-Laufwerke)
- Wechsel des SCSI-Controllers (Verlagerung der CD-/DVD-Laufwerksanschlüsse an einen zusätzlich verbauten SCSI-Controller)
- Wechsel der CPU in Slot 0
- Wechsel des kompletten Speichers
- Wechsel der Grafik-Hardware (PGX32 / XVR-1000 / Expert3D)
- Wechsel der Installationsmedien für Solaris 8 (2/02) und 9 (9/04) - DVD und CD-ROM!
Und nun der Clou: ich habe es nochmal mit Solaris 10 und OpenSolaris (SXCE Build 78) versucht. Dann passierte folgendes:
{0} ok boot /pci@1f,4000/scsi@5,1/disk@6,0:f File and args:
SunOS Release 5.10 Version Generic_118833-33 64-bit
Copyright 1983-2006 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
TSI: gfxp0 is GFX8P @ 1152x900
Configuring devices.
...
Type 'go' to resume
{3} ok
...<Medium-Wechsel>...
{3} ok boot /pci@1f,4000/scsi@5,1/disk@6,0:f
Resetting ...
...<Banner-Anzeige>...
Rebooting with command: boot /pci@1f,4000/scsi@5,1/disk@6,0:f
Boot device: /pci@1f,4000/scsi@5,1/disk@6,0:f File and args:
SunOS Release 5.11 Version snv_78 64-bit
Copyright 1983-2007 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
TSI: gfxp0 is GFX8P @ 1152x900
Configuring devices.
...
Beide Versionen funktionieren! Wie kann das denn sein? :o :( ???
Könnte ein erneutes Einspielen der OBP Version etwas bringen? Momentan ist folgende Version im Einsatz:
{0} ok .version
Release 3.31 Version 0 created 2001/07/25 20:35
OBP 3.31.0 2001/07/25 20:35
POST 1.2.8 2000/08/22 19:50
Es soll definitiv eine "Dual Boot"-Konfiguration auf die U80 drauf, mit Solaris 8 2/02 auf Disk0 und OpenSolaris SXCE Build 78 auf Disk1. SXCE ist bereits installiert, da es mit dieser Version beim Booten des Installationsmediums funktionierte.
Habt ihr noch Ideen?
Viele Grüße
escimo
-
Ich habe mich am Wochenende (eigentlich heute 1:00 - 5:30 Uhr) nochmal mit der Problematik befasst und weitere Tests gefahren.
[1.]
Zum einen konnte ich bei der Inspektion des Motherboards feststellen, dass der Jumper J3001 Pin 2+3 miteinander verbindet und damit der NVRAM beschreibbar ("Write Enable") ist. Default ist Pin 1+2.
[2.]
Ich habe auch die OpenBoot-Diagnose ausgeführt. Keine Auffälligkeiten. Übrigens: für was steht die OBP-Variable "mfg-mode"?
[3.]
Nach dem Setzen der OBP-Variable "diag-level" auf den Wert "min", wurden folgende erweiterten Ausgaben auf dem Bildschirm angezeigt:
SC Control: EWP:0 IAP:0 FATAL:0 WAKEUP:0 BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0
Probing Memory Bank #0 512 512 #2 512 512: 2 Gigabytes
Probing Floppy: drive detected on ID0
Probing EBUS Nothing there
Probing UPA Slot at 1e,0 SUNW,gfb
Probing UPA Slot at 1d,0 Nothing there
Probing /pci@1f,4000 at Device 1 pci108e,1000 network
Probing /pci@1f,4000 at Device 3 scsi disk tape scsi disk tape
Probing /pci@1f,4000 at Device 2 Nothing there
Probing /pci@1f,4000 at Device 4 Nothing there
Probing /pci@1f,4000 at Device 5 Nothing there
Probing /pci@1f,2000 at Device 1 Nothing there
<banner ... 1x 450 MHz CPU, Serial, Ethernet address ...>
Rebooting with command: boot cdrom
Boot device: /pci@1f,4000/scsi@3/disk@6,0:f File and args:
Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54
FCode UFS Reader 1.11 97/07/10 16:19:15
Redirected to slice 1
Loading: /platform/SUNW,Ultra-80/ufsboot
Loading: /platform/sun4u/ufsboot
- (Fortschrittsanzeige friert wieder ein!)
Was bedeutet dieses "SPOR:1" und wie kann mir dieser Output dabei helfen, Solaris in einer Version kleiner 10 zu installieren? Ich weis langsam net mehr weiter. :'(
Nur Schererei seitdem ich das Teil bekommen habe.
-
Hallo Stephan,
mit der Deutung der ersten Zeile
SC Control: EWP:0 IAP:0 FATAL:0 WAKEUP:0 BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0
kann ich auch nicht weiterhelfen. Evtl. könnte jemand für dich in der Sun Knowledgebase nachsehen oder jemand erinnert sich noch an ein entsprechendes Training. Der ehemalige Moderator des Sun Hardware Support Forums hätte möglicherweise weitergewußt, leider ist er jetzt auch etwas aus dem Training und er hat auch nicht mehr Zugriff auf diese Dokumente.
Was du selbst noch probieren kannst, ist mit verbose-Option (also boot cdrom -v) zu booten, dann werden ausführlichere Informationen angezeigt.
Zweite Sache: Mit set-defaults auf die Standard-Werte zurücksetzen. Bei einer Ultra AXi hat dies nachweislich geholfen. Die Symtome waren ähnlich, bestimmte Solaris-Versionen funktionierten, andere nicht. Ein Wechseln der Grafikkarte hat auch nicht geholfen (ein anderes System mit bis auf den Framebuffer identischer Konfiguration lief nämlich).
Nachweislich deshalb, weil jemand das gleiche Problem hatte und nach diesem Zurücksetzen lief es dann.
Die alten Settings vorher notieren und daran denken auto-boot? wieder auf false zu setzen !
Das das Flash-ROM mit dem OBP/POST nicht schreibgeschützt ist (J3001), dürfte keinen Einfluß haben. Bei den Midrange-Servern gibt es diesen Jumper nicht, sondern dies wird durch den Schlüsselschalter "miterledigt".
In dem gedruckten FEH stehen weitere Erklärungen zu OBP-Variablen. U.a. auch solche Sachen wie UPA (=CPU) Steckplätze ausblenden (es werden dadurch nicht alle installierten CPUs erkannt).
Michael
-
Was du selbst noch probieren kannst, ist mit verbose-Option (also boot cdrom -v) zu booten, dann werden ausführlichere Informationen angezeigt.
...
Zweite Sache: Mit set-defaults auf die Standard-Werte zurücksetzen.
Hi Michael, vielen Dank. Ich werde es gleich am Freitag, wenn ich wieder daheim bin, probieren mit den zwei Varianten.
Grüße
escimo
EDIT: Könnte jemand, der im Besitz einer Ultra 80 Workstation ist, seinen Output zum OBP-Kommando printenv hier einstellen, damit ich einen Vergleich für das Wochenende habe?
SC Control: EWP:0 IAP:0 FATAL:0 WAKEUP:0 BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0
Das scheint wohl doch nichts ernstes zu sein.
-
EDIT: Könnte jemand, der im Besitz einer Ultra 80 Workstation ist, seinen Output zum OBP-Kommando printenv hier einstellen, damit ich einen Vergleich für das Wochenende habe?
Donnerstag bekommst Du die Infos :)
-
Hallo,
ich habe jetzt im FEH nachgesehen. Diese "kritischen" Settings sind eher für andere Systeme (E250, E450). Bei der U80 bzw. Systeme mit dem selben Systemboard, wurden diese nicht aufgeführt.
mfg-options für die E450 findet du in Band 1, Seite INTRO-21. Für die Ultra 80 müßte man im Service Manual nachsehen.
Nun habe ich auch den entsprechenden Beitrag über den "Hänger" bei der SPARCengine Ultra AXi gefunden (nur Google-Cache, da die Beiträge nicht migriert wurden). Bei ausführlicher Ausgabe der Meldungen konnte man sehen wo das System hängt.
"When I have user command boot cdrom -v it stucked after
pseudo-device: trapstat0
trapstat0 is /pseudo/trapstat@0"
Das läßt sich zwar wahrscheinlich nicht auf dein Problem anwenden, ist aber trotzdem einen Versuch wert.
Michael
-
Software Power ON
Master CPU : 0000.0000.0055.11a0
Slave CPU : 0000.0001.0055.11a0
Slave CPU : 0000.0002.0055.11a0
Slave CPU : 0000.0003.0055.11a0
Master E$ : 0000.0000.0040.0000
Slave E$ : 0000.0000.0040.0000
Slave E$ : 0000.0000.0040.0000
Slave E$ : 0000.0000.0040.0000
@(#) UPA/PCI 3.23 Version 0 created 1999/06/30 13:53
Clearing DTAGS Done
Probing Memory
CONFIG = 0000.0000.1010.1010
MEM BASE = 0000.0000.0000.0000
MEM SIZE = 0000.0001.0000.0000
MMUs ON
Copy Done
PC = 0000.01ff.f000.2a50
PC = 0000.0000.0000.2a94
Decompressing into Memory Done
Size = 0000.0000.0006.ef90
ttya initialized
SC Control: EWP:0 IAP:0 FATAL:0 WAKEUP:0 BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0
Probing Memory Bank #0 1 1 1 1 : 4 Gigabytes
Probing Floppy: No drives detected
Probing EBUS SUNW,CS4231
Probing UPA Slot at 1e,0 Nothing there
Probing UPA Slot at 1d,0 Nothing there
Probing /pci@1f,4000 at Device 1 pci108e,1000 network
Probing /pci@1f,4000 at Device 3 scsi disk tape scsi disk tape
Probing /pci@1f,4000 at Device 2 Nothing there
Probing /pci@1f,4000 at Device 4 Nothing there
Probing /pci@1f,4000 at Device 5 SUNW,XVR-100
Probing /pci@1f,2000 at Device 1 Nothing there
SC Control: EWP:0 IAP:0 FATAL:0 WAKEUP:0 BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0
Probing Memory Bank #0 1 1 1 1 : 4 Gigabytes
Probing Floppy: No drives detected
Probing EBUS SUNW,CS4231
Probing UPA Slot at 1e,0 Nothing there
Probing UPA Slot at 1d,0 Nothing there
Probing /pci@1f,4000 at Device 1 pci108e,1000 network
Probing /pci@1f,4000 at Device 3 scsi disk tape scsi disk tape
Probing /pci@1f,4000 at Device 2 Nothing there
Probing /pci@1f,4000 at Device 4 Nothing there
Probing /pci@1f,4000 at Device 5 SUNW,XVR-100
Probing /pci@1f,2000 at Device 1 Nothing there
Sun Ultra 80 UPA/PCI (4 X UltraSPARC-II 450MHz), No Keyboard
OpenBoot 3.23, 4096 MB memory installed, Serial #15730451.
Ethernet address 8:0:20:f0:7:13, Host ID: 80f00713.
{0} ok printenv
Variable Name Value Default Value
scsi-initiator-id 7 7
keyboard-click? false false
keymap
ttyb-rts-dtr-off false false
ttyb-ignore-cd true true
ttya-rts-dtr-off false false
ttya-ignore-cd true true
ttyb-mode 9600,8,n,1,- 9600,8,n,1,-
ttya-mode 9600,8,n,1,- 9600,8,n,1,-
pcia-probe-list 1 1
pcib-probe-list 1,3,2,4,5 1,3,2,4,5
enclosure-type 540-3871
banner-name Sun Ultra 80 UPA/PCI
energystar-enabled? true
mfg-mode off off
diag-level max min
#power-cycles 150
system-board-serial# 5015168052804
system-board-date 39a70946
fcode-debug? false false
More [<space>,<cr>,q,n,p,c] ?
output-device screen screen
input-device keyboard keyboard
load-base 16384 16384
boot-command boot boot
auto-boot? true true
watchdog-reboot? false false
diag-file
diag-device net net
boot-file
boot-device disk1:a disk net disk net
local-mac-address? false false
ansi-terminal? true true
screen-#columns 80 80
screen-#rows 34 34
silent-mode? false false
use-nvramrc? false false
nvramrc
security-mode none
security-password
security-#badlogins 0
oem-logo
oem-logo? false false
oem-banner
More [<space>,<cr>,q,n,p,c] ?
oem-banner? false false
hardware-revision
last-hardware-update
diag-switch? true false
{0} ok
hth
-
Sun Ultra 80 UPA/PCI (4 X UltraSPARC-II 450MHz), No Keyboard
OpenBoot 3.23, 4096 MB memory installed, Serial #15730451.
Ethernet address 8:0:20:f0:7:13, Host ID: 80f00713.
Danke David. Ich vergleiche dann am Wochenende. Aber die OBP-Version wäre schon der erste Unterschied. Ich habe OpenBoot 3.31. :-\
-
ok boot cdrom -v
Boot device: /pci@1f,4000/scsi@3/disk@6,0:f File and args: -v
Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54
FCode UFS Reader 1.11 97/07/10 16:19:15
Redirected to slice 1
Loading: /platform/SUNW,Ultra-80/ufsboot
Loading: /platform/sun4u/ufsboot
Size: 354544+90530+77594 Bytes
- <Fortschrittsanzeige friert ein>
Das Argument verbose bringt mich nicht wirklich weiter. :-\
Der Output von printenv:
ok printenv
Variable Name Value Default Value
scsi-initiator-id 7 7
keyboard-click? false false
keymap
ttyb-rts-dtr-off false false
ttyb-ignore-cd true true
ttya-rts-dtr-off false false
ttya-ignore-cd true true
ttyb-mode 9600,8,n,1,- 9600,8,n,1,-
ttya-mode 9600,8,n,1,- 9600,8,n,1,-
pcia-probe-list 1 1
pcib-probe-list 1,3,2,4,5 1,3,2,4,5
enclosure-type 540-3871
banner-name Sun Ultra 80 UPA/PCI
energystar-enabled? true
mfg-mode off off
diag-level min min
#power-cycles 132
system-board-serial# 5015168062306
system-board-date 39cebea4
fcode-debug? false false
output-device screen screen
input-device keyboard keyboard
load-base 16384 16384
boot-command boot boot
auto-boot? false true
watchdog-reboot? false false
diag-file
diag-device net net
boot-file
boot-device disk0 disk1 net disk net
local-mac-address? false false
ansi-terminal? true true
screen-#columns 80 80
screen-#rows 34 34
silent-mode? false false
use-nvramrc? false false
nvramrc
security-mode none
security-password
security-#badlogins 0
oem-logo
oem-logo? false false
oem-banner
oem-banner? false false
hardware-revision
last-hardware-update
diag-switch? true false
Danach habe ich noch ein "set-defaults" im OBP-Modus ausgeführt. Danach ein "reset". Zum Abschluss wieder ein "boot cdrom -v". Keine Änderung!
-
Yippee! Bin ich ja doch net so blöd. 8)
Doch bevor ich zur Auflösung des Rätsels kommen möchte, zunächst noch der versprochene POST Output über die serielle Konsole:
ok setenv diag-switch? true
diag-switch? = true
ok setenv diag-level max
diag-level = max
ok power-off
<Anschalten des Systems über PowerOn>
CPU Offline (not present)
CPU Offline (not present)
Master CPU : 0000.0002.0055.11a0
CPU Offline (not present)
Master E$ : 0000.0000.0040.0000
Button Power ON
CPU Offline (not present)
CPU Offline (not present)
Master CPU : 0000.0002.0055.11a0
CPU Offline (not present)
Master E$ : 0000.0000.0040.0000
Probing keyboard Done
Executing Power On SelfTest
2>
2>@(#) Sun Ultra 80(UltraSPARC-II 4-way) UPA/PCI POST 1.2.8 08/22/2000 07:50 PM
2>INFO: Processor 2 is master. CPU 450 MHz.
2>
2> <00> Init System BSS
2> <00> NVRAM Battery Detect Test
2> <00> NVRAM Scratch Addr Test
2> <00> DMMU TLB Tag Access Test
2> <00> DMMU TLB RAM Access Test
2> <00> IMMU TLB Tag Access Test
2> <00> IMMU TLB RAM Access Test
2> <00> Probe Ecache
2>INFO: 4096KB Ecache
2> <00> Ecache RAM Addr Test
2> <00> Ecache Tag Addr Test
2> <00> Ecache Tag Test
2> <00> Invalidate Ecache Tags
2>INFO: Processor 0 is missing or disabled.
2>INFO: Processor 1 is missing or disabled.
2>INFO: Processor 3 is missing or disabled.
2> <00> Init SC Regs
2> <00> SC Address Reg Test
2> <00> SC Reg Index Test
2> <00> SC Regs Test
2> <00> SC Dtag RAM Addr Test
2> <00> SC Cache Size Init
2> <00> SC Dtag RAM Data Test
2> <00> SC Dtag Init
2> <00> Probe Memory
2>INFO: 1024MB Bank 0
2>INFO: 1024MB Bank 1
2>INFO: 0MB Bank 2
2>INFO: 0MB Bank 3
2> <00> Malloc Post Memory
2> <00> Init Post Memory
2> <00> Post Memory Addr Test
2> <00> Map PROM/STACK/NVRAM in DMMU
2> <00> Memory Stack Test
2> <00> DMMU Hit/Miss Test
2> <00> IMMU Hit/Miss Test
2> <00> DMMU Little Endian Test
2> <00> IU ASI Access Test
2> <00> FPU ASI Access Test
2> <1f> Init Psycho
2> <1f> PIO Read Error, Master Abort Test
2> <1f> PIO Read Error, Target Abort Test
2> <1f> PIO Write Error, Master Abort Test
2> <1f> PIO Write Error, Target Abort Test
2> <1f> Timer Increment Test
2> <1f> Init Psycho
2> <1f> Pass-Thru DMA UE ECC Rd Err Lpbk Test
2> <00> V9 Instruction Test
2> <00> CPU Tick and Tick Compare Reg Test
2> <00> CPU Soft Trap Test
2> <00> CPU Softint Reg and Int Test
2> <00> Copy Post to Memory
2> <00> Ecache Thrash Test
2> <00> ECC Mem Addr Clear
2> <00> Memory Addr w/ Ecache Test
2>INFO: 1024MB Bank 0
2>INFO: 1024MB Bank 1
2>INFO: No memory in Bank 2
2>INFO: No memory in Bank 3
2> <00> Block Memory Addr Test
2>INFO: 1024MB Bank 0
2>INFO: 1024MB Bank 1
2>INFO: No memory in Bank 2
2>INFO: No memory in Bank 3
2> <00> ECC Memory Addr Test
2>INFO: 1024MB Bank 0
2>INFO: 1024MB Bank 1
2>INFO: No memory in Bank 2
2>INFO: No memory in Bank 3
2> <00> Memory Status Test
2>INFO: 1024MB Bank 0
2>INFO: 1024MB Bank 1
2>INFO: No memory in Bank 2
2>INFO: No memory in Bank 3
2> <00> FPU Regs Test
2> <00> FPU Move Regs Test
2> <00> FPU State Reg Test
2> <00> FPU Functional Test
2> <00> FPU Trap Test
2> <00> DMMU Primary Context Reg Test
2> <00> DMMU Secondary Context Reg Test
2> <00> DMMU TSB Reg Test
2> <00> DMMU Tag Access Reg Test
2> <00> DMMU VA Watchpoint Reg Test
2> <00> DMMU PA Watchpoint Reg Test
2> <00> IMMU TSB Reg Test
2> <00> IMMU Tag Access Reg Test
2> <00> DMMU TLB Tag Access Test
2> <00> DMMU TLB RAM Access Test
2> <00> Dcache RAM Test
2> <00> Dcache Tag Test
2> <00> Icache RAM Test
2> <00> Icache Tag Test
2> <00> Icache Next Test
2> <00> Icache Predecode Test
2> <00> CPU Addr Align Trap Test
2> <00> DMMU Access Priv Page Test
2> <00> DMMU Write Protected Page Test
2> <1f> Init Psycho
2> <1f> Psycho Cntl and UPA Reg Test
2> <1f> Psycho DMA Scoreboard Reg Test
2> <1f> Psycho Perf Cntl Reg Test
2> <1f> PIO Decoder and BCT Test
2> <1f> PCI Byte Enable Test
2> <1f> Counter/Timer Limit Regs Test
2> <1f> Timer Reload Test
2> <1f> Timer Periodic Test
2> <1f> Mondo Int Map (short) Reg Test
2> <1f> Mondo Int Set/Clr Reg Test
2> <1f> Psycho IOMMU Regs Test
2> <1f> Psycho IOMMU RAM NTA Test
2> <1f> Psycho IOMMU CAM NTA Test
2> <1f> Psycho IOMMU RAM Address Test
2> <1f> Psycho IOMMU CAM Address Test
2> <1f> IOMMU TLB Compare Test
2> <1f> IOMMU TLB Flush Test
2> <1f> Stream Buff A Control Reg Test
2> <1f> Psycho ScacheA Page Tag Addr Test
2> <1f> Psycho ScacheA Line Tag Addr Test
2> <1f> Psycho ScacheA RAM Addr Test
2> <1f> Psycho ScacheA Page Tag NTA Test
2> <1f> Psycho ScacheA Line Tag NTA Test
2> <1f> Psycho ScacheA Error Status NTA Test
2> <1f> Psycho ScacheA RAM NTA Test
2> <1f> Stream Buff B Control Reg Test
2> <1f> Psycho ScacheB Page Tag Addr Test
2> <1f> Psycho ScacheB Line Tag Addr Test
2> <1f> Psycho ScacheB RAM Addr Test
2> <1f> Psycho ScacheB Page Tag NTA Test
2> <1f> Psycho ScacheB Line Tag NTA Test
2> <1f> Psycho ScacheB Error Status NTA Test
2> <1f> Psycho ScacheB RAM NTA Test
2> <1f> PBMA PCI Config Space Regs Test
2> <1f> PBMA Control/Status Reg Test
2> <1f> PBMA Diag Reg Test
2> <1f> PBMB PCI Config Space Regs Test
2> <1f> PBMB Control/Status Reg Test
2> <1f> PBMB Diag Reg Test
2> <1f> Init Psycho
2> <1f> Pri CE ECC Error Test
2> <1f> Pri UE ECC Error Test
2> <1f> Pri 2 bit w/ bit hole UE ECC Err Test
2> <1f> Pri 3 bit UE ECC Err Test
2> <1f> Streaming DMA UE ECC Rd Err Ebus Test
2> <1f> Streaming DMA CE ECC Rd Err Ebus Test
2> <1f> Streaming DMA CE ECC Rd Err Lpbk Test
2> <1f> Consistent DMA UE ECC Rd Error Ebus Test
2> <1f> Consistent DMA UE ECC R/M/W Err Ebus Test
2> <1f> Consistent DMA UE ECC R/M/W Err Lpbk Test
2> <1f> Consistent DMA CE ECC Rd Err Ebus Test
2> <1f> Consistent DMA CE ECC Rd Err Lpbk Test
2> <1f> Consistent DMA CE ECC R/M/W Err Ebus Test
2> <1f> Consistent DMA CE ECC R/M/W Err Lpbk Test
2> <1f> Consistent DMA Wr Data Parity Err Lpbk Test
2> <1f> Pass-Thru DMA UE ECC Rd Err Ebus Test
2> <1f> Pass-Thru DMA UE ECC R/M/W Err Ebus Test
2> <1f> Pass-Thru DMA UE ECC R/M/W Err Lpbk Test
2> <1f> Pass-Thru DMA CE ECC Rd Err Ebus Test
2> <1f> Pass-Thru DMA CE ECC Rd Err Lpbk Test
2> <1f> Pass-Thru DMA CE ECC R/M/W Err Ebus Test
2> <1f> Pass-Thru DMA CE ECC R/M/W Err Lpbk Test
2> <1f> Pass-Thru DMA Write Data Parity Err, Lpbk Test
2> <1f> Init Psycho
2> <1f> Mondo Generate Interrupt Test
2> <1f> Timer Interrupt Test
2> <1f> Timer Interrupt w/ periodic Test
2> <1f> Psycho Stream Buff A Flush Sync Test
2> <1f> Psycho Stream Buff B Flush Sync Test
2> <1f> Psycho Stream Buff A Flush Invalidate Test
2> <1f> Psycho Stream Buff B Flush Invalidate Test
2> <1f> Psycho Merge Buffer w/ Scache A Test
2> <1f> Psycho Merge Buffer w/ Scache B Test
2> <1f> Consist DMA Rd, IOMMU miss Ebus Test
2> <1f> Consist DMA Rd, IOMMU miss Lpbk Test
2> <1f> Consist DMA Rd, IOMMU hit Ebus Test
2> <1f> Consist DMA Rd, IOMMU hit Lpbk Test
2> <1f> Consist DMA Wr, IOMMU miss Ebus Test
2> <1f> Consist DMA Wr, IOMMU miss Lpbk Test
2> <1f> Consist DMA Wr, IOMMU hit Ebus Test
2> <1f> Consist DMA Wr, IOMMU hit Lpbk Test
2> <1f> Stream DMA Rd, IOMMU miss, Scache Miss Ebus Test
2> <1f> Stream DMA Rd, IOMMU miss, Scache Miss Lpbk Test
2> <1f> Stream DMA Rd, IOMMU hit, Scache Miss Ebus Test
2> <1f> Stream DMA Rd, IOMMU hit, Scache Miss Lpbk Test
2> <1f> Stream DMA Rd, IOMMU Miss, Scache(prev rd) Hit Ebus Test
2> <1f> Stream DMA Rd, IOMMU Miss, Scache Hit (prev rd) Lpbk Test
2> <1f> Stream DMA Rd, IOMMU Hit, Scache Hit Ebus Test
2> <1f> Stream DMA Rd, IOMMU Hit, Scache Hit (prev rd) Lpbk Test
2> <1f> Stream DMA Rd, IOMMU Miss, Scache Hit(prev wr) Ebus Test
2> <1f> Stream DMA Rd, IOMMU Miss, Scache Hit (prev wr) Lpbk Test
2> <1f> Stream DMA Rd, IOMMU Hit, Scache Hit(prev wr) Ebus Test
2> <1f> Stream DMA Rd, IOMMU Hit, Scache Hit (prev wr) Lpbk Test
2> <1f> Stream DMA Wr, IOMMU miss, Scache Miss Ebus Test
2> <1f> Stream DMA Wr, IOMMU miss, Scache Miss Lpbk Test
2> <1f> Stream DMA Wr, IOMMU hit, Scache Miss Ebus Test
2> <1f> Stream DMA Wr, IOMMU hit, Scache Miss Lpbk Test
2> <1f> Stream DMA Wr, IOMMU Miss, Scache(prev rd) Hit Ebus Test
2> <1f> Stream DMA Wr, IOMMU Miss, Scache(prev rd) Hit Lpbk Test
2> <1f> Stream DMA Wr, IOMMU Hit, Scache(prev rd) Hit Ebus Test
2> <1f> Stream DMA Wr, IOMMU Hit, Scache(prev rd) Hit Lpbk Test
2> <1f> Stream DMA Wr, IOMMU Miss, Scache(prev wr) Hit Ebus Test
2> <1f> Stream DMA Wr, IOMMU Miss, Scache(prev wr) Hit Lpbk Test
2> <1f> Stream DMA Wr, IOMMU Hit, Scache(prev wr) Hit Ebus Test
2> <1f> Stream DMA Wr, IOMMU Hit, Scache(prev wr) Hit Lpbk Test
2> <1f> Pass-Thru DMA Rd, Ebus device Test
2> <1f> Pass-Thru DMA Rd, Loopback Mode Test
2> <1f> Pass-Thru DMA Wr, Ebus device Test
2> <1f> Pass-Thru DMA Wr, Loopback Mode Test
2> <1f> Consist DMA Rd, IOMMU LRU Lock Ebus Test
2> <1f> Consist DMA Rd, IOMMU LRU Lock Lpbk Test
2> <1f> Stream DMA Rd, IOMMU LRU Lock, Scache LRU Lock Ebus Test
2> <1f> Stream DMA Rd, IOMMU LRU Lock, Scache LRU Lock Lpbk Test
2> <1f> Stream DMA Rd, IOMMU miss, Scache LRU Lock Ebus Test
2> <1f> Stream DMA Rd, IOMMU Miss, Scache LRU Lock Lpbk Test
2> <1f> Stream DMA Rd, IOMMU Hit, Scache LRU Lock Ebus Test
2> <1f> Stream DMA Rd, IOMMU Hit, Scache LRU Lock Lpbk Test
2> <1f> Stream DMA Rd, IOMMU LRU Lock, Scache Miss Ebus Test
2> <1f> Stream DMA Rd, IOMMU LRU Lock, Scache Miss Lpbk Test
2> <1f> Consist DMA Wr, IOMMU LRU Locked Ebus Test
2> <1f> Consist DMA Wr, IOMMU LRU Lock Lpbk Test
2> <1f> Stream DMA Wr, IOMMU LRU Lock, Scache LRU Lock Ebus Test
2> <1f> Stream DMA Wr, IOMMU LRU Lock, Scache LRU Lock Lpbk Test
2> <1f> Stream DMA Wr, IOMMU Miss, Scache LRU Lock Ebus Test
2> <1f> Stream DMA Wr, IOMMU Miss, Scache LRU Lock Lpbk Test
2> <1f> Stream DMA Wr, IOMMU Hit, Scache LRU Lock Ebus Test
2> <1f> Stream DMA Wr, IOMMU Hit, Scache LRU Lock Lpbk Test
2> <1f> Stream DMA Wr, IOMMU LRU Lock, Scache Miss Ebus Test
2> <1f> Stream DMA Wr, IOMMU LRU Lock, Scache Miss Lpbk Test
2> <1f> Stream DMA Wr, IOMMU LRU Lock, Scache(prev rd) Hit Ebus Test
2> <1f> Stream DMA Wr, IOMMU LRU Lock, Scache(prev rd) Hit Lpbk Test
2> <00> UltraSPARC-2 Prefetch Instructions Test
2> <00> Test 0: prefetch_mr
2> <00> Test 1: prefetch to non-cacheable page
2> <00> Test 2: prefetch to page with dmmu misss
2> <00> Test 3: prefetch miss does not check alignment
2> <00> Test 4: prefetcha with asi 0x4c is noped
2> <00> Test 5: prefetcha with asi 0x54 is noped
2> <00> Test 6: prefetcha with asi 0x6e is noped
2> <00> Test 7: prefetcha with asi 0x76 is noped
2> <00> Test 8: prefetch with fcn 5
2> <00> Test 9: prefetch with fcn 2
2> <00> Test 10: prefetch with fcn 12
2> <00> Test 11: prefetch with fcn 16 is noped
2> <00> Test 12: prefetch with fcn 29 is noped
2> <00> Test 13: prefetcha with asi 0x15 is noped
2> <00> Test 14: prefetch with fcn 3
2> <00> Test 15: prefetcha14 with fcn 2
2> <00> Test 16: prefetcha80_mr
2> <00> Test 17: prefetcha81_1r
2> <00> Test 18: prefetcha10_mw
2> <00> Test 19: prefetcha80_17 is noped
2> <00> Test 20: prefetcha10_6: illegal instruction trap
2> <00> Test 21: prefetcha11_1w
2> <00> Test 22: prefetcha81_31
2> <00> Test 23: prefetcha11_15: illegal instruction trap
2>STATUS =PASSED
Power On Selftest Completed
Status = 0000.0000.0000.0000 ffff.ffff.f00b.3f58 ff9f.ffff.0bd1.1111
Software Power ON
CPU Offline (not present)
CPU Offline (not present)
Master CPU : 0000.0002.0055.11a0
CPU Offline (not present)
Master E$ : 0000.0000.0040.0000
@(#) UPA/PCI 3.31 Version 0 created 2001/07/25 20:35
Clearing DTAG Done
Probing Memory
CONFIG = 0000.0000.0000.1010
MEM BASE = 0000.0000.0000.0000
MEM SIZE = 0000.0000.8000.0000
MMUs ON
Copy Done
PC = 0000.01ff.f000.2b30
PC = 0000.0000.0000.2b74
Decompressing into Memory Done
Size = 0000.0000.0006.ee80
ttya initialized
SC Control: EWP:0 IAP:0 FATAL:0 WAKEUP:0 BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0
Probing Memory Bank #0 512 512 512 512 : 2 Gigabytes
Probing Floppy: drive detected on ID0
Probing EBUS Nothing there
Probing UPA Slot at 1e,0 SUNW,gfb
Probing UPA Slot at 1d,0 Nothing there
Probing /pci@1f,4000 at Device 1 pci108e,1000 network
Probing /pci@1f,4000 at Device 3 scsi disk tape scsi disk tape
Probing /pci@1f,4000 at Device 2 Nothing there
Probing /pci@1f,4000 at Device 4 Nothing there
Probing /pci@1f,4000 at Device 5 Nothing there
Probing /pci@1f,2000 at Device 1 Nothing there
Sun Ultra 80 UPA/PCI (UltraSPARC-II 450MHz), No Keyboard
OpenBoot 3.31, 2048 MB memory installed, Serial #15739929.
Ethernet address 8:0:20:f0:2c:19, Host ID: 80f02c19.
Initializing 2047 megs of memory at addr ...Wie man sehen kann, liegt kein erkennbarer Hardware-Defekt vor. Weiterhin die Ausgabe von "show-devs" und "dev-alias".
ok show-devs
/SUNW,gfb@1e,0
/SUNW,UltraSPARC-II@2,0
/counter-timer@1f,1c00
/pci@1f,2000
/pci@1f,4000
/virtual-memory
/memory@0,0
/aliases
/options
/openprom
/chosen
/packages
/pci@1f,4000/scsi@3,1
/pci@1f,4000/scsi@3
/pci@1f,4000/network@1,1
/pci@1f,4000/ebus@1
/pci@1f,4000/scsi@3,1/tape
/pci@1f,4000/scsi@3,1/disk
/pci@1f,4000/scsi@3/tape
/pci@1f,4000/scsi@3/disk
/pci@1f,4000/ebus@1/flashprom@10,0
/pci@1f,4000/ebus@1/eeprom@14,0
/pci@1f,4000/ebus@1/fdthree@14,3023f0
/pci@1f,4000/ebus@1/ecpp@14,3043bc
/pci@1f,4000/ebus@1/su@14,3062f8
/pci@1f,4000/ebus@1/su@14,3083f8
/pci@1f,4000/ebus@1/se@14,400000
/pci@1f,4000/ebus@1/sc@14,500000
/pci@1f,4000/ebus@1/SUNW,pll@14,504000
/pci@1f,4000/ebus@1/power@14,724000
/pci@1f,4000/ebus@1/auxio@14,726000
/openprom/client-services
/packages/sun-keyboard
/packages/SUNW,builtin-drivers
/packages/disk-label
/packages/obp-tftp
/packages/deblocker
/packages/terminal-emulator
ok devalias
screen /SUNW,gfb@1e,0
net /pci@1f,4000/network@1,1
disk /pci@1f,4000/scsi@3/disk@0,0
cdrom /pci@1f,4000/scsi@3/disk@6,0:f
tape /pci@1f,4000/scsi@3,1/tape@4,0
tape1 /pci@1f,4000/scsi@3,1/tape@5,0
tape0 /pci@1f,4000/scsi@3,1/tape@4,0
disk6 /pci@1f,4000/scsi@3/disk@6,0
disk5 /pci@1f,4000/scsi@3/disk@5,0
disk4 /pci@1f,4000/scsi@3/disk@4,0
disk3 /pci@1f,4000/scsi@3/disk@3,0
disk2 /pci@1f,4000/scsi@3/disk@2,0
disk1 /pci@1f,4000/scsi@3/disk@1,0
disk0 /pci@1f,4000/scsi@3/disk@0,0
scsi /pci@1f,4000/scsi@3
floppy /pci@1f,4000/ebus@1/fdthree
ttyb /pci@1f,4000/ebus@1/se:b
ttya /pci@1f,4000/ebus@1/se:a
keyboard! /pci@1f,4000/ebus@1/su@14,3083f8:forcemode
keyboard /pci@1f,4000/ebus@1/su@14,3083f8
mouse /pci@1f,4000/ebus@1/su@14,3062f8
name aliases
So nun zur Lösung, auf die ich im übrigen wieder am Ende all' meine Optionen zufällig gestoßen bin:
Ich wusste bereits, dass Solaris 2.5.1 HW 11/97 das erste von der Ultra 80 unterstützte Release ist. In einer meiner letzten Beiträge schrieb ich:
... Dazu die Gewissheit, dass der Onboard-Chip und die Kabel von der Hauptplatine zur HDD-Backplane und von da zum internen Laufwerk nicht die Ursache sein können. Auch ein Laufwerks-Defekt bei 4 optischen Laufwerken kann dann ausgeschlossen werden. Zudem habe ich es gleich noch mit Solaris 2.5.1 versucht. Hier konnte er jetzt den Kernel nicht finden, was hoffen lässt.
Nun war ich so frei, es nochmal zu probieren und mir die Sache mit dem Kernel-Pfad nachzulesen:
ok boot cdrom -v
Boot device: /pci@1f,4000/scsi@3/disk@6,0:f File and args: -v
boot: cannot open kernel/unix
Enter filename [kernel/unix]: /platform/sun4u/kernel/sparcv9/unix
boot: cannot open /platform/sun4u/kernel/sparcv9/unix
Enter filename [kernel/unix]: /platform/sun4u/kernel/unix
Size: 259952+60420+93532 Bytes
Enter default directory for modules [/platform/sun4u/kernel /kernel /usr/kernel]:
cpu0: SUNW,UltraSPARC-II (upaid 2 impl 0x11 ver 0xa0 clock 450 MHz)
SunOS Release 5.5.1 Version Generic_103640-12 [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1996, Sun Microsystems, Inc.
Using default device instance data
mem = 2097152K (0x80000000)
avail mem = 2120065024
Ethernet address = 8:0:20:f0:2c:19
root nexus = Sun Ultra 80 UPA/PCI (UltraSPARC-II 450MHz)
pci108e,80000 at root: UPA 0x1f 0x4000
pci108e,80001 at root: UPA 0x1f 0x2000
glm0: Rev. 4 Symbios 53c875 found.
PCI-device: scsi@3, glm #0
glm1: Rev. 4 Symbios 53c875 found.
PCI-device: scsi@3,1, glm #1
sd0 at glm0: target 0 lun 0
sd0 is /pci@1f,4000/scsi@3/sd@0,0
<SUN36G cyl 24620 alt 2 hd 27 sec 107>
sd6 at glm0: target 6 lun 0
sd6 is /pci@1f,4000/scsi@3/sd@6,0
<CD-ROM Disc for SunOS Solaris_2.5.1 Installation >
root on /pci@1f,4000/scsi@3/disk@6,0:b fstype ufs
PCI-device: ebus@1, ebus #0
su0 at ebus0: offset 14,3083f8
su0 is /pci@1f,4000/ebus@1/su@14,3083f8
su1 at ebus0: offset 14,3062f8
su1 is /pci@1f,4000/ebus@1/su@14,3062f8
keyboard is </pci@1f,4000/ebus@1/su@14,3083f8> major <37> minor <0>
mouse is </pci@1f,4000/ebus@1/su@14,3062f8> major <37> minor <1>
se0 at ebus0: offset 14,400000
se0 is /pci@1f,4000/ebus@1/se@14,400000
stdin is </pci@1f,4000/ebus@1/se@14,400000:a> major <20> minor <0>
stdout is </pci@1f,4000/ebus@1/se@14,400000:a> major <20> minor <0>Configuring the /devices directory
SUNW,hme0: CheerIO 2.0 (Rev Id = c1) Found
PCI-device: network@1,1, hme #0
SUNW,hme0 is /pci@1f,4000/network@1,1
st4: <Vendor 'HP ' Product 'C1537A '>
st4 at glm0: target 4 lun 0
st4 is /pci@1f,4000/scsi@3/st@4,0
fdthree0 at ebus0: offset 14,3023f0
fdthree0 is /pci@1f,4000/ebus@1/fdthree@14,3023f0
ecpp0 at ebus0: offset 14,3043bc
ecpp0 is /pci@1f,4000/ebus@1/ecpp@14,3043bc
pseudo-device: llc10
llc10 is /pseudo/llc1@0
Configuring the /dev directory
SUNW,hme0: Link Down - cable problem?
The system is coming up. Please wait.
What type of terminal are you using?
1) ANSI Standard CRT
2) DEC VT52
3) DEC VT100
4) Heathkit 19
5) Lear Siegler ADM31
6) PC Console
7) Sun Command Tool
8) Sun Workstation
9) Televideo 910
10) Televideo 925
11) Wyse Model 50
12) X Terminal Emulator (xterms)
13) Other
Type the number of your choice and press Return:An diesem Punkt war mir spätestens bewusst: die Ursache ist der 64-Bit Kernel "/platform/sun4u/kernel/sparcv9/unix". Also was wird man als nächsten Schritt in Erwägung ziehen - korrekt: den 32-Bit Kernel.
ok boot cdrom /platform/sun4u/kernel/unix[/color] -v
Weitere Beweise im nächsten Beitrag, weil ich schon wieder die 20.000-Zeichen gesprengt habe. ;)
-
Ich wusste bereits, dass Solaris 2.5.1 HW 11/97 das erste von der Ultra 80 unterstützte Release ist.
Ich verstehe nur nicht, warum du krampfhaft versuchst, dieses grottig-alte Release auf die arme Ultra80 zu pressen.
Das Ding läuft doch auch mit moderner Software. ???
-
@Ebbi: Keine Sorge Ebbi. Solaris 2.5.1 läuft nur auf der SS20. Ich brauchte jedoch alternative Medien zum Austesten. ;)
Hier die Beweise für die Problematik zum 64-Bit Boot-Kernel.
[1] Solaris 10 Release 11/06
ok boot cdrom -v
Boot device: /pci@1f,4000/scsi@3/disk@6,0:f File and args: -v
Size: 0x7a768+0x1c319+0x30443 Bytes
module /platform/sun4u/kernel/sparcv9/unix: text at [0x1000000, 0x107a767] data at 0x1800000
module misc/sparcv9/krtld: text at [0x107a768, 0x10933af] data at 0x184c760
module /platform/sun4u/kernel/sparcv9/genunix: text at [0x10933b0, 0x11f0f17] data at 0x1852000
module /platform/SUNW,Ultra-80/kernel/misc/sparcv9/platmod: text at [0x11f0f18, 0x11f0faf] data at 0x18a4550
module /platform/sun4u/kernel/cpu/sparcv9/SUNW,UltraSPARC-II: text at [0x11f0fc0, 0x11fd1c7] data at 0x18a4c80
SunOS Release 5.10 Version Generic_118833-33 64-bit
Copyright 1983-2006 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
...
Setting up Java. Please wait...
Beginning system identification...
Searching for configuration file(s)...
Search complete.
Discovering additional network configuration...
Select a Language
0. English
1. French
2. German
3. Italian
4. Japanese
5. Korean
6. Simplified Chinese
7. Spanish
8. Swedish
9. Traditional Chinese
Please make a choice (0 - 9), or press h or ? for help: ^CFeb 9 11:17:27 svc.startd[7]: instance svc:/system/install-setup:default exited with status 130
Exiting to shell...
# halt
syncing file systems... done
Program terminated
[2] Solaris Express Community Edition Build 78
ok boot cdrom -v
Boot device: /pci@1f,4000/scsi@3/disk@6,0:f File and args: -v
Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
FCode UFS Reader 1.13 05/06/08 08:30:31.
Redirected to slice: 1
Loading: /platform/SUNW,Ultra-80/ufsboot
Loading: /platform/sun4u/ufsboot
Size: 0x9fca7+0x1b928+0x453b4 Bytes
module /platform/sun4u/kernel/sparcv9/unix: text at [0x1000000, 0x109fca7] data at 0x1800000
module misc/sparcv9/krtld: text at [0x109fca8, 0x10bab7f] data at 0x1860ce0
module /platform/sun4u/kernel/sparcv9/genunix: text at [0x10bab80, 0x12a4657] data at 0x1866b00
module /platform/SUNW,Ultra-80/kernel/misc/sparcv9/platmod: text at [0x12a4658, 0x12a4797] data at 0x18bb268
module /platform/sun4u/kernel/cpu/sparcv9/SUNW,UltraSPARC-II: text at [0x12a47c0, 0x12b14f7] data at 0x18bb940
SunOS Release 5.11 Version snv_78 64-bit
Copyright 1983-2007 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
...
Setting up Java. Please wait...
Beginning system identification...
Searching for configuration file(s)...
Search complete.
Discovering additional network configuration...
Select a Language
1. English
2. French
3. German
4. Italian
5. Japanese
6. Korean
7. Simplified Chinese
8. Spanish
9. Swedish
10. Traditional Chinese
Please make a choice (1 - 10), or press h or ? for help: ^CExiting to shell...
#Bei beiden Versionen wird der 64-Bit Kernel genutzt. Im folgenden die Boot-Prozedur mit den 32-Bit Kernel und Modulen
[3] Solaris 8 Release 2/04 HW-Update 4 (CD-R)
boot cdrom /platform/sun4u/kernel/unix -v
Boot device: /pci@1f,4000/scsi@3/disk@6,0:f File and args: /platform/sun4u/kernel/unix -v
Size: 343592+55726+57618 Bytes
SunOS Release 5.8 Version Generic_108528-29 32-bit
Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved.
Ethernet address = 8:0:20:f0:2c:19
Using default device instance data
mem = 2097152K (0x80000000)
avail mem = 2075222016
root nexus = Sun Ultra 80 UPA/PCI (UltraSPARC-II 450MHz)
pcipsy0 at root: UPA 0x1f 0x4000
pcipsy0 is /pci@1f,4000
pcipsy1 at root: UPA 0x1f 0x2000
pcipsy1 is /pci@1f,2000
/pci@1f,4000/scsi@3 (glm0):
Rev. 5 Symbios 53c875 found.
PCI-device: scsi@3, glm0
glm0 is /pci@1f,4000/scsi@3
/pci@1f,4000/scsi@3,1 (glm1):
Rev. 5 Symbios 53c875 found.
PCI-device: scsi@3,1, glm1
glm1 is /pci@1f,4000/scsi@3,1
sd0 at glm0: target 0 lun 0
sd0 is /pci@1f,4000/scsi@3/sd@0,0
<SUN36G cyl 24620 alt 2 hd 27 sec 107>
sd6 at glm0: target 6 lun 0
sd6 is /pci@1f,4000/scsi@3/sd@6,0
root on /pci@1f,4000/scsi@3/disk@6,0:b fstype ufs
PCI-device: ebus@1, ebus0
power0 at ebus0: offset 14,724000
power0 is /pci@1f,4000/ebus@1/power@14,724000
su0 at ebus0: offset 14,3083f8
su0 is /pci@1f,4000/ebus@1/su@14,3083f8
su1 at ebus0: offset 14,3062f8
su1 is /pci@1f,4000/ebus@1/su@14,3062f8
se0 at ebus0: offset 14,400000
cpu2: UltraSPARC-II (portid 2 impl 0x11 ver 0xa0 clock 450 MHz)
Configuring /dev and /devices
pseudo-device: devinfo0
devinfo0 is /pseudo/devinfo@0
SUNW,hme0 : PCI IO 2.0 (Rev Id = c1) Found
PCI-device: network@1,1, hme0
hme0 is /pci@1f,4000/network@1,1
/pci@1f,4000/scsi@3/st@4,0 (st4):
<HP DDS-3 4MM DAT>
st4 at glm0: target 4 lun 0
st4 is /pci@1f,4000/scsi@3/st@4,0
fd0 at ebus0: offset 14,3023f0
fd0 is /pci@1f,4000/ebus@1/fdthree@14,3023f0
ecpp0 at ebus0: offset 14,3043bc
ecpp0 is /pci@1f,4000/ebus@1/ecpp@14,3043bc
pseudo-device: fssnap0
fssnap0 is /pseudo/fssnap@0
pseudo-device: winlock0
winlock0 is /pseudo/winlock@0
pseudo-device: lockstat0
lockstat0 is /pseudo/lockstat@0
pseudo-device: llc10
llc10 is /pseudo/llc1@0
pseudo-device: lofi0
lofi0 is /pseudo/lofi@0
pseudo-device: fcp0
fcp0 is /pseudo/fcp@0
Using RPC Bootparams for network configuration information.
SUNW,hme0 : No response from Ethernet network : Link down -- cable problem?
Skipping interface hme0
Searching for configuration file(s)...
The Solaris Installer can be run in English, or any of the following languages:
1) English 6) Japanese
2) German 7) Korean
3) Spanish 8) Swedish
4) French 9) Simplified_Chinese
5) Italian 10) Traditional_Chinese
Select the language you want to use to run the installer: ^C
# halt
syncing file systems... done
Program terminated
ok
[4] Solaris 9 Release 9/04 (DVD)
ok boot cdrom /platform/sun4u/kernel/unix -v
Boot device: /pci@1f,4000/scsi@3/disk@6,0:f File and args: /platform/sun4u/kernel/unix -v
Size: 0x5b47f+0xe83d+0x1cd97 Bytes
SunOS Release 5.9 Version Generic_117171-07 32-bit
Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Ethernet address = 8:0:20:f0:2c:19
Using default device instance data
mem = 2097152K (0x80000000)
avail mem = 2071166976
root nexus = Sun Ultra 80 UPA/PCI (UltraSPARC-II 450MHz)
pcipsy0 at root: UPA 0x1f 0x4000
pcipsy0 is /pci@1f,4000
pcipsy1 at root: UPA 0x1f 0x2000
pcipsy1 is /pci@1f,2000
/pci@1f,4000/scsi@3 (glm0):
Rev. 5 Symbios 53c876 found.
PCI-device: scsi@3, glm0
glm0 is /pci@1f,4000/scsi@3
PCI-device: scsi@3, glm0
glm0 is /pci@1f,4000/scsi@3
/pci@1f,4000/scsi@3,1 (glm1):
Rev. 5 Symbios 53c876 found.
PCI-device: scsi@3,1, glm1
glm1 is /pci@1f,4000/scsi@3,1
PCI-device: scsi@3,1, glm1
glm1 is /pci@1f,4000/scsi@3,1
sd0 at glm0: target 0 lun 0
sd0 is /pci@1f,4000/scsi@3/sd@0,0
sd6 at glm0: target 6 lun 0
sd6 is /pci@1f,4000/scsi@3/sd@6,0
root on /pci@1f,4000/scsi@3/disk@6,0:b fstype ufs
PCI-device: ebus@1, ebus0
ebus0 is /pci@1f,4000/ebus@1
power0 at ebus0: offset 14,724000
power0 is /pci@1f,4000/ebus@1/power@14,724000
su0 at ebus0: offset 14,3083f8
su0 is /pci@1f,4000/ebus@1/su@14,3083f8
su1 at ebus0: offset 14,3062f8
su1 is /pci@1f,4000/ebus@1/su@14,3062f8
se0 at ebus0: offset 14,400000
se0 is /pci@1f,4000/ebus@1/se@14,400000
cpu2: UltraSPARC-II (portid 2 impl 0x11 ver 0xa0 clock 450 MHz)
Configuring /dev and /devices
pseudo-device: devinfo0
devinfo0 is /pseudo/devinfo@0
SUNW,hme0 : PCI IO 2.0 (Rev Id = c1) Found
PCI-device: network@1,1, hme0
hme0 is /pci@1f,4000/network@1,1
/pci@1f,4000/scsi@3/st@4,0 (st4):
<HP DDS-3 4MM DAT>
st4 at glm0: target 4 lun 0
st4 is /pci@1f,4000/scsi@3/st@4,0
fd0 at ebus0: offset 14,3023f0
fd0 is /pci@1f,4000/ebus@1/fdthree@14,3023f0
gfb0 at root: UPA 0x1e 0x0
gfb0 is /SUNW,gfb@1e,0
pseudo-device: fssnap0
fssnap0 is /pseudo/fssnap@0
ecpp0 at ebus0: offset 14,3043bc
ecpp0 is /pci@1f,4000/ebus@1/ecpp@14,3043bc
pseudo-device: ramdisk1024
ramdisk1024 is /pseudo/ramdisk@1024
pseudo-device: winlock0
winlock0 is /pseudo/winlock@0
pseudo-device: lockstat0
lockstat0 is /pseudo/lockstat@0
pseudo-device: llc10
llc10 is /pseudo/llc1@0
pseudo-device: lofi0
lofi0 is /pseudo/lofi@0
pseudo-device: fcp0
fcp0 is /pseudo/fcp@0
pseudo-device: trapstat0
trapstat0 is /pseudo/trapstat@0
Using RPC Bootparams for network configuration information.
SUNW,hme0 : No response from Ethernet network : Link down -- cable problem?
SUNW,hme0 : No response from Ethernet network : Link down -- cable problem?
Skipping interface hme0
Searching for configuration file(s)...
Search complete.
Select a Language
0. English
1. French
2. German
3. Italian
4. Japanese
5. Korean
6. Simplified Chinese
7. Spanish
8. Swedish
9. Traditional Chinese
Please make a choice (0 - 9), or press h or ? for help: ^C
# halt
syncing file systems... done
Program terminated
ok
Mystery solved. File closed. :)
Grüße
escimo
-
Ich glaube ich habe mich zu früh gefreut. :(
Jetzt konnte ich zwar mit Hilfe des 32-Bit Kernel Solaris 8 HW4 (2/04) installieren, doch ich kann das System nun nicht mit dem 64-Bit Kernel starten, da der schon zuvor beschriebene Effekt eintritt. Wie soll ich so etwas fixen?
Ich habe erst mal die OBP-Variable boot-file entsprechend auf den 32-Bit Kernel Mode konfiguriert:
{1} ok setenv boot-file /platform/sun4u/kernel/unix
Gib es einen Patch, der den 64-Bit Kernel unter "/platform/sun4u/kernel/sparcv9/unix" fixt?
Grüße
escimo
-
Hallo Stephan,
sowohl Solaris 2.5.1 HW 11/97 als auch Solaris 2.6 2.6 HW 5/98 lassen sich auf der Ultra 80/E420R installieren, vorausgesetzt der passende Kernel wird vorher durch Booten von der OECD (enthält ein Solaris 7) geladen.
Beim direkten Booten der beiden Medien kommt die Meldung über den fehlenden Kernel.
Stichwort: UltraSPARC II >= 400 MHz
Solaris 2.5.1 und Solaris 2.6 sind leider schlechte Beispiele für 64-Bit Kernel, denn die erste Version mit 64-Bit Kernel war Solaris 7.
Das hilft dir mit deinem Problem aber auch nicht weiter ...
Michael
-
Das hilft dir mit deinem Problem aber auch nicht weiter ...
Hallo Michael, ja leider nicht. Wie bereits erwähnt ist nun neben Solaris Express CE Build 78 - bei dem der 64-Bit Kernel funktioniert - noch Solaris 8 HW4 (2/04) - bei dem es einzig mit dem 32-Bit Kernel bootet - auf der anderen Festplatte installiert. Leider hat auch der Recommended Patch Cluster im Anschluss noch keine Besserung gebracht.
Ich überlege, ob ich den "kadb" zu Rate ziehen sollte.
Das ist aber auch ein sehr merkwürdiges Problem. Da wird man ja geradezu gezwungen auf die neue Version (Solaris 10 und höher) zu schwenken. :-\
Gruß
Stephan
-
Die Idee mit dem Kernel-Debugger ist mir auch gekommen, nur hast du damit schon gearbeitet ?
Für Solaris x86 gibt es dazu eine Dokumentation von Frank Hofmann (http://blogs.sun.com/ambiguous/)
The Solaris Operating System on x86 Platforms Crashdump Analysis Operating System Internals (http://opensolaris.org/os/community/documentation/files/book.pdf)
Für SPARC ist man wahrscheinlich auf docs.sun.com (kostenlos) oder das Buch PANIC! UNIX System Crash Dump Analysis Handbook von Chris Drake und Kimberly Brown (http://blogs.sun.com/Kimberley/) angewiesen.
Michael
-
Moin,
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). Soweit ich das auf den ersten Blick sehe hast du aber (ausser der Grafikkarte) keine weiteren Karten eingebaut, richtig?
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.
Leider ist der "Boothaenger" noch relativ weit am Anfang (dadurch kann man keinen Crashdump zur Analyse ziehen) und ist da wirklich auf den Kernel-Debugger angewiesen. Mach einfach mal folgendes (am besten mit Solaris 10 CD):
<ok> boot kmdb -d
Dann sollte ein Prompt erscheinen:
Welcome to kmdb
Dort dann "moddebug/W 0xe0000000" eingeben (ohne die Anfuehrungsstriche) und dann ein ":c" um den Bootvorgang fortzusetzen.
Mal sehen was da als letztes geladen wird....
Falls du dann wieder den Haenger hast, dann mittels STOP-A (oder send break falls ueber Serial drin) in den kmdb wechseln. Dort dann erstmal den folgenden Befehl:
(falls das nach der ersten Seite stoopt bitte einmal "c" druecken - dann kommt der Rest).
Die Ausgaben on dem moddebug und der $<threadlist werden recht gross (sicherlich zu gross fuer ein Posting hier). Vielleicht kannst du die irgendwo zum Download hinstellen.
Ich hatte mal ein aehnliches Phaenomen bei einer defekten CPU (wobei ich allerdings zwei in meiner Ultra 60 habe und dann die Kiste beim Initialisieren der zweiten CPU hing). 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)?
Tschau,
Drusus.
-
Moin,
achja: an der Stelle wo du den Haenger siehst wird ueblicherweise Hostname gesetzt etc.
Nicht dass du hier auf einen Timeout vom Netz (DHCP etc.) wartest...
Hast du da nur das onboard Netzwerk-Interface oder noch irgendwas weiteres dran/drin?
Bevor man mit kmdb und co. rangeht vielleicht mal sehen welche Start Methode hier gerade laeuft. Mach doch mal ein
<ok> boot cdrom -m verbose
(mit der Solaris 10 CD).
Tschau,
Drusus.
-
Die Idee mit dem Kernel-Debugger ist mir auch gekommen, nur hast du damit schon gearbeitet ?
Ö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:
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
-
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.
-
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:
{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
-
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.
-
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:
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
-
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:
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 (http://developers.sun.com/solaris/developer/support/driver/docs/OBP-stuff/forthdebug.pdf) (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 (http://learningsolaris.com/docs/chpt_mdb_os.pdf), Seite 67 "3.7.2.2 Implementation As a Kernel Module". Ich werde dann doch mal lieber auf den (k)mdb schwenken.
-
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
-
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.
-
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
-
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.
-
[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... ???
-
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.
-
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. :-[
-
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. :D 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. ;)
-
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. :D 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.
-
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. (http://planetsmilies.net/tired-sleeping-smiley-17394.gif)
Gruß
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. (http://www.contentschmiede.de/wp-content/emoticons/wall.gif)
Beispiel eines anderen Solaris8-Systems:
$ 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.
-
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. (http://www.contentschmiede.de/wp-content/emoticons/wall.gif)
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.
-
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 :o
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 (http://www.sonnenblen.de/sun_sparc/speicherproblem_bei_ultra_80-t4861.0.html)" 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 (http://www.sun.com/bigadmin/content/selfheal/selfheal_overview.pdf)", 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
-
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
-
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. :o
Hattest du jemals ein "abgemagertes" Speichermodul?
Gruß
Stephan
-
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.
-
...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. :-\