Ich habe einige eingebettete Serversysteme auf Basis von i7-4700EQ, die Hyperthreading erfordern. Alles ist gut, außer dass in seltenen Fällen das Hyperthreading-Flag im CMOS deaktiviert wird. Solange die Hardware noch in meinem Besitz ist, kann ich einfach neu starten, ins CMOS gehen und die Einstellung korrigieren. (Alle anderen Einstellungen im CMOS bleiben in Ordnung, einschließlich Uhrzeit/Datum, also gehe ich davon aus, dass es nicht an der Batterie liegt.)
Nach der Bereitstellung ist jedoch kein Konsolenzugriff mehr möglich. Wenn die CMOS-Einstellungen verloren gehen, könnte das Gerät zwar „repariert“ werden, aber das scheint eine Menge Arbeit für ein sehr einfaches Problem zu sein.
Nach meinem Verständnis liest der Linux-Kernel das BIOS nur, um Kernelvariablen zu initialisieren. Ist das richtig?
Wenn das richtig ist, gibt es eine Möglichkeit, dem Linux-Kernel mitzuteilen, dass er die BIOS-Meldungen ignorieren und einfach Hyperthreading im Kernel aktivieren soll?
Gibt es, wenn möglich, eine einfache Möglichkeit (z. B. eine Grub-Befehlszeileneinstellung), dies zu tun? Oder kann man, wenn möglich, aber schwierig, die BIOS-Anweisungen ignorieren und Hyperthreading aktivieren, indem man die Kernel-Quelle ändert und neu kompiliert?
Obwohl ich nicht dachte, dass es funktionieren würde, habe ich es bereits in /etc/default/grub versucht
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash maxcpus=8 nr_cpus=8"
anschließend habe ich update-grub verwendet und neugestartet. (Ich habe auch versucht, maxcpus und nr_cpus einzeln einzustellen.)
Ich habe zahlreiche Beispiele dafür gefunden, wie Hyperthreading auf einem laufenden System deaktiviert und dann wieder aktiviert wird. Aber keine Beispiele dafür, wie es aktiviert wird, wenn der Kernel fälschlicherweise denkt, ein Mensch hätte Hyperthreading absichtlich deaktiviert.
Schließlich könnte ich behaupten, es liege an der „defekten Hardware“, aber damit allein wird man keinen „Krieg“ gewinnen. Wenn es nicht möglich ist, Hyperthreading trotz des BIOS zu aktivieren, ist das eine gültige Antwort – und die Antwort wird mir nützlich sein, wenn sie Beweise/Erklärungen dafür enthält.
Antwort1
Als allgemeine Regel ist dies nicht ganz richtig.
Beispiel 1:SMIFirmware-Interrupt-Handler (auch BIOS-Interrupt-Handler genannt) laufen auch nach dem Booten des Kernels noch, allerdings mit höheren Berechtigungen als der Kernel. Sie können gerne versuchen, SMM zu bekämpfen. Erwarten Sie jedoch nicht, dass Linux besonders daran interessiert ist, Ihnen zu helfen.
Beispiel 2: Die Firmware für „Secure Boot“ kann zwar selbst aktualisiert werden, aber es ist im Allgemeinen keine gute Idee, das Betriebssystem die Firmware mit einem beliebigen Image überschreiben zu lassen. Daher sollte die Firmware vor dem Booten des Betriebssystems/Bootloaders ein Hardware-Flag setzen, um Schreibvorgänge auf den Firmware-Chip zu verhindern. Sobald das Flag gesetzt ist, sollte es nicht möglich sein, es ohne Neustart zu entfernen. Oder so ähnlich. Es kommt vor, weil einige Firmwares dies natürlich nicht richtig gemacht haben ... ein Beispiel istHier.
Ich weiß nicht, ob das Zulassen von SMT ein weiteres Beispiel ist oder nicht.
Es ist unerwünscht, gegen die Firmware zu kämpfen. Es ist besonders unerwünscht, gegen die Firmware zu kämpfen, wenn Ihr Betriebssystem (Linux) nicht versucht, Sie zu unterstützen. (Zum Beispiel, wenn esbekämpft die Firmware über ACPI ATA-Befehle. Oder konstruktiver ausgedrückt: Linux ignoriert C-Statusinformationen aus dem ACPI-BIOS, wenn es auf einer Intel-CPU läuft, für die es bereits genaue C-Statusinformationen kennt).
(Außerdem könnten Sie Ihr Ziel auch dann nicht erreichen, wenn die allgemeine Regel angewendet würde. Sie könnten beispielsweise das BIOS benötigen, um das Layout zu erfahren. Und es könnte Gründe geben, warum Sie nicht davon ausgehen möchten, dass das Layout statisch ist. Das heißt, Gründe, warum es keine gute Idee ist, den Kernel so zu patchen, dass er die vom BIOS bereitgestellten ACPI-Tabellen ignoriert und stattdessen die ACPI-Tabellen verwendet, die Sie beim Booten mit allen gewünschten BIOS-Einstellungen erfasst haben.)
Selbst wenn Ihr Ziel erreichbar ist, würde ich denken, dass Sie sich mit hardwarespezifischen Details befassen würden. Es wäre sehr beeindruckend, wenn Sie einen Weg finden würden, SMT im Kernel zu aktivieren, das warnichthardwarespezifisch. Ich würde einer Antwort auf diese Frage nicht ganz vertrauen, dass sie kanonisch ist, wenn darin nicht angegeben wäre, dass sie auf einem passenden Motherboard und mit einer passenden Firmware-Version getestet wurde, und Sie haben nicht angegeben, um welche Version es sich handelt.
Aus diesem Grund glaube ich nicht, dass Linux-Entwickler versuchen werden, Sie hier zu unterstützen. Es handelt sich nicht um ein sehr häufiges Problem.