[Lösung] CPU-Deadlock auf Dual/QuadP3-Systemen nach 5-7 Tg.

[hjm82]

UPDATE: ist nicht mehr spezifisch für den Netfinity 5000, sondern selbes Problem auch mit Quad-P3-Xeon (Netfinity 7000 M10) aufgetreten!

UPDATE 20.6.2012: Problem könnten NMIs bzw. der Watchdog-Mechanismus sein - siehe hinzugefügte Antwort.


Hallo zusammen!

Ausgangslage: ich betreibe mehrere SMP-Systeme mit Pentium-3-CPUs, darunter einen IBM Netfinity 5000 mit 2x P3-Coppermine und, ihm am vergleichbarsten, einen IBM xSeries 232 mit 2x P3-Tualatin. Auf allen Systemen läuft Debian testing (wheezy) mit einem aktuellen Stand und relativ ähnlicher Konfiguration.

Problem: der Netfinity 5000 läuft, im Gegensatz zu den anderen Systemen, nicht stabil mit neueren Kerneln als der Version 2.6.32. Ich habe alle getestet, von 2.6.38, 2.6.39 und 3.0 bis nun mittlerweile 3.2.1.
Mit allen diesen neuen Versionen habe ich das Problem, daß es nach einiger Laufzeit (min. ca. 1 Stunde, max. ca. 60 Stunden) zu enen völligen Aufhängen des Systems kommt, das - insbesondere mit dem Kernel 3.2.1, mit dem ich aktuell teste - ein Deadlock zwischen den beiden CPUs zu sein scheint (der Netfinity 5000 hat an der Frontplatte zwei "Aktivitäts-LEDs" für die CPUs, die in "eingefrorenem" Zustand ein sich in immer gleicher Folge wiederholendes Blinkmuster zeigen; bei einem normalen Absturz wäre dies nicht der Fall).

Die verwendeten Kernel sind die von Debian paketierten, je nach Version aus stable, testing oder experimental; seit der "Zwangseinführung" von PAE für die SMP-fähigen Kernel dementsprechend diejenigen mit PAE.

Leider hinterläßt der Deadlock nichts auf der Festplatte, so daß ich bisher an keine konkreten Infos zur Ursache des Problems kommen konnte (allerdings plane ich, sobald wie möglich einen Log über die serielle Schnittstelle aufzuzeichnen, in der Hoffnung daß hier noch Meldungen kommen).

Ich habe die Konfigurationen und Kernel-Logs der beiden genannten Rechner schon intensiv verglichen und komme als wesentliche Unterschiede nur auf das folgende:
- der Netfinity 5000 hat eine Onboard-LAN-Karte, die den AMD pcnet32-Treiber verwendet
- im Gegensatz zum xSeries 232 (2 IO-APICs) hat der Netfinity 5000 nur einen IO-APIC

Kann das Problem irgendwas mit der BKL-Thematik zu tun haben? Mit den neueren Kerneln werden offenbar auch intensiv NMIs für das Locking verwendet - mit 2.6.32 ist der NMI-Zähler für alle CPUs stets null, mit den neueren Versionen wächst er im Betrieb stetig.

Anbei noch die dmesg-Ausgaben der Bootvorgänge:

Kernel 2.6.32: http://nopaste.debianforum.de/36212
Kernel 3.2.1: http://nopaste.debianforum.de/36213

Besten Dank im Voraus für jede Unterstützung!

Schöne Grüße,
Hans-Jürgen

[hjm82]

Hallo,

zwischenzeitlich habe ich Protokolle über die serielle Schnittstelle erstellt, während der Rechner in diesem Deadlock hängenblieb. Daraus ist absolut gar nichts ersichtlich - die zeitlich letzten Einträge sind verworfene Firewall-Pakete, die von der PPP-Schnittstelle kamen.

Diese Tatsache und Konfigurationsvergleiche mit den anderen SMP-Systemen verleiten mich im Moment zu der Vermutung, daß es am Treiber "pcnet32" liegen könnte, der über das AMD-Onboard-LAN für die PPPoE-Verbindung zuständig ist. Zum Test habe ich diesen Chip nun deaktiviert und für die PPP-Verbindung eine (weitere) tg3-Karte eingebaut - diesen Kartentyp nutze ich in allen Systemen für das lokale Netz und hatte damit keinerlei Stabilitätsprobleme, sehe das also als ein zuverlässiges Entscheidungskriterium.

In etwa drei bis vier Tagen sollte spätestens klar sein, ob ohne pcnet32 der Deadlock nochmals auftaucht.

Falls jemand Erfahrungen oder detailliertere Infos zu diesem Treiber und evtl. Zusammenhänge mit der BKL-Entfernung hat, bin ich um jeden Hinweis dankbar. Sollte sich der Verdacht bestätigen, daß hier ein Problem ist, würde ich das gerne irgendwo als Bug melden - welcher Weg wäre da zu gehen bzw. könnte mich hierbei jemand unterstützen?

Besten Dank und Grüße,

Hans-Jürgen

[rendegast]

Code: Alles auswählen

$ /sbin/modinfo pcnet32
filename:       /lib/modules/3.2.0-0.bpo.1-amd64/kernel/drivers/net/ethernet/amd/pcnet32.ko
license:        GPL
description:    Driver for PCnet32 and PCnetPCI based ethercards
author:         Thomas Bogendoerfer
alias:          pci:v00001023d00002000sv*sd*bc02sc00i*
alias:          pci:v00001022d00002000sv*sd*bc*sc*i*
alias:          pci:v00001022d00002001sv*sd*bc*sc*i*
depends:        mii
intree:         Y
vermagic:       3.2.0-0.bpo.1-amd64 SMP mod_unload modversions
parm:           debug:pcnet32 debug level (int)
parm:           max_interrupt_work:pcnet32 maximum events handled per interrupt (int)
parm:           rx_copybreak:pcnet32 copy breakpoint for copy-only-tiny-frames (int)
parm:           tx_start_pt:pcnet32 transmit start point (0-3) (int)
parm:           pcnet32vlb:pcnet32 Vesa local bus (VLB) support (0/1) (int)
parm:           options:pcnet32 initial option setting(s) (0-15) (array of int)
parm:           full_duplex:pcnet32 full duplex setting(s) (1) (array of int)
parm:           homepna:pcnet32 mode for 79C978 cards (1 for HomePNA, 0 for Ethernet, default Ethernet (array of int)


"author: Thomas Bogendoerfer" Kernel-Mailinglist?
Parameter ausprobieren?

Mit den neueren Kerneln werden offenbar auch intensiv NMIs für das Locking verwendet - mit 2.6.32 ist der NMI-Zähler für alle CPUs stets null, mit den neueren Versionen wächst er im Betrieb stetig.

Im Rahmen ist das wohl nichts besonderes, AMD X2, 3.2.0.bpo (3.2.4):

Code: Alles auswählen

$ grep MI /proc/interrupts -C1
 42:        168      51158   PCI-MSI-edge      eth0
NMI:         48         56   Non-maskable interrupts
LOC:     593829     205860   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:         48         56   Performance monitoring interrupts
IWI:          0          0   IRQ work interrupts
--
ERR:          1
MIS:          0

$ uptime
 04:36:12 up 16:02,  4 users,  load average: 0.00, 0.01, 0.05


[hjm82]

Hallo!

Danke für die Anmerkung, ich werde schauen, den Autor zu kontaktieren, sollte sich der Verdacht auf den Netzwerktreiber erhärten.

Erst aber ein kurzer Zwischenbericht: seltsam ist, daß es nach dem temporären Deaktivieren der pcnet32-Karte noch auftritt, aber seltener und deterministischer. Ziemlich genau nach 7 Tagen Dauerbetrieb kommt es nun zum Deadlock, davor war es oft früher und nach variablen Zeiträumen.

Nun fiel mir beim letzten Update noch etwas auf:
- in der fstab waren noch Einträge für sysfs und nfs-rpc, was "früher" mal eine Zeit lang nötig war und dann dort vergessen war, bis es jetzt von neuen Kernelversionen nicht mehr toleriert wird (Typ "sysfs" nicht mehr bekannt).

Seit dem Wochenende läuft das System nun mit der korrigierten fstab und ich warte mal wieder geduldig 8 Tage. Das ist tatsächlich ein weiterer Unterschied zu den anderen Multi-CPU-Maschinen, welche alle mit Lenny bzw. Squeeze begonnen haben - mein "Problemfall" dagegen ging erstmals mit Etch in Betrieb und wurde seither regelmäßig aktualisiert.

Mal schauen, vielleicht lasse ich mal testweise ein weiteres System über 2 Wochen zum Test laufen - mache das nur in aller Regel ungern, wenn damit nicht wenigstens eine sinnvolle Aufgabe verknüpft ist.

Hat niemand ein ähnliches System mit Kernel-Version > 2.6.38?

Beste Grüße,

Hans-Jürgen

[hjm82]

Hallo!

Mittlerweile gibt es neue "Erkenntnisse", oder besser gesagt einen Mangel davon:

- der Netzwerktreiber ist es NICHT. Es schien zwar stabiler/länger zu laufen, aber ändert das Verhalten qualitativ nicht.

- der Dual-P3 (Netfinity 5000) ist nun auch einmal wieder früher ausgestiegen, nach 5 Tagen. Nun ist er zurück auf Kernel 2.6.32, um erstmal wieder stabil zu laufen.


- alle vier SMP-Maschinen laufen im Moment im Dauerbetrieb mit dem aktuellen wheezy-Kernel 3.2.x (ich habe sinnvolle Aufgaben für den Dauerlauf gefunden), um Vergleichsergebnisse zu liefern.


- Ein Quad-P3-Xeon-System hat es heute erwischt - nach etwas mehr als 4 Tagen Laufzeit blieb es heute mit demselben Fehler stehen. Komplett blockiert (und nichts im Protokoll), und mit dauerflimmernden CPU-Aktivitäts-LEDs, wobei hier eine "Gewichtung" der Helligkeit erkennbar war: CPU1 hat die meiste Aktivität, dann etwas weniger jeweils CPU2 und CPU3, am wenigsten CPU4.

- System wurde per Reset neugestartet und läuft wieder - mal schauen, wie lange.

Es MÜSSEN doch eigentlich noch irgendwelche Leute dieses Problem haben!!??

Langsam bin ich am Verzweifeln, vor allem bringt nicht weiter...

Da sehr wenig Reaktionen kommen, benenne ich das Thema evtl. mal um.

Danke für jede Hilfe und beste Grüße,

Hans-Jürgen

[hjm82]

Hallo nochmals,

in letzter Zeit verfolge ich vermehrt (bisher nur lesend) die Diskussionen auf lkml.org. In den letzten Tagen habe ich einen recht interessanten Hinweis gefunden:

https://lkml.org/lkml/2012/3/15/157

Generell scheinen gerade einige Deadlocks, Livelocks und Race Conditions diskutiert zu werden - ich hoffe, daß evtl. dabei eine Lösung herauskommt. Mich wundert es, daß irgendwie niemand sonst diesen Fehler zu kennen scheint.

Es wird wohl sinnvoll sein, mal ein englischsprachiges Forum zu bemühen oder doch einen der Wege einer Kernel-Bug-Meldung zu nutzen - davor schrecke ich bisher etwas zurück, da ich nur das Verhalten beschreiben kann, aber absolut nichts an handfesten Logs o.ä. mitliefern kann und das Ganze auch nicht in einer VM "komfortabel" testen kann. Falls jemand meine Kompetenz in Frage stellt - ich bin Linux-Nutzer seit 14 Jahren, angefangen mit Suse 6.0 und Debian 2.0, und habe dabei schon viele komplexere Probleme gelöst und exotische Hardware zum Laufen gebracht, z.B. IBM Microchannel-Systeme, oder arbeite auch an Bugfixes für manche Treiber mit. Fast immer gibt es etwas Vernünftiges als Protokoll oder klare Indizien, wo man sich entlanghangeln kann (z.B. hatte ich mal Kernel-Paniken, die auf defekten RAM und auch auf eine nicht sauber initialisierte Swap-Partition zurückzuführen waren).
In diesem Fall bin ich aber nun wirklich verzweifelt, weil NULL an Information extrahierbar ist und der Fehler lange Wartezeiten bis zum Auftreten mit sich bringt, und zudem an meinem Vertrauen in Linux etwas kratzt, da ich zuverlässige Rechner benötige, andererseits aber nicht länger auf Kernel 2.6.32 angewiesen sein möchte. Leider konnte ich auch 2.6.37 nicht testen, da der nur kurzzeitig in den testing-Repositories war.

Aktuell läuft Kernel 3.3.0, auch dieser scheint vom Problem nach wie vor betroffen, zwei Rechner blieben innerhalb eines Tages nach dem updatebedingten Neustart stehen, seit einem zweiten Neustart aber schon wieder mehrtägiger Betrieb ohne Fehler.

Interessanterweise (zumindest "gefühlt") tritt das Problem eher in Schwach- als in Vollast-Phasen auf.


Beste Grüße,

Hans-Jürgen

[hikaru]

Auf [1] wirst du 2.6.37 und viele andere Kernelversionen finden. Schau dich mal in den Archiven von Anfang 2011 um!

[1] http://snapshot.debian.org/

[rendegast]

weil NULL an Information extrahierbar ist

Vielleicht können kexec / kdump aushelfen?
Pakete kexec-tools kdump-tools
http://www.ibm.com/developerworks/linux/library/l-kexec/index.html
http://prefetch.net/blog/index.php/2009/07/06/using-kdump-to-get-core-files-on-fedora-and-centos-hosts/

[hjm82]

Hallo zusammen,

besten Dank für die Antworten! Den Snapshot-Service kannte ich noch nicht, das ist ja sehr hilfreich und für viele Lebenslagen gut zu wissen. Hoffentlich reicht dafür dort der Speicher lange, so viele Paketversionen wie es gibt...

Danke auch für kexec/kdump - sollte auch mit Kernel 3.4.x keine Besserung eintreten, so werde ich mich an derart erweiterte Methoden mal dranmachen.

Nun aber zum aktuellen Zwischenstand: mit Kernel 3.3.0 habe ich (nach einem einzigen Hänger am ersten Tag und Reboot) nun erstmalig mit einem "Nach-2.6.38-Kernel" eine kontinuierliche Uptime von über 10 Tagen erreicht! Das gibt Hoffnung, daß es besser wird. 3.4-rc1 hat bereits die Korrekturen dieses hrtimer/ntp-Livelocks, daher warte ich mal gespannt auf die erste Nicht-rc-Version in experimental oder sid. Vielleicht ist dann diese Durststrecke überstanden.

Mir fiel bei diesem einzelnen Hänger auf, daß es keine Blockade zwischen mehreren CPUs mehr war, sondern die Endlos-Aktivität auf eine beschränkt war. Das macht etwas Hoffnung...

Danke und beste Grüße,

Hans-Jürgen

[hjm82]

Hallo zusammen,

wie versprochen nun eine aktualisierte Rückmeldung und der aktuelle Stand.

Mittlerweile läuft auf den SMP-Maschinen ein Eigenbau-Kernel 3.4.2 basierend auf den siduction-Quellpaketen, da die zeitnah bereitstanden. (Danke an das Team für die Patcherei und praktische Bereitstellung! Nur die Infos zu quilt muß man sich suchen...)

Ergebnis: insbesondere auf dem Dual-CPU-Rechner tritt noch immer gelegentlich eine Blockade auf, allerdings jetzt konsequent nicht mehr als Livelock, sondern nur eine CPU betreffend. Teilweise hat es statt Blockierung auch schon automatische Neustarts gegeben.

Problem allerdings: bei keinem der Vorgänge war etwas protokollierbar, trotz Loggen über RS232 und aktiviertem höchsten Loglevel in /proc/sys/kernel/printk.

Nachdem mir just heute morgen das Ding wieder hängenblieb (direkt beim Frühstück mitbekommen), habe ich heute nochmal intensiv im Internet recherchiert. Wie oben schon genannt, war meine Erkennungs-Systematik die NMI-Aktivität und die Änderung derselben zwischen Debian-Kernel 2.6.32 und 2.6.38.

Zufällig fand ich hierbei diesen Bug-Eintrag:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639331

Nach zahlreichen falschen oder nur teilweise erfolgreichen Fährten könnte das endlich ein Treffer sein. Die beschriebenen Randbedingungen sind genau dieselben wie bei meinem Problem:
--> Beginn mit dem deb-Stand 2.6.38, alles gut mit 2.6.32
--> keine offensichtliche Ursache
--> volle Blockade ohne Diagnoseausgaben
--> von Bug-Betroffenem gefundene Kausalität hat mit NMIs zu tun!

Testweise laufen meine SMP-Maschinen daher seit heute mit der Boot-Option "nowatchdog", was diesen Mechanismus ausschaltet - siehe da, die NMI-Zähler bleiben pro CPU auf "1" stehen (und dieser eine kommt daher, daß ich die NMI-Selbsttest-Suite in den Kernel kompiliert habe). Davor wurde in Intervallen von etwa einer Minute jeder NMI-Zähler inkrementiert.

Eine genaue Aussage wird frühestens in einer Woche möglich sein.

Den Bug werde ich abonnieren und dort einen Kommentar einfügen, evtl. mache ich auch ne Eingabe auf bugzilla.kernel.org, falls ich vom Ersteller des Bugs dort nichts finde.

Im übrigen stimmt unter den Umständen die Kernel-Config-Doku nicht ganz: in der Hilfe steht dort für die NMI-Watchdog-Optionen, daß das Einschalten manuell mit dem Parameter "nmi_watchdog=x" erfolgen muß - aber es scheint auch ohne diese Angabe eine Aktivierung zu erfolgen.

Beste Grüße,

Hans-Jürgen

[Livingston]

Hallo Hans-Jürgen,

leider kann ich nichts zu Deinem Problem beitragen, möchte aber mal loswerden, dass ich es großartig finde, wie Du Dich ich an dem Problem festbeisst und uns hier die Ergebnisse zukommen lässt.
Ich bin davon überzeugt, dass Du dadurch einigen Leuten weiter hilfst, auch wenn Du keine Rückmeldungen erhältst. Ist ja durchaus verständlich. Bei solch einem verzwickten Problem kann ja kaum jemand was Eigenes erarbeiten.

Ciao
Livi

[hjm82]

Hallo,

danke für die Rückmeldung Warum sollte ich mich auch nicht daran festbeißen? Mich ärgert sowas, wenn ich weiß, daß die Hardware in Ordnung ist und irgendeine "blöde" Funktion irgendwas macht, das (in diesem Fall) nicht nötig ist und ggf. andere Probleme mit sich bringt. Auch wenn ich recht jung bin, hatte ich mal noch mitbekommen, daß NMIs generell "was Schlechtes" sind und im Normalbetrieb nicht vorkommen sollten. Man sieht auch, wie schlecht die Kernel-Änderungen dokumentiert sind (insbesondere bzgl. der Vorkonfiguration für Debian), denn keiner konnte in den Rückmeldungen sagen, woher die NMIs kommen. Anfangs dachte ich, das hätte was mit der Entfernung des "BKL" zu tun, so daß die NMIs zur Inter-CPU-Synchronisation hätten dienen können o.ä.

Zudem ärgert es mich manchmal, daß man schnell abgetan wird und das Probem als "exotisch" oder "liegt an der Hardware" abgetan wird - sieht man ja auch an dem Bug-Report mit dem hängenden Laptop, den ich verlinkt habe. "Kann nicht sein" ist die Aussage, und die kam auch im mittlerweile von mir an die Debian-Bugliste gesendeten Thema:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678443

Mal schauen, was rauskommt. In ein bis zwei Wochen weiß ich mehr - "wehe" das Ding läuft bis dorthin durch, dann wäre das "kann nicht sein" widerlegt...

Beste Grüße,

Hans-Jürgen

[hjm82]

Hallo!

Wie es aussieht, ist die aktuelle Ursachen-Vermutung mit dem NMI-Watchdog ein Treffer, bzw. bin ich mal vorsichtig optimistisch. Das hier bringt mich dazu:

netfinity5000:~# uptime
23:39:38 up 11 days, 6:39, 2 users, load average: 0,10, 0,09, 0,06

Der letzte Hänger war am 20. Juni, wo ich dann "nowatchdog" in die Boot-Parameter aufnahm.

Zur endgültigen Prüfung werde ich die nächsten Tage beobachten und bin vor allem gespannt, wie es mit dem Bug-Report weitergeht, wo von mir auch die neuen Ergänzungen etwas detaillierter zu finden sind:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678443

Beste Grüße,

Hans-Jürgen

PS: schade, daß die Titelzeile eines Themas so begrenzt ist, würde die gerne um einen Hinweis auf die Ursache erweitern...

[Livingston]

Vielleicht folgender Titel:
NMI-Deadlock auf Dual/QuadP3 nach 1 Woche
und ggf. den ersten Post um eine kleinen Chronik ergänzen, Motto "Was bisher geschah..."