Linux stecken in CPU-Soft-Lockup?

Mein System ist ein CentOS 6.3 (Kernel-Version 2.6.32-279.el6.x86_64 ausgeführt).Linux stecken in CPU-Soft-Lockup?

Ich habe ein ladbares Kernel-Modul, das ein Treiber ist, der eine PCIe-Karte verwaltet. Wenn ich den Treiber unter Verwendung von insmod manuell einfüge, während das Betriebssystem ausgeführt wird, wird der Treiber erfolgreich geladen und ist betriebsbereit.

Wenn ich jedoch versuche, den Treiber mit rpm zu installieren und dann das System neu zu starten, bleibt das Betriebssystem während des Startvorgangs stecken und spuckt die folgende "Soft-Lockup" -Nachricht für ALLE CPU-Kerne aus, mit Ausnahme eines Kerns in " soft lockup "in einem der Threads, die von meinem Treiber erstellt wurden.

BUG: soft lockup - CPU#X stuck for 67s! [migration/8:36] 
.......(same above message for all cores except one) 
BUG: soft lockup - CPU#10 stuck for 67s! [mydriver_thread/8:36] 
(one core is locked up in one of the threads in my driver).

Ich suchte im Netz ziemlich viel für Informationen zu diesem Kernel msg/bug, und es gibt ziemlich viele Beiträge darüber, keine auf, was es bewirkt, oder wie zu debuggen. Jede Hilfe mit den folgenden Fragen wirklich geschätzt würde:

Ich bin nicht in der Lage, in das System einzuloggen, ich denke, es ist, weil alle Kerne in einem „weichen Überbrückungs“ Zustand sind, und kann daher nicht auslösen einen Kernel Dump von der Shell-Eingabeaufforderung. Ich habe SysRq aktiviert und versucht, einen Kernel-Dump mit SysRq-Key-Combo auszulösen, aber kein Glück. Es scheint, dass das System nicht auf die Tastatur reagiert (nicht einmal auf die CapsLock-Taste). Irgendwelche Vorschläge, wie ich in diesem Fall einen Kernel-Dump auslösen kann?
Ich kann mir vorstellen, dass möglicherweise mein Treiber Thread "Soft-Lockup" verursacht. Aber wie kann der Thread "Migration" (ein Kernel-Thread) nur wegen meines Treibers in einer "weichen Sperre" sein?
Beim Durchsuchen des Netzes wird der Thread "Migration" verwendet, um Aufgaben von einer CPU in eine andere zu verschieben. Kann mir bitte jemand helfen, zu verstehen, was dieser Thread genau macht? Und wie kann es von anderen Threads beeinflusst werden, wenn überhaupt.

Quelle

2013-02-28 Ahmed A

Es wäre sehr hilfreich, wenn Sie uns einige Stack-Spuren zeigen könnten. – cdleonard

Wenn das Problem beim Neustart auftritt, denke ich an die vielen vielen Probleme, die die Module beim Laden der Firmware hatten, wenn keine Firmware vorhanden ist. Versucht der Treiber von der ursprünglichen Ramdisk zu laden? Fordert es Firmware und bekommt es nicht? Ist Ihr Treiber während der Initialisierung Schleife und alle Arbeitswarteschlangen Threads oder etwas hogging? –

@cdleonard Es gibt keine Backstrace auf dem Bildschirm. Alles, was ich bekomme, sind sechzehn Zeilen derselben Kernel-Nachricht ("BUG: soft lockup .....") für jeden der 16 Kerne im System. Eine dieser Nachrichten ist für einen Kern, der mit einem Thread von meinem Treiber beschäftigt ist, und der Rest des Kerns ist mit dem Migrationsthread festgefahren. –

Ich hatte ein sehr ähnliches Problem auf meinem Desktop. Es würde sich sehr oft lockern - ungefähr einmal am Tag oder so.

Es stellt sich heraus, dass es war, weil ich auf einem Intel Haswell lief. Es scheint, dass die Haswell/Broadwell-Reihe von Intel-Prozessoren einen Fehler aufweist, der Systeminstabilität verursachen kann. Dieser Fehler wurde in einem Microcode-Update behoben.

Überprüfen Sie, ob CentOS ein Intel-Microcode-Paket anbietet, und installieren Sie es. Stellen Sie sicher, dass Sie grub so konfigurieren, dass es als initiale Ramdisk geladen wird, bevor es initramfs lädt.

Persönlich habe ich meinen Mikrocode durch Booten in Windows und Ausführen eines BIOS-Updates aktualisiert. Sie können überprüfen, ob der Microcode tatsächlich aktualisiert wurde, indem Sie die Ausgabe von grep 'microcode' /proc/cpuinfo vor und nach dem Update vergleichen.

Quelle

2016-06-14 12:36:12

Antwort

Verwandte Themen