Je le vois mentionné de temps en temps lorsque le noyau vérifie les CPUs. Je suppose qu'il s'agit d'un type de bug matériel du CPU lié à l'instruction HLT, mais je ne trouve aucune information à ce sujet. Alors, qu'est-ce que hlt_bug en réalité?
Réponses
Trop de publicités?
Je ne suis pas sûr des détails exacts car il s'agit d'un problème ancien, peut-être aussi loin que quand les machines basées sur le 386 étaient courantes.
L'instruction HLT ne peut être appelée qu'en "anneau 0" lorsque le CPU n'est pas en mode "réel", donc elle ne devrait être appelée que par le noyau dans un système d'exploitation moderne. Cela instruit le processeur de faire une pause jusqu'à ce qu'il reçoive la prochaine interruption. Les processeurs modernes passeront alors dans un état de faible consommation d'énergie à ce stade, bien que ce ne soit pas aussi simple pour les processeurs avec plusieurs cœurs évidemment.
Si je me souviens bien, le bug était que certains processeurs 386 ne se réveillaient pas en réponse à certaines interruptions dans certaines circonstances. La vérification de l'existence de ce bug se fait en configurant un temporisateur auquel les processeurs affectés sont connus pour répondre et un qu'ils ne répondent pas — si le CPU se réveille pour la première fois en réponse au premier temporisateur, vous savez donc que le bug existe car il aurait déjà dû se réveiller auparavant et gérer l'interruption du deuxième temporisateur plus court. Comme l'instruction HLT est généralement rarement appelée en dehors du noyau, vous n'avez pas à vous en préoccuper — je suppose que le seul effet du drapeau "bug hlt found" est d'empêcher le code de gestion de l'alimentation d'appeler HLT pour mettre en veille les processeurs qui ont le bug et qui pourraient ne pas se réveiller.
La seule référence que j'ai trouvée à ce bug en ligne (à part des copies de la sortie de démarrage du noyau, les fichiers sources bugs.* et cette question (wow, les questions sur ces sites apparaissent rapidement dans la base de données de Google!)) après une recherche rapide est une discussion sur la nécessité de maintenir la vérification de ce bug dans le noyau de nos jours, car il est peu probable qu'il affecte les configurations matérielles que les gens utilisent actuellement ou utiliseront à l'avenir.
Édit: ce HOWTO mentionne un problème HLT dans certaines puces 486DX-100 (recherchez la page pour no-hlt pour la référence). Il se peut que ce soit le problème que je me rappelle (plutôt qu'un problème avec certains processeurs 386) ou ce pourrait être une coïncidence et qu'il y ait eu deux bugs de réveil de l'état de faible consommation liés à cette instruction.
Dmitry
Points
61
J'en ai rencontrée une !
Mon premier ordinateur était un Iskra EVM soviétique (essentiellement un IBM PC/XT avec son propre bus du Rideau de fer, mais entièrement compatible logiciellement). Parfois, il se figeait, produisant parfois des anomalies à l'écran. Après une enquête plus approfondie, j'ai découvert :
-
Le système avait un processeur Siemens SAB 8086 fonctionnant à 8 Mhz.
-
Le coupable était l'instruction HLT (0xF4) qui faisait planter le système indépendamment de la désactivation ou de l'activation des interruptions.
Une simple séquence, comme 0xFA, 0xF4, 0xC3 (cli, hlt, ret) ne faisait PAS planter le système de manière élégante, comme on pouvait s'y attendre, produisant plutôt des anomalies à l'écran, puis se figeant.
La séquence similaire 0xFB, 0xF4, 0xC3 (sti, hlt, ret) n'exécutait pas simplement en silence et ne revenait pas à la ligne de commande, encore une fois - anomalies à l'écran, et soit un gel, soit (rarement) - retour à la ligne de commande.
Juste le 0xF4, 0xC3 (normalement les interruptions sont activées, de toute façon) - mêmes anomalies, des bips et un gel.
Je n'ai jamais compris où le contrôle était transféré, j'aurais pu écrire un chargeur d'amorçage qui remplit la mémoire avec des hooks (0xCC), puis le gestionnaire INT 03h m'aurait dit d'où il venait. Mais à l'époque, je n'y ai jamais pensé. Ou peut-être que ce n'était pas juste un transfert de contrôle, mais une corruption quelque part, qui sait ? Je n'ai jamais entendu parler de l'instruction HLT buguée sur les processeurs Siemens, mais cela pourrait être le cas. Je ne veux pas généraliser, cela pourrait bien être juste CE CAS, ou peut-être un lot défectueux.
Eh bien, pour finir l'histoire - à l'époque, j'ai trouvé une autre machine du même modèle, mais celle qui avait la pierre soviétique à l'intérieur (le KM1810VM86M - le processeur Intel 8086 fidèlement volé (emprunté) et ensuite reproduit). J'ai essayé de jouer avec l'instruction HLT là-bas, et ELLE A FONCTIONNÉ comme elle aurait dû, et comme le Référentiel du programmeur Intel 8086 le dit...
Quelle ironie... et quelle histoire ! :)
