Debian Sarge mit Kern 2.4.27 auf SMP (Ross) Teil 1

[RolfD]

Als eifriger Leser der Sonnenblen.de möchte ich meine Erfahrungen mit der Installtion von Debian Sarge mit 2.4.27 Kernel auf einer SS20 SMP(Ross) weiter geben.

Grundsätzlich: Es geht.
Einschränkung: Es dauert... und man muss einige Hürden überwinden - was nicht immer mit "RTMF" allein zu machen ist.

Grundzustand war eine SS20 mit viel Speicher (512MB Vollausbau) sowie 2 Bridgeport (Ross) CPUs mit je 142 MHz und je 1 MB Cache, einigen SMB Karten und 2 x 18 GB Platten. Das Sys lief zuletzt unter Debian Woody mit 2.2er Kernel recht gut, die Bugfixes und Verbesserungen durch gcc 3.3.5 / Kernel 2.4.27 haben mich jedoch zu einer Neuinstallation bewogen. Ziel ist es, den Rechner als Router / Internet Dienste Server (Stabilität vor Geschwinigkeit) hinter einem (ish.de) Kabelmodem mit 2mbit laufen zu lassen. Also los gehts...

-> Tag 1
Download der Debian Netinstall CD für Sparc Sarge von einem Mirror. Die Sun bootete ohne weiteres von der gebrannten CD und eine Mini-install war "recht schnell" aufgespielt. Als Default verwendet das Netinstall ext3 Filesysteme (was später noch zu Problemen führen sollte...). Da ich aber eh ext3 nutzen wollte, war mir das erst mal recht. Nebenbei: Der von CD startende Debianinstaller ist sowas von lahm, das es einen abschreckt, eine SS20 zu installieren... aber die Geduld lohnt dann doch irgendwann.

Das gebootete Image installiert "netter Weise" direkt den SMP Kernel und beim nächsten booten begrüssen schon 2 Pinguine den eifrigen Sparcbesitzer... Jubel bricht aus... so schnell ... so einfach... die Freude hat jedoch 15 Zeilen tiefer ein jähes Ende. Kernel Panic wegen nicht ladbarer initrd! (die Partition mit /boot und / lag unter 1 GB)

Da das ext3 Filesystem und der scsi Treiber scheinbar mit einer initrd geladen wird, und bei mir jede Ramdisk mit "bad MagicNr" und Kernel Panic stehen blieb, entfernte ich kurzer Hand eine CPU aus dem Rechner, da ich Lade-/Speicherprobleme des Kernels vermutete. Es kann aber auch sein, das ich einfach Fehler beim Erstellen der neuen Ramdisk gemacht habe oder sonst was vergessen / nicht beachtet habe.

Also neuer Versuch mit nur einer CPU und siehe da, der Kernel liess sich nun mit Initrd ladend komplett starten. Damit war schon mal wieder ein Linux auf dem Rechner und ca. 1 Tag an Fummelei mit einem Teilerfolg gekrönt. Daß 2.4er Kernel auf UP-Rechnern laufen würden, wusste ich von der Website "http://osinvestor.com/sparc/"

[RolfD]

-> Tag 2
Da ich 2 CPUs habe, möchte ich auch beide nutzen... (ich hätte gern die 200MHz DualCPUs, also 4 CPUs pro Rechner, aber die Preise liegen jenseits vom für mich machbaren und sind zudem super selten zu kriegen)! Um ein Fehler im Kernel auszuschliessen, die üblichen Utils für den Kernelbau installiert, die original Debian Kernel Quellen gezogen und alles durch den gcc gescheucht. Nach ca. 6h hatte ich eine viel zu grosse Kernelversion (limit 2,6MB ungezipt) und musste massiv abspecken. Also noch mal alles durch den gcc... und diesmal passte er dann... 2,4 MB... dann mit "mkinitrd" eine ramdisk gebaut... 2.te CPU rein.. gebootet ... 2 Pinguine ... und nach 15 Zeilen Kernelpanic.
Wieder ein Tag im Eimer und alles noch mal aufsetzen...
Ich bekam Zweifel an meinem Vorhaben.

->Tag 3
Neuer Versuch...neues Glück! Da offensichtlich das Laden der initrd nur unter SMP fehlschlug - warum weiss der Geier (und evtl. die Silo/Kernelprogger) - beschloss ich, wieder eine Install mit einer CPU zu machen und für den zu compilierenden SMP Kernel die Initrd abzuschalten. Dazu musste jedoch ext3 und der ESP SCSI Treiber fest im Kernel integriert werden...wegen Platzproblemen (die berühmte 2,6MB Kernel Beschränkung) stellte ich in "menuconfig" dann ext2 auf M für Modul.. so wie verschiedene andere Optionen ebenfalls. Ich konnte mir einen Kernel ohne ext2 nicht wirklich vorstellen und rechnete fest mit einem Fehlschlag. Um die Vorteile der Hypersparc CPUs auch zu nutzen, stellte ich vorher noch im makefile unter arch/sparc die CFLAGS auf zusätzliche "-mv8 -mtune=ultrasparc" ein. Im ersten Anlauf wurde er wieder zu gross.. im zweiten (noch weiter modularisierten / reduzierten) Anlauf und weitere 6h später passte er dann endlich.

Also Kernel installiert, zweite CPU rein, gebootet... und am Ende eines langen dritten Tages fuhr der Rechner mit zwei CPUs und ohne Kernelpanic endlich hoch. Ich staunte nicht schlecht.
Der Kernel lies sich prima starten, lud alle Module nach und machte keine Probleme. Einige kleinere Tests bewiesen, das der Kern stabil scheint und die 2.te CPU gut unterstützt.

Hier meine /proc/cpuinfo:

cpu             : ROSS HyperSparc RT625 or RT626
fpu             : ROSS HyperSparc combined IU/FPU
promlib         : Version 3 Revision 2
prom            : 2.25
type            : sun4m
ncpus probed    : 2
ncpus active    : 2
Cpu0Bogo        : 142.13
Cpu1Bogo        : 142.13
MMU type        : ROSS HyperSparc
contexts        : 4096
nocache total   : 5242880
nocache used    : 374784
CPU0            : online
CPU1            : online

Aus füheren Versuchen mit dem SMP 2.2 und 2.4 sowie diversen Mailinglisten wusste ich, das Bogomips auf 2.4er SMP Sparc Kernel um ca. 30-40% einbricht. Dies ist hier nicht der Fall, was wohl evtl. auch an den Optionen in arch/sparc liegt.

[RolfD]

->Tag 4
Ich änderte in "menuconfig" noch einige Netzwerk Parameter, weil ich doch noch etwas "Platz" im Kernelfile hatte und der Rechner als Router auch noch einiges mehr können sollte. Mit "make -j 2 dep clean vmlinux modules" den gcc-Lauf angeschubst... dies soll meiner Info nach auf SMP Systemen den Compilerlauf deutlich beschleunigen helfen... ich habe zwar keine Zeiten genommen, aber kann das auch bestätigen. Nun hatte ich meinen vorläufig entgültigen Kernel mit SMP.

Dann... mutig geworden, lud ich mir den 2.4.31 Kern von "kernel.org" runter und wollte mich nun daran versuchen. Beim Lesen der Changelogs von 2.4.27 bis 2.4.31 sind mir doch einige Sachen aufgefallen, die ein Update in Relation zum weiteren Aufwand rechtfertigen. Wieder ein gcc Lauf mit dem .config aus dem 2.4.27 auf den 2.4.31 angewendet und der Kern wurde sauber erstellt. Der 31er Kern ist noch nicht gestartet, dazu werde ich noch was nachtragen.

->Tag 5
Mein System ist nun zwar nicht grade schnell (im vergleich zu Intel Rechnern neuer Bauart) aber deutlich belastbarer als eine Uniprozessor-installation und es scheint zudem alles stabil zu laufen. So freue mich nun, diesem schönen alten Rechner ein neues, moderneres Betriebssystem geben zu können, so daß er noch lange seinen Dienst tun wird.

Das kernel .config File hänge ich bei Interesse noch an. Wenn ich Platz und Trafic bekomme, kann ich den von mir gebauten 27.er und 31.er Kernel auch zum Download bereit stellen, obwohl das wohl wenig zweckmässig ist. Er ist recht spezialisiert, das .config File und diese Beschreibung helfen sicher mehr.

Derzeit versuche ich Mittels apt-build mein System komplett neu zu compilieren (was einige Tage dauern wird), da ich bemerkt habe, daß die Pakete mit "-mhypersparc -mtune=hypersparc" doch deutlich schneller sind, als die mit -mv7 compilierten Originale. Hinwiese aus dem Netz z.B. mit openssh bzw. der ssh Shell bestätigen das. Eine schöne Anleitung dazu liefert z.B. "http://julien.danjou.info/article-apt-build.html" und das readme zu apt-build. Das Schöne an der Geschichte... abt-build kann wunderbar im Hintergrund laufen, ohne daß es das System wirklich beeinträchtigt, und zur Not hilft man eben mit "renice" nach. Man kann aber nun mal aus einer alten Schildkröte keine Rennflunder machen - man sollte sich also nicht zu viel versprechen, das System läuft jedoch jetzt schon deutlich flüssiger als mit dem 2.2er Kern. Als "Heim"Server/Router/System zum Lernen/Testen hinter einer entsprechenden Kabelmodem Anbindung ist das System auch durch die verbaute SBUS Quad Ethernet Karte flexibler, schneller, vielseitiger und schöner als jede Popels-Routerbox mit mager-FW.

Gruß RolfD

[erisch]

Hallo

Interessanter Text.

Ein paar Anmerkungen:

Warum benutzt du eine initial ramdisk. Ist doch garnicht nötig. Wenn du Probleme damit hast, dann lass sie einfach weg.
Die ramdisk wird nur von Systemen benötigt, die von CD booten oder wenn die Treiber für das rootfilesystem extern geladen werden müssen.

Da du aber dein Zeugs eh alles im Kernel hast kannste dir das mit der ramdisk sparen.

Und zweitens:
-mtune=ultrasparc sollte Code erzeugen, der auf der SS20 gar nicht lauffähig ist, weil das mv8plus Code erzeugt.

Mfg. Erisch

[RolfD]

Hallo Erisch,

Das Handbuch zu gcc sagt eindeutig, das -mtune keine Codeoptimierungen vornimmt, sondern nur den Code z.B. für Ultrasparc in der Ladereihenfolge optimiert. Dies betrifft z.B. das Alignment von Daten und/oder Nops nach Branches... Da die Ultrasparc und die Hyperspar CPUs wohl näher verwand sind als die Hypersparc und V7 Architektur, nutzt diese Option sehr wohl was.
Die eigentliche Codegenerierung läuft mittels -mv8 schon richtig.

Hier noch mal ein Auszug aus dem gcc manual:
"-mtune=cpu_type
   Set the instruction scheduling parameters for machine type cpu_type, but do not set the instruction set or register set that the option -mcpu=cpu_type would."

Zum Thema Initrd, der Linux Kern von Debian hat das Ext2 fs fest eincomiliert und lädt das ext3 fs incl. ESP Treiber als Modul via initrd nach. Wenn ich eine ext3 Partition mit / und /boot habe, komme ich beim Booten nun mal nicht an die Partition so lange Initrd nicht geladen wird. In meinem Beitrag geht es u.A. auch darum, ext2 als Modul und ext3 als fest compilierten Code zu nutzen damit ich von einer ext3 Partition starten kann OHNE eine initrd zu nutzen.

Anmerkung: Ich habe den debian installer nicht dazu bekommen, /boot als separate Partition mit ext2 zu nutzen zumal das Laden der initrd trotzdem eine KP verursachte.

Gruß RolfD

[astronom]

Das klingt ja interessant, vielleicht kann ich auf ähnliche weise dieses Wochenende meiner SS20 mit 4x100MHz Ross auch wieder etwas leben einhauchen.
Wenn du deine .config anhängen könntest fände ich das klasse. Mir fehlt leider die Information welche Treiber ich in den Kernel bauen müsste um auf die initrd verzichten zu können.
Auch das Kernel-Image zu haben wäre eventuell nicht schlecht - da ich ja DualCPU's habe, habe ich leider keine option ohne SMP zu starten :-(
Sollte es mit dem Platz total hapern kann ich eventuell aushelfen. Wenn du eventuell den Modultree komplett weglassen könntest, so das man also mit dem Kernel alleine booten und dann die Module nachbauen kann, kann ich den Kernel auf meinen Webspace hochladen.

