Arch Linux

kernel Meldung : CPU not responding

SiD

Moin, bei meinem neuen Rechner tritt ab und zu das Problem auf, das beim booten scheinbar nicht alle Kerne erkannt werden.

[    5.276951] CPU1: Not responding.
[   10.363897] CPU2: Not responding.
[   15.483850] CPU3: Not responding.

es ist ein i3 2100 auf einem AsRock H67M Board. Ich glaube das ist zum ersten mal aufgetreten, nachdem ich einen anderen Lüfter auf den Mugen2 montiert habe, kann es sein, dass ich dabei zu sehr am Mugen "gewackelt" habe, das da irgendwo was kaputt gegangen ist, oder sowas wie ein kleiner Wackler da ist?

EDIT://
Ich kann nicht genau sagen, ob das immer so ist, aber eben gerade hat es geholfen einmal kurz ins BIOS / EFI zu gehen, nichts zu ändern und dann bootet er normal. Ich meine das war schon öfters so.

Cabal

Den Mugen2 hab ich auch. Der hat gut Gewicht^^

wenn dein Bios schon am Anfang Probleme hat, die CPU zu erkennen, tipp ich mal auf Mobo oder CPU (orakel). Check beim Booten mal die LED's oder die Anzeige (oder was auch immer dein Board zum leuchten bringt 😉) Wenn das BIOS irgendwo hält, Leuchtsignal checken und ins Handbuch gucken.

Ansonsten stress mal die CPU mit prime95. Wenn sie da abschmiert, darfst Dir um sie Gedanken machen.

greetz

PS: Sry für späte antworten

SiD

Also das ist bis jetzt erst wieder einmal aufgetreten. Der Rechner fährt dann aber trozdem hoch, aber laüft dann nur mit einem Kern.
mprime läuft auch ohne abzustürzen (nur probiert nachdem normal mit allen Kernen gebootet wurde)

Das ganze tritt auf, nachdem der Bootloader (syslinux) den kernel geladen hat, bzw beim laden des kernels.

edit:

Cabal schriebWenn das BIOS irgendwo hält, Leuchtsignal checken und ins Handbuch gucken.

Das BIOS hängt nicht, tritt wie gesagt erst nach Syslinux auf.

SiD

Also eine Lösung habe ich bis jetzt noch nicht gefunden, aber ich habe gerade mal die aktuellste BIOS / UEFI version draufgeflashed.
Mal sehen obs was bringt.

[gelöscht]

Hatte ich mit meinem I7 (StockTakt) auch ein paar mal.

Scheint am Board zu liegen (Gigabyte, bzw am CPU-Sockel) das er beim Anspringen nicht genug saft bekommt, bzw Auto die Vcore zu niedrig ansetzt. Ist mir in 5 Monaten 2 x passiert.

Da ich den eh OC habe und Vcore per Hand einstelle ist das Problem weg.

Wenn du das öfters hast:
Einfach die Vcore fest einstellen und nicht auf Auto. Hast du 0 Unterschied zu! Vllt sogar ne etwas kühlere CPU da Auto "meistens" immer ein bischele mehr Saft auf die CPU gibt damit die Läuft. Undervolten / Feste VCore lässt die Garantie _nicht_ erlischen.

Grüße

SiD

Danke für den Tip, ich werde das jetzt erstmal so im Auge behalten und falls das BIOS Update nichts gebracht hat mal ausprobieren.

SiD

Also es lief jetzt die ganze Zeit immer, ohne den Fehler. Bis jetzt ....

Gerade trat das Problem an dauernd auf, derREchner ist bestimmt erst nachd em 20sten Versuch hochgefahren.

Oescher schrieb Wenn du das öfters hast:
Einfach die Vcore fest einstellen und nicht auf Auto. Hast du 0 Unterschied zu! Vllt sogar ne etwas kühlere CPU da Auto "meistens" immer ein bischele mehr Saft auf die CPU gibt damit die Läuft. Undervolten / Feste VCore lässt die Garantie _nicht_ erlischen.

Hat leider auch nichts gebracht.

SiD

also jetzt grad wollte der REchner wieder gar nicht hochfahren, auch nach mehreren Versuchen nicht.

Ich habe dann mal die SystemrescueCD von einem USB Stick probiert zu booten, ging auch nicht, dann habe ich es nochmal mit dem Stick und acpi=off probiert:

und dann hat er zumindest mal gebootet zwar nur mit einem Kern, aber wenigstens ist der REchner benutzbar. 😉

so, dann nochmal ohne acpi=off probiert, fährt wieder nicht hoch -> mit acpi=off -> fährt hoch.

Ob das nun immer so ist, keine Ahnung, jetzt grad tritt der Fehler wieder nicht auf, aber ich habe mir in der syslinux.cfg vorsichtshalber mal einen neuen Eintrag erstellt (acpi=off). Mal sehen obs beim nächsten mal dann damit klappt.