Re: SMP - kernel panic
On Tue, Sep 09, 2003 at 04:53:08PM +0200, Adrian Zaugg wrote: 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 Problem könnte tatsächlich am Netzwerkkartentreiber liegen. Die Treiber müssen nämlich ebenfalls für SMP kompiliert sein, da sonst Spinlocks auftreten können Jo, das war das Problem. Unter dem SMP System einfach nochmal den SMP Kernel und die Module kompiliert und dann liefs ohne Probleme. Eigentlich meine ich, dass die Debian Standard-SMP Kernel, das richtig machen müssten. Hast Du den Standardkernel kernel-image-2.4.18-686-smp ausprobiert? Geht es da auch schief? Kann ich nicht sagen, der Kernel scheint keine SCSI Unterstützung zu haben. Also konnte ich damit gar nicht erfolgreich booten. Trotzdem, so läufts ja, danke nochmal! Gruß Charlie -- ICQ: 15899282 Tel.: 02641/204387 Mobil Tel.: 0162/9412753 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: SMP - kernel panic
On Tue, Sep 09, 2003 at 04:53:08PM +0200, Adrian Zaugg wrote: Das Problem könnte tatsächlich am Netzwerkkartentreiber liegen. Die Treiber müssen nämlich ebenfalls für SMP kompiliert sein, da sonst Spinlocks auftreten können Werden die Treiber denn nicht automatisch für SMP kompiliert, wenn ich für den Kernel die SMP Unterstützung akktiviert habe? Es kam ja schonmal der Hinweis, einen SMP-Kernel und die Module unter einem SMP-Kernel nochmal zu kompilieren. Das konnte ich bisher leider noch nicht testen. Habe erst am WE wieder die Gelegenheit an der Kiste was zu experementieren. Eigentlich meine ich, dass die Debian Standard-SMP Kernel, das richtig machen müssten. Hast Du den Standardkernel kernel-image-2.4.18-686-smp ausprobiert? Geht es da auch schief? Ich habe dafür einen neuen Kernel gebacken. Hatte ich wohl übersehen, dass es schon fertige smp Kernel gibt. Wie auch immer, der Idee geh ich mal als erstes nach. Gruß Charlie -- ICQ: 15899282 Tel.: 02641/204387 Mobil Tel.: 0162/9412753 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: SMP - kernel panic
On Tue, Sep 09, 2003 at 03:54:47PM +0200, Gerhard Brauer wrote: Ich würde z.B. noch eine netzwerk-lastige Prüfmethode (z.B. ftp oder nfs Kopieraktionen von vielen kleinen und auch einigen großen Dateien) hinzunehmen, neben nmap und samba-Anmeldung. Per ftp ist eine Maßnahme, nfs scheidet aus, es ist nur eine Linux Kiste vorhanden. Gleichzeitig würde ich mal untersuchen, ob der Rechner auch trapt wenn du nicht-netzwerklastige Vorgänge ausführst, also wie vorgeschlagen Kernel-Kompilieren (auch mit Streß), Kopieraktionen auf der/den Platten, etc. Kopieraktionen auf der Platte hatte ich schon durchgeführt, da bleibt die Maschine nicht hängen. Nur: wenn du merken solltest daß die Traps im Zusammenhang mit der Netzwerk-Traffic stehen würde ich auf jedenfall die Karte testweise tauschen. Und bei einem Produktiv-Server würde ich auf Qualität achten. Es haben sich ja schon einige Ideen gesammelt, denen ich alle mal nachgehen werde, aber leider erst am WE. Danke schomal an alle Beteiligten. Ne kleine Rückmeldung was es war gibts natürlich. (Hoffe ich doch ;) Gruß, Charlie -- ICQ: 15899282 Tel.: 02641/204387 Mobil Tel.: 0162/9412753 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: SMP - kernel panic
High, high ... * Charles Imbusch [EMAIL PROTECTED] schrieb am [09.09.03 00:03]: 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? Normalerweise eigentlich nicht, udn die Wahrscheinlichkeit wird geringer je weniger system/hardware-nah die Programme sind. Es gibt ja kaum Programme, die sich anders verhalten wenn sie SMP vorfinden. Aber die fertig kompilierten Programme sind ja für eine allgemeine Plattform gebaut, also minimal 386 bzw. Pentium. Da sind dann evtl. nicht alle Optimierungen bzw. Prozessor-Besonderheiten enthalten die du bei einer eigenen Kompilierung unter deinem System bekommst. Nimm mal allein den Unterschied zwischen AMDs und Intels. Und bei deinem System mußt du diese *Möglichkeit* auch noch mit der Anzahl deiner CPUs potenzieren. Also Murphy würde ganz klar sagen: ja Außerdem ist es ja nur eine Möglichkeit von vielen. Gerade bei solchen Problemen wie deinem, die sich nicht direkt auf eine bestimmte Ursache zurückführen lassen bzw. nicht reproduzieren lassen, ist es IMHO wichtig eine logische Fehlersucheinkreismethode zu finden, die alle Möglichkeiten einer Fehlerbehebung erstmal erfasst und dann nach Wahrscheinlichkeit sortiert. Das Selbstkompilieren ist also eine Möglichkeit, aber die Wahrscheinlichkeit als Fehlerursache momentan eher gering. Siehe auch weiter unten. 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. nmap ist wie samba (zumindest bei deiner Fehlerbedingung) ja ein netzwerk-lastiges Programm. Jetzt wäre doch interessant, im Sinne der logischen Fehlersucheinkreismethode ;-) zu probieren, ob die panics nur oder immer im Zusammenhang mit echtem Netzwerktraffic auftreten. Ich würde z.B. noch eine netzwerk-lastige Prüfmethode (z.B. ftp oder nfs Kopieraktionen von vielen kleinen und auch einigen großen Dateien) hinzunehmen, neben nmap und samba-Anmeldung. Gleichzeitig würde ich mal untersuchen, ob der Rechner auch trapt wenn du nicht-netzwerklastige Vorgänge ausführst, also wie vorgeschlagen Kernel-Kompilieren (auch mit Streß), Kopieraktionen auf der/den Platten, etc. Wenn du dann feststellt, das die panic immer im Zusamenhang mit Belastung der Netzwerk-Karte auftritt bist du doch schon einen großen Schritt weiter. Die Prioritäten der logischen Fehlersucheinkreismethode verschieben sich doch dann gewaltig, die Notwendigkeit von Selbstkompilieren von Programmen wird unwahrscheinlicher, das Austauschen der Netzwerkkomponente wird wahrscheinlicher. 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? Tut mir leid, der Hersteller sagt mir jetzt nichts, möchte auch nicht googeln. Interessanter wäre der Chipsatz, also welches Modul geladen wird. Wenn es ein OnBoard-NIC ist, dann ist es meiner Meinung nach ein Billigteil wenn es nicht wenigstens ein Intel-Chip(eepro/eepro100) oder 3Com ist. Das aber ohne Wertung, da kann dir jemand anderes vielleicht besseres dazu sagen. Nur: wenn du merken solltest daß die Traps im Zusammenhang mit der Netzwerk-Traffic stehen würde ich auf jedenfall die Karte testweise tauschen. Und bei einem Produktiv-Server würde ich auf Qualität achten. Danke schonmal Grüsse, Charlie Gruß Gerhard -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re[2]: SMP - kernel panic
Hallo Charles On Mon, 8 Sep 2003 10:47:34 +0200 Gerhard Brauer [EMAIL PROTECTED] wrote: 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 Problem könnte tatsächlich am Netzwerkkartentreiber liegen. Die Treiber müssen nämlich ebenfalls für SMP kompiliert sein, da sonst Spinlocks auftreten können (so wie ich das verstanden habe, wenn ein Prozessor auf die Hardware zugreift, muss es für den andern Proz. gesperrt werden, da gewöhnliche Hardware nicht mit Zugriffen von zwe CPUs rechnet). Meistens ist der Code im Treiber vorhanden, wird aber nur reinkompiliert, wenn für SMP kompiliert wird. Eigentlich meine ich, dass die Debian Standard-SMP Kernel, das richtig machen müssten. Hast Du den Standardkernel kernel-image-2.4.18-686-smp ausprobiert? Geht es da auch schief? Grüsse, Adrian. -- Adrian Zaugg [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: SMP - kernel panic
High, high ... * Charles Imbusch [EMAIL PROTECTED] 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 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: SMP - kernel panic
On Mon, Sep 08, 2003 at 12:13:19AM +0200, Stefan Frank wrote: [...] Aber immer wieder blieb die Kiste stehen oder der Kernel crashte. Aber mit nur einer CPU war immer alles ok. Also zum Schluss beide CPUs getauscht und seitdem ist Ruhe. Ich hoffe bei Dir ist das nicht der Fall. Waren denn beide CPUs definitiv kaputt, oder hast Du sicherheitshalber einfach beide ausgetauscht? Dann könnte es doch sein, dass Du eine intakte CPU in die Tonne gekloppt hast. Grüsse, Charlie -- ICQ: 15899282 Tel.: 02641/204387 Mobil Tel.: 0162/9412753 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
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 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: SMP - kernel panic
Hi Charlie, Waren denn beide CPUs definitiv kaputt, oder hast Du sicherheitshalber einfach beide ausgetauscht? Dann könnte es doch sein, dass Du eine intakte CPU in die Tonne gekloppt hast. Gott (oder wer auch immer) bewahre, jede CPU einzeln fuer sich lief _ohne_ Probleme. Nur zusammen wollten sie nicht. Hab die einfach mit den CPU's zweier Desktops getauscht. ciao, Stefan -- It does me no injury for my neighbor to say there are twenty gods or no God. It neither picks my pocket nor breaks my leg. -- Thomas Jefferson -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
SMP - kernel panic
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. 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 hatte google angeworfen und schon einige Male gesehen, dass es ein kernel bug sein könnte und deshalb das Ganze mit 2.4.22 ausprobiert. Aber auch da wars genauso. Hat jemand ne Idee? Grüsse, Charlie -- ICQ: 15899282 Tel.: 02641/204387 Mobil Tel.: 0162/9412753 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: SMP - kernel panic
Hi Charles, ich möcht Dich ja nicht erschrecken, aber ich hatte so was ähnliches, als ich meinen SMP Rechner zusammenbaute. Ich hatte meine CPUs bei ebay ersteigert (NIE wieder). Damals hab ich alles mögliche getauscht und versucht. Aber immer wieder blieb die Kiste stehen oder der Kernel crashte. Aber mit nur einer CPU war immer alles ok. Also zum Schluss beide CPUs getauscht und seitdem ist Ruhe. Ich hoffe bei Dir ist das nicht der Fall. Bye, Stefan -- It does me no injury for my neighbor to say there are twenty gods or no God. It neither picks my pocket nor breaks my leg. -- Thomas Jefferson -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
