Betriebssysteme > Linux

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

<< < (5/6) > >>

Sparky:

--- Zitat ---->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?

--- Ende Zitat ---

- 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

RolfD:
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

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

astronom:
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?

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:
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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete