Betriebssysteme > Linux

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

<< < (6/6)

astronom:

--- Zitat von: RolfD am 10. August 2005, 20:08:36 ---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)

--- Ende Zitat ---

Du brauchst mir nicht alles Haarklein erklären, ich bin schon seit einigen Jahren Linuxer und betrachte mich inzwischen als recht fit 8)


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

Heute schon zweimal gemacht - beim zweiten mal (interessanterweise mit der gleichen config wie beim ersten mal) lief der Kernel kann.



--- Zitat ---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)?
--- Ende Zitat ---
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.

RolfD:
Hallo Astronom,

--- Zitat von: astronom am 10. August 2005, 20:46:20 ---Du brauchst mir nicht alles Haarklein erklären, ich bin schon seit einigen Jahren Linuxer und betrachte mich inzwischen als recht fit 8)

--- Ende Zitat ---

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.
 

--- Zitat von: astronom am 10. August 2005, 20:46:20 ---Heute schon zweimal gemacht - beim zweiten mal (interessanterweise mit der gleichen config wie beim ersten mal) lief der Kernel kann.

--- Ende Zitat ---

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


--- Zitat von: astronom am 10. August 2005, 20:46:20 ---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.

--- Ende Zitat ---

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

Navigation

[0] Themen-Index

[*] Vorherige Sete