Betriebssysteme > Linux

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

<< < (2/6) > >>

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:


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

--- Ende Zitat ---


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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete