[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SMP -> kernel panic



High, high ...
* Charles Imbusch <CImbusch@gmx.net> schrieb am [07.09.03 22:48]:
> Hallo,
> 
> ich versuche gerade einer Linux Maschine beizubringen den zweiten
> Prozessor zu benutzen. Dafür hab ich mir zuerst den Kernel 2.4.18
> einfach mal neu gebacken. Booten war kein Problem, es erschien zweimal
> der Tux und in /proc/cpuinfo wurde der zweite Prozessor mit aufgelistet.
> 
> Einziges, aber recht großes Problem war danach folgendes:
> 
> Wenn sich z.B. ein user an der Domäne anmeldete und das Profil auf den
> client übertragen wurde schmierte der linux server ab. Ich spekulier
> damit, dass der erhöhte Netzwerktraffic Probleme machen könnte.
>

Das betrifft dann denn samba server, richtig? Hast du auch mit anderen
Aufgaben Probleme?
Ich würde auch noch mal einen SMP-Kernel unter dem laufenden SMP-Kernel
übersetzen, mit allen Modulen. Vor langer Zeit hatte ich z.B. mal das
Problem, das mein Dual-PentiumPro bei fertigen SMP-Kernel immer trappte.
"Schuld" war das 3c509 Modul für die Netzkarte. Erst bei einer
Neu-Kompilierung von Kernel und Modulen war Ruhe.

Ich würde mal das samba-Paket unter dem laufenden SMP-Kernel neu
kompilieren, v.a. mit der richtigen Prozessorklasse. Wäre einen Versuch
wert, wenn, s.o., "nur" dieser Fehler auftritt. Beim Kompilieren kann
ich mich erinnern (ist schon etwas her) das bei SMP nach ./configure
beim Kompiler-Lauf auch ein extra SMP-Schalter gesetzt war.

Welche CPUs verwendest du denn?
Evtl. ist es auch die Netzwerk-Karte. Ich denke, grad die Billigteile
können Probleme mit der Interrupt-Verteilung auf zwei CPUs haben.

Ansonsten vielleicht mal Streßtest. Es gibt Tools explizit für den
Netzwerk-Streß. Für CPUs/MB/HD bietet sich ein Kernel-Lauf an.
Z.B. Kernel-sourcen auspacken und ein
	make -j 2 bzImage
verwendet beide CPUs zum compilieren, ein
	make -j 99 bzImage
startet 99 einzelne makes und gccs

> Fehlermeldung war folgende:
> 
> Unable to handle Kernel NULL pointer dereference at virtual address...
> 
> [ viele nette Zahlen ]
> 
> Kernel panic: Aiee, killing interrupt handler!
> In interrupt handler - not syncing.

Ich würde mal mal meinen Kernel mit MagicSysRequest bauen,
Kernel debugging->Magic SysRq keys
Die Ausgaben, die du damit nach einer panic kriegst, weisen oftmals in
die richtige Richtung.

> Grüsse,
> 		Charlie

Gruß
	Gerhard



Reply to: