Re: SMP -> kernel panic
On Mon, Sep 08, 2003 at 10:47:34AM +0200, Gerhard Brauer wrote:
> Das betrifft dann denn samba server, richtig?
Yep.
> Hast du auch mit anderen Aufgaben Probleme?
Im "normalen" Betrieb bleibt die Kiste nur durch samba hängen. Im
"unnormalen" Betrieb, also wenn ich z.B. nmap benutze passierts aber
*manchmal* auch. Es ist also nicht wirklich reproduzierbar außer mit
samba.
> 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.
Das ist eine Idee, der ich mal nachgehen werde.
> 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.
Ist auch nen Versuch wert. Aber kann es denn wirklich sein, dass ein
Programm, das nur für eine cpu compiliert wurde, das ganze OS zum
Stillstand bringen kann?
Der Fehler tritt nicht "nur" bei Samba auf, z.B. wie oben erwähnt auch
teilweise mit nmap, was du vorher natürlich nicht wußtest.
> Welche CPUs verwendest du denn?
Kurzer Auszug aus /proc/cpuinfo:
model name : Pentium III (Coppermine)
stepping : 6
cpu MHz : 906.352
cache size : 256 KB
> Evtl. ist es auch die Netzwerk-Karte. Ich denke, grad die Billigteile
> können Probleme mit der Interrupt-Verteilung auf zwei CPUs haben.
/proc/pci sagt mir dass es eine
MYSON Technology Inc SURECOM EP-320X-S 100/10M Ethernet PCI Adapter
(rev0) ist. Ist das ein Billigteil?
> 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
Ohja, da wird die Machine ins Schwitzen kommen.
> > 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.
Auch das ist ne Idee, der ich mal nachgehen werde.
Danke schonmal
Grüsse,
Charlie
--
ICQ: 15899282 Tel.: 02641/204387 Mobil Tel.: 0162/9412753
Reply to: