sonnenblen.de - Das unabhängige Sun User Forum
Betriebssysteme => Linux => Thema gestartet von: RolfD am 05. August 2005, 00:38:01
-
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/"
-
-> 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.
-
->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
-
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
-
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
-
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.
-
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
-
>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
-
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.
-
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 :-(
-
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
-
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:
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!
-
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
-
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.....
-
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.
-
Noch etwas:
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
Ganz doofe Frage: Hattest Du ein Kabel angesteckt?
Bezüglich AUI bzw TP, gibt es da nicht einen OBP Eintrag, der regelt, welches von beiden benutzt wird?
Ich hab leider meine Command Reference nicht da und die SS20 steht auch woanders im Augenblick :)
Übrigens hab ich noch einen AUI-TP Converter hier herumliegen, falls Du ihn brauchen solltest, kann ich dir das Ding gerne zukommen lassen gegen Porto (2€ oder so sollte das kosten).
Angenehmes Wochenende,
Claus
-
So.. ich habe mein Kernel hochgeladen und stelle ihn damit zu Testzwecken zur Verfügung
Sollte ich Probleme mit dem Downloadvolumen bei Arcor kriegen, nehme ich den Kern wieder vom Netz.
Zum Kernel selbst:
Der Kern mit Version 2.4.27 ist ein normaler Debian Kernel mit modifizierten Optionen "make menuconfig".
Er läuft nur mit V8 Prozessoren!
Er lädt keine initrd!
Er hat kein ext2 Filesystem enthalten!
Er muss eine ext3 /boot und eine ext3 / (root) partition vorfinden!
Er kann ext2 als Modul nach dem booten nachladen!
Er ist als SMP Kern mit max 4 CPU'S compiliert, ob er auf einem UP System läuft, weiss ich nicht.
Es sind einige Optionen abgeschaltet, die evtl. doch gewünscht sind... es steht jedem frei, den Kern selbst neu zu bauen und die von mir abgeschalteten Optionen wieder einzuschalten, es ist jedoch auf die Kernelgrösse von max. 2,6MB "ungezipt" zu achten.
Der Kern ist ein reiner Test- u. Versuchskernel und nicht für produktive Umgebungen gedacht.
Die Nutzung erfolgt auf eigene Gefahr und sollte nicht ohne Hintergrundinformation erfolgen.
Für Schäden aus der Nutzung dieses Kernels muss ich also jede Verantwortung ablehnen.
Der Link zum Config File: http://home.arcor.de/rolf.diesing/sun/config
(Bitte daran denken, das File in .config umzubenennen wenn es 1:1 in den sourcetree eingefügt werden soll.
Das File ist leider etwas gross um es hier komplett zu posten, solche Datenwüsten wären in einem Forum als Text auch unpassend)
Der Link zum Kernel: http://home.arcor.de/rolf.diesing/sun/kernel-image-2.4.27-sparc32_V8.smp_sparc.deb
(Dies ist ein normales deb, ggf. im silo vorher eine Alternativconfig anlegen um den alten UP-Kernel noch booten zu können.)
Ich bin für Vorschläge und Verbesserungen am config File immer dankbar da ich mich selbst erst langsam an die Problematik rantaste.
@Sparky
Danke für diese Infos!
Ich hab da aber noch ne Frage: Ich habe bei mir im Banner (2.25R) der Sun gesehen, das dort "Hypersparc" steht. Ist das ein Hinweis auf ein OBP einer HS20/30? ich habe mal im OBP nach den Optionen für die Speichereinstellungen gesucht aber nichts gefunden. Oder sind alle Rechner mit Ross CPUs sozusagen "Hypersparc"? Mein ROM Image habe ich mal irgendwann im Web/FTP gefunden und kann leider nichts mehr zum Filedatum sagen. Gibts eine Möglichkeit das ROM genauer zu identifizieren?
Zu meinem Versuch, alle Pakete mit apt-build nachzubauen und entsprechend auf v8 zu optimieren.. es scheint da diverse Probleme zu geben, ich empfehle daher derzeit, dies noch nicht zu machen. Ganz konkret z.B. lässt sich der dhcp-client zwar compilieren, ist aber dann nicht mehr in der Lage, IP adressen zuzuweisen. Da man sich sein Rechner mit sowas vom Netz abhängen kann, ist da Vorsicht geboten. (ich habe mir dann provisorisch z.B. mit einer statischen IP geholfen, der Rechner muss jedoch später dhcp auf min. 1 eth machen können). Wo da genau die Probleme liegen, versuche ich noch rauszubekommen. Perl habe ich bisher noch nicht compilieren können, das bricht mit Fehler ab. Jedoch scheint es sich doch zu lohnen, mit Ross CPUs zumindest einige Pakete zu optimieren - vor allem da wo viel gerechnet wird, merkt man doch deutliche Unterschiede.
Gruß RolfD
-
Ich hab da aber noch ne Frage: Ich habe bei mir im Banner (2.25R) der Sun gesehen, das dort "Hypersparc" steht. Ist das ein Hinweis auf ein OBP einer HS20/30? ich habe mal im OBP nach den Optionen für die Speichereinstellungen gesucht aber nichts gefunden. Oder sind alle Rechner mit Ross CPUs sozusagen "Hypersparc"? Mein ROM Image habe ich mal irgendwann im Web/FTP gefunden und kann leider nichts mehr zum Filedatum sagen. Gibts eine Möglichkeit das ROM genauer zu identifizieren?
Im OK Prompt:
.Version
-
So.. ich habe mein Kernel hochgeladen und stelle ihn damit zu Testzwecken zur Verfügung
Sollte ich Probleme mit dem Downloadvolumen bei Arcor kriegen, nehme ich den Kern wieder vom Netz.
Zum Kernel selbst:
Der Kern mit Version 2.4.27 ist ein normaler Debian Kernel mit modifizierten Optionen "make menuconfig".
Er läuft nur mit V8 Prozessoren! [...]
Der Link zum Kernel: http://home.arcor.de/rolf.diesing/sun/kernel-image-2.4.27-sparc32_V8.smp_sparc.deb
(Dies ist ein normales deb, ggf. im silo vorher eine Alternativconfig anlegen um den alten UP-Kernel noch booten zu können.)
Getestet an meiner Funktionierenden SS20 mit 2x125MHz Ross - Bootet nicht. Der Debian-Uniprozessorkernel von der Installations-CD läuft.
Das erste booten des neuen Kernels endete mit einem kompletten System-freeze, ich bin nichtmal mehr an das OK-Prompt gekommen. Alle weiteren enden in einem "Watchdog reset" & Rücksetzen ans OK-Prompt sofort nach dem start von init.
Der nächste schritt wäre wohl selber einen Kernel zu basteln - aber nimmer heute. Gibt es noch irgend welche anderen vorschläge, was man versuchen könnte?
-
@Sparky
Hallo Sparky ich habe mit .Version folgende Ausgabe:
->Release 2.25R hyperSPARC Version 1 created 97/01/28 15:20:13
Ist diese Version für eine 'normale' SS20 mit 2 mal HM142S-1024 Modulen überhaupt geeignet?
Und kann ich aus dem Rechner evtl. noch etwas Leistung rauskitzeln und wenn ja, wie?
Die R-Versionen haben anscheinend auch einige Befehle mehr als das "normale" OBP, gibts dazu irgendwo im Netz eine erweiterte Befehlsreferenz?
@All
Zu meinem 2.4.31 Kernel von Kernel.org:
Ich habe heute mein zuletzt gebauten Kern nun aktiviert und alles ist glatt verlaufen.
Der Rechner bootet und startet fehlerfrei komplett durch.
@astronom
Die Probleme, das nach dem Booten der init Prozess starb und der Rechner hing, hatte ich mit frühen 2.4er Kernel Versuchen auch.
Allerdings meinte ich das Problem in einer falsch eingerichteten "system.map" gefunden zu haben da Silo die zum Kernel gehörende "system.map" zum laden des Kerns braucht bzw. da etwas Mittels einem Codestück "btfixup.c" anpasst. Wenn die System.map nicht dem aktuellen Kernel entspricht, konnte ich solche Fehler wie init-Absturz reproduzieren. Da tappe ich aber recht massiv im Dunkelen... und lasse mich gern auch verbessern. Sonst wüsste ich nicht, warum der Debain-Kern 2.4.27-2 so Probleme macht.. wie gesagt hier läuft er einwandfrei. Man kann mit LILO über den Kernel Boot Parameter "init=/bin/bash" übrigens auch ein anderes Programm als "Init" starten was an der Konsole gern zum reset von rootpw genutzt wird. Das entspricht grob gesagt einem Kernelstart im single Modus. Der Silo müsste sowas auch kennen. Damit kannst du evtl. die geladenen Module und Devices kontrollieren (wenn silo das so überhaupt kann).
Den Kern also selbst zu bauen (evtl. mit meinem config file) scheint mir die beste Lösung zu sein. Wie man debian-Kernel erstellt ist gut dokumentiert. Die Kernel von Kernel.org lassen sich so ähnlich bauen. Ich vermute aber, das Prozedere kennst du auch.
Würd mich freuen wenn wir die Rechner mal "gegeneinander antreten lassen können" wenn du soweit bist. Ist bestimmt auch für die Com interessant, eine Dual CPU SS20 142Mhz 1mb cache gegen eine Quad SS20 100Mhz 256 kb cache laufen zu sehen...
Mich würden auch Ergebnisse anderer Betriebssysteme und Konstellationen im Bereich SS20 interessieren.
@All
Nach dem mein 2.4.31 Kern nun läuft, überlege ich noch, den Security Patch von http://www.grsecurity.net/ anzuwenden.
Gibt es damit hier Erfahrung im Forum bezüglich SMP? Angeblich soll der Patch SMP tauglich sein... hat das mal jemand (evtl auch auf sparc64) probiert? Welche Erfahrungen gibt es also zu dem Patch auf Sparc?
Gruß RolfD
-
->Release 2.25R hyperSPARC Version 1 created 97/01/28 15:20:13
Ist diese Version für eine 'normale' SS20 mit 2 mal HM142S-1024 Modulen überhaupt geeignet?
Und kann ich aus dem Rechner evtl. noch etwas Leistung rauskitzeln und wenn ja, wie?
Die R-Versionen haben anscheinend auch einige Befehle mehr als das "normale" OBP, gibts dazu irgendwo im Netz eine erweiterte Befehlsreferenz?
- Offensichtlich ist diese Version geeignet, sonst würde deine SS20 damit nicht booten
- Mehr Leistung gibts nur mit schnelleren CPU´s oder einer waschechten Ross HyperSTATION
- Es gibt nirgends eine Befehlreferenz - da sollte ich vielleicht für meine Homepage mit aufnehmen
-
Zum Patch von grsecurity.net auf vanilla Kernel 2.4.31 als SMP,
der Patch lässt sich erwartungsgemäß problemlos einspielen und die Compilation läuft durch.
Die Optionen von grsecurity lassen sich Mittels 'make menuconfig' einstellen.
Es gibt Low,Medium,High,Custom. Ich hatte dort die Stufe 'Medium' genommen und den gcc lauf angeworfen.
Der Kern ist jedoch nicht startbar.
Beim Laden des Kerns (noch auf der Silo Ausgabe und vor dem Umschalten in den normalen ->(weisse Schrift auf schwarzem Hintergrund) Videomode blinkt die Grafik kurz auf.. als wenn ein CPU/Grafikkarten/Rechner Reset ausgeführt wird und der Rechner bleibt dann mit Int 15 bzw. Watchdog Meldung stehen. Da der Patch sehr tief in die Systeminterna der Prozessverwaltung eingreift, scheint es also dort auch zu Problemen zu kommen. Es dürfte sich IMHO also um ein (Speicher)Initialisierungs-/Ladefehler von Silo und/oder (in der Folge) um ein sehr frühes "Sterben" des eigentlichen Kernelprozesses handeln. Jedenfalls ist der Kern nach dem Reset nicht mehr in der Lage, irgendwas gescheites in der "grsecurity"-Einstellung "medium" anzustellen. Der Patch sollte aber angeblich auf arch Sparc laufen. Evtl. geht er auf UP und das Problem liegt im SMP code... da scheinen sowieso noch "einige" Baustellen zu liegen.
Ich teste das ganze nun mit SMP und in Einstellung "Low"als default und mit aktivem "random tcp source port" als Custom Option und bin auf den nächsten gcc Lauf gespannt. Ich benutze inzwischen auch das "-mcpu=hypersparc -mtune=hypersparc" als Ersatz für "-mv8 -mtune=v9" da dies den für meine CPUs bestangepassten Code ergeben müsste.
Gruß RolfD
-
@all
Der Patch von grsecurity.net funktioniert auch in der "Low" unter den beschriebenen Voraussetzungen und Einstellung nicht.
Da ich nicht vor hatte, Kernelprogger zu werden, muss ich mich wohl mit dem 2.4.31er smp Kern erst mal begnügen.
Gruß Karboom
-
Hallo RolfD,
dein 2.4.27-Kernel läuft auf meiner daheimstehenden Sun (4x100MHz, 512MB Ram) blendend - seit ich BNC-Netzwerkequipment habe kann ich mit dem AUI-BNC-Transciever auch wieder ins Netzwerk.
Allerdings wüsste ich noch gerne, welche änderungen du an dem Kernel gegenüber dem Vanilla-Kernel vorgenommen hast und mit welchen Extra-Compiler-Optionen du den Kern gebaut hast. Ich habe versucht mir einen 2.4.31 zu backen, der bootet aber leider nicht. Er bleibt bei einer Fehlermeldung (die ich schon wieder vergessen habe) stehen und das ganze System mit ihm - kein OBP mehr. Den habe ich mit -mcpu=hypersparc -mtune=hypersparc gebaut.
Muss man eigentlich wie in einem deiner ersten Postings erwähnt wirklich den Makefile ändern um diese Optionen zu den CFLAGS hinzuzufügen oder reicht da nicht ein "export CFLAGS="$CFLAGS -mcpu=hypersparc -mtune=hypersparc" vor dem starten des Compile?
-
Hallo Astronom,
es freut mich sehr, das der von mir gebaute Kern bei deiner 4x100er läuft.
Es gibt nichts schlimmeres wie wenn man "nicht reprduzierbare Ergebnisse" hat.. von da her ist dies ein wichtiger Schritt.
Zur Kernel config:
Ich hatte neben dem Kernel auch die Config auf dem Webspace abgelegt, mit der ich den Kernel erzeugt habe.
Es handelt sich wie gesagt um den 2.4.27-2 aus original Debian Qellen.
Du kannst mit "diff" meine und deine Config vergleichen und/oder meine Config in dein Kernelsourceverzeichnis als ".config" kopieren um dann mit "make menukonfig" die für dich sinnvollen Änderungen machen. (backup nicht vergessen)
Die Änderungen bezüglich der CFLAGS muss man wohl in /usr/src/Kernelsource+Version/arch/sparc/Makefile machen.
Ich hatte auch versucht, dies mit CFLAGS als shell Variable zu machen aber diese wird scheinbar von den scripten nicht berücksichtig bzw. das mit dem Var Export hat bei mir nicht so geklappt wie es gedacht war. Ändern des Makefile hilft aber zuverlässig.
Bei mir sieht das dann so aus:
CFLAGS := $(CFLAGS) -mcpu=hypersparc -mtune=hypersparc -O2 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
Zum 2.4.31 Kern:
Ich habe wie bereits beschrieben das .config File aus der 2.4.27-2 genommen und es in den Source Tree für den 2.4.31 kopiert, dort dann mit "make menuconfig" weitere kleinere Einstellungen vorgenommen (im Bereich NetFilter) und ebenfalls dort in arch/sparc/Makefile die Optionen geändert. Dieser Kern läuft bei mir nun seid einigen Tagen stabil. Du hast damit alles an Infos, die du brachst um den Kern nachzubauen.
Mir ist noch nicht ganz klar, warum der von mir gebaute Kern nicht auf deinem 2x125 Rechner läuft. Eigentlich kann dies nur ein Problem am Filesystem sein. Hängen deine Platten an dem interen ESP SCSI oder bootest du von einer externen Platte UND einem 2.ten SCSI Kontroller (Qlogic)? Wenn ja, musst du den QLogic Treiber natürlich aktivieren, der bei mir nur als Modul nachgeladen werden kann. Auch "von einem Array booten" müsste mit meinem Kern fehlschlagen da die Module dazu nachgeladen werden. Mein Kern ist nur zum booten von einer internen Platte am Bordeigenen ESP mit ext3 /boot bzw. / ausgelegt. Mein /boot liegt dabei in der / und nicht als eigene Partition vor so das also auch /lib mit den Modulen erreicht werden kann wenn / gemountet wird. Poste doch mal bitte dazu Deine komplette /etc/fstab. Auch eine etwas genauere Fehlerbeschreibung würde mir ggf. schon helfen. :) Versuch evtl. auch mal die Platte aus dem 4x100 Rechner in dem Rechner mit 2x125 laufen zu lassen... wenn die Hardware ok ist, müsste der 2x125er ja mit der Platte aus dem Stand hochkommen.
Für Leute die ext2 UND ext3 im Kern brauchen, wäre übrigens evtl. interessant, das NCP Netzwerk File System (Novell Shares) und das XFS Filesystem sowie das IPv6 abzuschalten... es gibt schon noch einige Möglichkeiten, den Kern kleiner zu kriegen.... Grundsätzlich gilt: der Kern sollte wirklich nur nützliches enthalten... und den Rest in Module packen und/oder ganz abschalten.
Ich muss wirklich sagen.... Debian auf Sparc32 ist inzwischen eine gute Wahl... aber nix für Linux Anfänger und Leute ohne Geduld :) Aber solche Leute wären mit ner SS20 sowieso nicht glücklich zu machen... egal welches Sys da werkelt.
Mich würde nun brennend interessieren, warum der grsecurity patch so übel daneben geht... denn in der Antwort dieser Frage liegt IMHO auch ein grosser Teil der Probleme, warum z.B. die 2.6er Kerne auf Sparc32-smp nicht gehen und SMP auf Sparc32 wohl grundsätzlich nicht unproblematisch scheint.
Gruß RolfD
-
Hallo Astronom,
es freut mich sehr, das der von mir gebaute Kern bei deiner 4x100er läuft.
Es gibt nichts schlimmeres wie wenn man "nicht reprduzierbare Ergebnisse" hat.. von da her ist dies ein wichtiger Schritt.
Zur Kernel config:
(Keine weiteren änderungen)
Du brauchst mir nicht alles Haarklein erklären, ich bin schon seit einigen Jahren Linuxer und betrachte mich inzwischen als recht fit 8)
Zum 2.4.31 Kern:
Ich habe wie bereits beschrieben das .config File aus der 2.4.27-2 genommen und es in den Source Tree für den 2.4.31 kopiert, dort dann mit "make menuconfig" weitere kleinere Einstellungen vorgenommen (im Bereich NetFilter) und ebenfalls dort in arch/sparc/Makefile die Optionen geändert. Dieser Kern läuft bei mir nun seid einigen Tagen stabil. Du hast damit alles an Infos, die du brachst um den Kern nachzubauen.
Heute schon zweimal gemacht - beim zweiten mal (interessanterweise mit der gleichen config wie beim ersten mal) lief der Kernel kann.
Mir ist noch nicht ganz klar, warum der von mir gebaute Kern nicht auf deinem 2x125 Rechner läuft. Eigentlich kann dies nur ein Problem am Filesystem sein. Hängen deine Platten an dem interen ESP SCSI oder bootest du von einer externen Platte UND einem 2.ten SCSI Kontroller (Qlogic)?
Die 125er-Sun hat nur den internen Controller. Meine hiesige hat _glaube_ ich zwei Controller. Allerdings habe ich die Karte bisher auch nicht weiter identifiziert - die steckt einfach noch drin damit sie aufgeräumt ist.
Die Platte in der 125er hat nur zwei Partitionen - /dev/sda1 (root, 1,6 GB, ext3) und /dev/sda2 (swap, 360 MB). Aber der Kernel wurde ja nicht mal richtig gebootet. Wenn ich wieder an der Sun sitze (frühestens am Wochenende) kann ich genaueres abtippen.
-
Hallo Astronom,
Du brauchst mir nicht alles Haarklein erklären, ich bin schon seit einigen Jahren Linuxer und betrachte mich inzwischen als recht fit 8)
Nun ich erkläre es deshalb so genau um Missverständnisse zu vermeiden, und um Leuten diesen Weg zu ermöglichen, die nicht Meine oder Deine Erfahrung haben. Ausserdem ist das Thema sparc32 und SMP auf Debian (auch weil Redhat/SUsE und andere {z.B. der Sparc Kernel Programmierer Dave Miller} ihre Bemühungen zur arch sparc32 offiziell eingestellt haben - nicht zuletzt wegen angeblich kaum zu lösender Probleme mit dem Arch Code ) ein sehr wichtiges Thema. Auch die Menge an Klicks für den Thread zeigen, das hier grosses Interesse besteht!
Nimm das also bitte nicht persönlich auf dich bezogen.
Heute schon zweimal gemacht - beim zweiten mal (interessanterweise mit der gleichen config wie beim ersten mal) lief der Kernel kann.
Mir ist schon einige Male aufgefallen, das es Unterschiede zwischen einem Kaltstart, einem Reset mittels OBP-Befehl und einem Stop-a/Resume gibt. Dies ist evtl. auf das OBP zurück zu führen bzw. ein weiteres Problem von SILO. Dementsprechend startet manchmal der Kernel auch bei mir nicht und bleibt einfach hängen. Ein Kaltstart bringt das System jedoch meist fehelrfrei hoch und ein "reboot" in der shell ist - so weit ich mich erinnere - auch noch nicht hängen geblieben. Gibt man am Siloprompt jedoch Befehle ein, kann der anschliessende Start dann hängen bleiben. Wie gesagt, IMHO ein SILO Problem da SILO immer gestartet wird, jedoch der Kern manchmal hängt (weil er nicht richtig initialisiert wird).
Die 125er-Sun hat nur den internen Controller. Meine hiesige hat _glaube_ ich zwei Controller. Allerdings habe ich die Karte bisher auch nicht weiter identifiziert - die steckt einfach noch drin damit sie aufgeräumt ist.
Die Platte in der 125er hat nur zwei Partitionen - /dev/sda1 (root, 1,6 GB, ext3) und /dev/sda2 (swap, 360 MB). Aber der Kernel wurde ja nicht mal richtig gebootet. Wenn ich wieder an der Sun sitze (frühestens am Wochenende) kann ich genaueres abtippen.
Die / auf /dev/sda1 sollte nicht grösser als 1 GB sein. Dazu gibts hier im Forum ebenfalls massenweise Hinweise. Ich sagte auch schon mal das SILO im Prinzip ein sehr alter LILO ist... bei dem es das gleiche Problem auch in i386 gab. Eine 2Gb Platte ist für ein Linux eh etwas sehr schwachbrüstig. Das nur als Tip zur Partition. Der "nichtidentifizierte Controller" ist anhand seiner Part Nr. sehr leicht zu identifizieren. Schau mal bei http://sunstuff.org/ vorbei. Wegen Platten... da gibts noch nen ganz gemeinen Fallstrick:
Die Sun bootet von der Platte auf der SCSI ID 3. Die wird in Linux auch richtig als /dev/sda erkannt. Baut man nun eine Platte hinzu, läuft diese meist als SCSI ID 1 (im OBP kontrollieren!). Die Sun bootet weiterhin von der ID 3. Das habe ich soweit aus diversen Sun Docu's und das lässt sich im OBP auch umstellen. Bootet das Linux System aber nun von ID 3, werden auch wieder die Patten erkannt.. und weil dabei ID 1 vor ID3 kommt, wird nun die Platte auf ID 1 zur /dev/sda und die Platte mit ID 3 dann /dev/sdb! Als Folge stimmen nun z.B. die nicht ganz unbedeutenden Einträge in der /etc/fstab und/oder silo.conf zum root fs nicht und der Bootvorgang MUSS fehlschlagen. Wer sich eine Platte zusätzlich ins Sysem hängen will, sollte sich also VORHER Gedanken zu dem Problem machen! Um dies Problem zu umgehen habe ich mein Sys von Anfang an mit 2 Platten installiert und boote daher von ID3 alias /dev/sdb1. Mit einer weiteren Platte würden aber wieder Probleme auftauchen weil die bootplatte dann z.B. /dev/sdc1 ist. Ohne Probleme lassen sich nur Platten auf ID 4,5 und 6 nachrüsten (ID 6 ist evtl. für ein vorhandenen Streamer vorbehalten). Andere Systeme (NetBSD?) benutzen teilweise die Devicedescriptoren wie bei Sun üblich... (so 'komische' devicenamen die sich kein Mensch merken kann :) , auch im OBP zu finden) so das diese das Problem weiträumig umgehen... eigentlich ist dies aber auch unter Linux mit den /dev/sdxX Namen kein Problem wenn man das Gesagte berücksichtigt.
Gruß RolfD