Betriebssysteme > Linux

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

(1/6) > >>

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

Navigation

[0] Themen-Index

[#] Nächste Seite