[RolfD]

Hallo Astronom,
da du 4x 100 Mhz hast (2x2 CPU Boards), wird es dir so nicht gelingen, auf diese Art das System zu installieren da du IMMER min 2 CPUs hast, selbst wenn du ein Bord aus dem System entfernst. Es wird bei dir also immer der SMP Kern installiert, welcher evtl. auch bei dir an der Initrd scheitert. Kann man aber eine CPU evtl. noch im OBP abschalten? Dann ginge mein Weg. Evtl. kann man meine Variante jedoch abwandeln oder mit einem vorkompiliertem Kern und / oder mit einer selbstgezimmerten Install CD was machen. Wenn ich also helfen kann, gern...

Edit: mir ist grade eingefallen, evtl. kannst Du die Sparc installieren in dem du eine einfache SingleCPU nimmst und die Grundinstallation durchführst, nur mit dieser CPU dann jedoch statt den Kern selbst zu bauen mein SMP-Kernel einspielst und DANN erst die beiden schnelleren CPU-Boards einsetzt.
Eine Location für das Kernelimage und die .config Datei gebe ich dir per Mail.

Gruß RolfD

[erisch]

>Das Handbuch zu gcc sagt eindeutig, das -mtune keine
>Codeoptimierungen vornimmt,

sorry, das mtune hab ich wohl großzügig überlesen. Trotzdem wäre eine hypersparc Optimierung sicher angebrachter.

>Anmerkung: Ich habe den debian installer nicht dazu bekommen,
>/boot als separate Partition mit ext2 zu nutzen zumal das Laden der
>initrd trotzdem eine KP verursachte.

Das kannste doch nachher machen. Auf die /boot Partition musste dann nur den Kernel und die System-map ablegen, die Configs für den Boot Manager und dann den Bootmanager in den MBR oder ersten Sektor schreiben.
Leider kenn ich mich mit Silo nicht aus, mit Grub geht das aber ganz einfach (nur gibts den nicht für SPARC), da wird das mit Silo auch möglich sein.

Mfg. Erisch

[RolfD]

Hallo Erisch,

Zu den Optionen in -mtune ...
um noch mal das gcc Handbuch zu bemühen:

"Here is a list of each supported architecture and their supported implementations.

             v7:             cypress
             v8:             supersparc, hypersparc
             sparclite:      f930, f934, sparclite86x
             sparclet:       tsc701
             v9:             ultrasparc, ultrasparc3"

Daher wäre ein -mtune=hypersparc tatsächlich angebrachter. In meinem nächsten gcc Lauf werde ich das berücksichtigen. Ich habe die Info mit "ultrasparc" übrigens aus einem Text von: http://marc.theaimsgroup.com/?l=linux-sparc&m=101919235803803&w=2
Hier wird auch was zur Optimierung von Sparc Code gesagt.

Noch mal zur initrd:
in der Initrd von Debian Sarge wird der ext3 Treiber und der scsi Treiber nachgeladen. Wenn das Laden einer initid wie bei mir zu einer Kernel Panic führt, MUSS zumindest der scsi Treiber im Kernel liegen da sonst der Rest nicht geladen wird. Wenn das FS dann mit ext2 eingerichtet ist, kann der Kernel starten wie du beschrieben hast weil ext2 fest eingebunden ist. Der Zugang für den Kernel ist also doppelt vernagelt weil ext3 UND ESP in meinem Fall (mit ext3 /boot) nachgeladen werden müssen was - mit defektem Ladeverhalten der initrd nun mal nicht zu machen ist und ohne Initrd kommt der Kern nicht an den SCSI Treiber vom Typ ESP.

Zum vorgehen mit Silo.. Silo ist nicht mit Grub oder neueren LILO's zu vergleichen. Silo entspricht bestenfalls den ganz alten Lilo Varianten und hat IMHO ganz massive Probleme mit der Speicherverwaltung vor dem eigentlichen Kernel Init. (IMHO auch der Grund warum die früh geladene Inird vom System wegen falscher MagicNr später nicht akzeptiert wird - vermutlich geht da irgend ein Offset ins Nirwana oder die im original .config mit 16MB sehr groß eingestellte Ramdisk wird nicht korrekt geladen) Vom grundsätzlichen Vorgehen stimmt dein Ansatz jedoch und würde auch gehen wenn der Sarge Installer per default noch mit ext2 arbeiten würde UND der scsi Treiber im Kern enthalten wäre.

Das initrd-Problem wäre recht einfach zu lösen wenn entweder das Laden der initrd mit SMP gehen würde (beste Lösung) - was es aber nicht tut - oder man ext3 und ESP fest im Kernel verankert (mein Kernel), da ext3 durch den Debianinstaller für /boot auch vorgeschlagen wird und durch mich nicht zu ändern war (Installer spuckte Fehlermeldungen aus). Oder in dem der Installer akzeptieren würde, das /boot ein Ext2 ist, was er aber aus mir unerklärlichen Gründen nicht tut und ZUDEM der ESP Treiber im Kern vorhanden ist... was er auch nicht tut.
Ich hab jetzt wirklich alle mir bekannten Optionen aufgezählt

Gruß RolfD

PS:Text noch mal editiert.

[astronom]

Hallo Astronom,
da du 4x 100 Mhz hast (2x2 CPU Boards), wird es dir so nicht gelingen, auf diese Art das System zu installieren da du IMMER min 2 CPUs hast, selbst wenn du ein Bord aus dem System entfernst. Es wird bei dir also immer der SMP Kern installiert, welcher evtl. auch bei dir an der Initrd scheitert.

Ich habe eine möglichkeit gefunden, das zu umgehen!
Wenn man mit der Installation durch ist, bittet der Debian-Installer darum die CD zu entfernen und das system neu zu starten. An dieser stelle sollte man vor dem Reboot an die zweite Konsole wechseln, dort ist eine Shell offen.
Mit "chroot /target" kann man sich in sein installiertes System katapultieren. Wenn man die CD wieder reinschiebt und "mount /cdrom" aufruft kann man weiter von der CD Pakete ins System installieren. "apt-get install kernel-image-2.4.27-2-sparc32" installiert von der CD das non-SMP-Paket. Dabei kommt eine Fehlermeldung das man das Kernelimage installieren möchte, das bereits läuft. Alles getrost ignorieren und durchentern.
Nach dem Reboot hat meine Sun ohne murren den non-SMP-Kernel ausgewählt und damit gebootet. Mein einziges verbleibendes Problem ist jetzt, das die Netzwerkkarte in meiner SS20 wohl kaputt ist :-(

[RolfD]

Hallo Astronom,
du hast damit schon ein riesen Schritt in die richte Richtung gemacht! Das freut mich!

Ich glaube aber nicht mal, das die Netzwerkkarte im Eimer ist. Unter Woody lief sie ja auch bei dir oder? Die Netzwerkkarten werden mit dem 2.4.27er als Modul geladen und evtl. hast du von der Installation des SMP Kernels noch Reste im System.
Der Non-SMP Kernel kann die Module aus dem SMP Kern nicht laden und daher scheitern evtl. die Treiber. Also noch mal den Non-SMP Kern installieren... Oder schau mal mit "dmesg" nach, was das System ausgibt. Auch /var/log/messages wären interessant. evtl. auch mal ein "ldconfig" ausführen und neu booten... (müsste aber eigentlich beim start von debian passieren) Ich halte das Netzkartenproblem also eher für ein Problem der passenden Treiber wobei unter Debian alle mir bekannten SBUS-Module und die interne Netzwerkschnittstelle über nachladbare Module unterstützt werde, daher evtl. auch mal mit "modprobe" Module nachladen probieren.

Meines wissens kannst du im OBP (zu erreichen mit Tasten "Stop-A" ) auch "boot net" statt "boot disk" oder "boot cdrom" angeben so das er vom Netzwerk aus bootet da im OBP ein rudimentärer Treiber für die interne Netzwerkkarte enthalten ist. Damit lässt sich zumindest testen, ob die Schnittstelle Daten verarbeitet, weil dann bootp Pakete von der Sun aus ins Netz gehen müssten.

Wenn das sicher gestellt ist, ist es zu 99,9% ein Treiberproblem und da dann vermutlich ein nicht geladenes Modul.

Ich werde dir am WE mein Kern und meine Config auf einem Webserver stellen, evtl kannst du ihn auf CD brennen und dann installieren. Allerdings musst du dafür zwingend /boot mit ext3 nutzen. Die Netzwerktreiber werden auch bei mir als Modul nachgeladen.

Gruß RolfD

[astronom]

Die Netzwerkkarten werden mit dem 2.4.27er als Modul geladen und evtl. hast du von der Installation des SMP Kernels noch Reste im System.
[...] Meines wissens kannst du im OBP (zu erreichen mit Tasten "Stop-A" ) auch "boot net" statt "boot disk" oder "boot cdrom" angeben so das er vom Netzwerk aus bootet da im OBP ein rudimentärer Treiber für die interne Netzwerkkarte enthalten ist. Damit lässt sich zumindest testen, ob die Schnittstelle Daten verarbeitet, weil dann bootp Pakete von der Sun aus ins Netz gehen müssten.

Ich glaube nicht das es ein Treiberproblem ist - zumindest nicht nur. Ich wollte zwischenzeitlich mal NetBSD 2.0 auf der Sun installieren. Von CD ging wegen ominösen Fehlermeldungen (CD konnte nicht gelesen werden) nicht, also habe ich meinen PC mal wieder zum Netzboot-Rechner für Suns ausgerüstet. Als ich das netbsd-Image mittels "boot net" laden wollte, beschwerte das OBP sich immer darüber, das kein Link vorhanden sei. Und wenn man sich die Link-Lampe am switch mal ansieht - wann immer Daten über das Interface gehen sollen, geht sie aus und das System spuckt Fehlermeldungen.
Wobei mir aber gerade auffällt... auf der anderen SS20 gab es das gleiche problem mit Sarge auch, dort funktioniert das Booten im OBP. Kann das eventuell etwas mit der OBP-Version zu tun haben? Die "andere" SS20 hat ein OBP 2.25, meine hier stehende hat Version 2.19.

Noch etwas:

Code: [Auswählen]

ok test net

Using AUI Ethernet Interface
Internal loopback test -- succeeded.
External loopback test -- Lost Carrier  (transceiver cable problem?)  
send failed.

Using TP Ethernet Interface
Internal loopback test -- succeeded.
External loopback test -- Lost Carrier  (transceiver cable problem?)  
send failed.

net selftest failed. Return code = -1

Ich werde dir am WE mein Kern und meine Config auf einem Webserver stellen, evtl kannst du ihn auf CD brennen und dann installieren. Allerdings musst du dafür zwingend /boot mit ext3 nutzen. Die Netzwerktreiber werden auch bei mir als Modul nachgeladen.

Dank im voraus!

[RolfD]

Also genaues weiss ich zu den OBP Versionen auch nicht aber es lässt sich dazu einiges fachkundiges hier im Forum finden. So weit ich weiss, brauchst du auf Rechnern mit ROSS CPU's auch die OBP 2.25R wobei R für "modifiziert durch Fa. Ross" bedeutet. (wie meine Sun übrigens auch hat) Wende dich mal an Sparcy hier im Forum, ich habe gelesen das er mal jemand ein ROM angeboten hatte zu brennen... falls du das selbst brennen kannst/willst.. du brauchst soweit ich mich erinnere ein EPROM Typ 27040 um es zu brennen. Ich hab wohl noch nen 2.25R Image da... ob es tatsächlich das letzte von 1997 ist, kann ich dir aber nicht sagen. Jedenfalls laufen meine CPUs damit. Das Ding mit dem roten Schild auf deinem Photo (anderer Thread) ist das NVRam....(realtimeclock und buffered RAM, der "Chip" ist wesentlich "dicker" als das Eprom) Ich sah das du an anderer Stelle mal gefragt hattest. Das NVRam solltest du nicht entfernen.. das EPROM liegt aber direkt daneben. Schau da aber besser noch mal in die Handbücher zum Mainboard bei Sun. Em.. hast du mal das Netzwerkkabel zur Sun geprüft? Nicht das da ein banaler Kabelbruch vorliegt oder du nen Crossover erwischt hast... alles schon erlebt... besser alles 2 mal checken

PS: Ach ja.. es gibt wohl zumindest für die SS10 ein externen BNC-Transreciver zum aufstecken auf die kleinen Microstecker hinten am Gehäuse.. solltest du so einen aufgesteckt haben, kann es sein das der TP-Port nicht geht. Bei Versuchen mit TP also den Transreciver abstecken. Mit normal gestecktem TP-Patchkabel und verbindung zum Hub/Switch sollte der OBP-Recivertest positiv verlaufen.

Gruß RolfD

[Sparky]

OK.
Mein Spezialgebiet SS10/20 mit Ross-CPU´s.
Man benötigt für den Einwandfreien Betrieb mit Ross CPU´s
bis 125MHz ein SUN OBP der Version 2.22
Für 150MHz sollte es ein SUN 2.25 sein,
darüber dann nur noch mit dem von Ross modifiziertem 2.25er.
Das Ross 2.25R gibt es in Verschiedenen Versionen !!
Diese erkennt man nur am Datum.
Die letzte - und wohl am meisten verbreitete Version - ist am Datum 14-03-97 zu erkennen.
Ich selbst habe fünf verschiedene Versionen,
die älteste trägt das Datum 15-09-95.
Zwei Versionen waren nur für die Hyperstation 20/30 und SparcPlug von Bedeutung,
denn dort kann man den MBus-Takt frei einstellen.
Meine HS30 läuft mit 200MHz CPU´s bei einem MBus-Takt von 70MHz.
Das ist bei einer SS290 nicht möglich, weil Ross einen eigenen
Chipsatz gebacken hat.
Weiters kann man die Latenzzeit für den Speicher einstellen.
Dank spezieller Speichermodule mit 128MB für die HS20/30
verfügen meine Maschinen über 1024MB RAM.
Einziger Wehrmutstropfen, diese sind mit Solaris nicht nutzbar -
dafür aber mit OpenBSD/NetBSD.
Ich ringe immer noch mit mir, ob ich irgendwann bei Cyberfinity
zuschlage und zwei Single-Slot 200MHz Dual-CPU´s kaufe.
Nur für das Geld bekommt man schon eine Blade 100.....

[astronom]

Wende dich mal an Sparcy hier im Forum, ich habe gelesen das er mal jemand ein ROM angeboten hatte zu brennen... [...] Das NVRam solltest du nicht entfernen.. das EPROM liegt aber direkt daneben. [...] Em.. hast du mal das Netzwerkkabel zur Sun geprüft? Nicht das da ein banaler Kabelbruch vorliegt oder du nen Crossover erwischt hast... alles schon erlebt... besser alles 2 mal checken

PS: Ach ja.. es gibt wohl zumindest für die SS10 ein externen BNC-Transreciver zum aufstecken auf die kleinen Microstecker hinten am Gehäuse.. solltest du so einen aufgesteckt haben, kann es sein das der TP-Port nicht geht. Bei Versuchen mit TP also den Transreciver abstecken. Mit normal gestecktem TP-Patchkabel und verbindung zum Hub/Switch sollte der OBP-Recivertest positiv verlaufen.

Ich glaube von Sparky habe ich damals schon das OBP 2.25 für meine andere Sun (2x125MHz) bekommen. Die die hier steht (4x100MHz) habe ich mit diesem OBP ausgemustert bei einer Firma bekommen, daher glaube ich nicht das ich zwingend eine neuere OBP-Version brauche um die CPU's zu betreiben. Einen externen Transciever für BNC habe ich allerdings, im normalfall liegt der allerdings im Schrank. Ich habe den gestern testweise mal angesteckt - "test net" ergab bei AUI un external Transciever eine Zeitüberschreitung. Ich fand' das erstmal sehr positiv und werde mir mal Equipment ausleihen, mit dem ich mein Twisted-Pair-Netz mit einem BNC-Netz verbinden kann und schauen, ob ich dann mehr glück habe.