Le noyau Linux se bloque à «Basculer vers tscource source» sur Pentium 4

11

Matériel: Dell Dimension 4500S : i845G, Pentium 4, stock + 2 Go de RAM et dernière mise à jour du BIOS (vers 2002).

J'ai construit un système Linux à partir des sources, jusqu'à présent c'est LFS 7.0 par le livre. Le premier noyau que j'ai construit fonctionne bien, mais a beaucoup de peluches et de ballonnements, donc j'optimise maintenant le noyau pour mon matériel cible (voir ci-dessus).

Ma dernière tentative de configuration, et plusieurs variantes d'essais et d'erreurs, ont été continuellement suspendues à l'instruction printk "Passage à clocksource tsc". Mon "bon" noyau n'a jamais eu de problème ... c'est la version 3.1.0 btw. Les deux sont construits à partir du même arbre source, pas de taches, make mrproper, make menuconfig, etc, donc évidemment je manque juste une clé CONFIG_XXXdrapeau.

Je regarde ce problème depuis plus d'une journée maintenant, et j'ai construit le noyau qui sait combien de fois, mais en vain.

Une chose que je trouve intéressante est avec le bon noyau que je reçois:

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

aussi, il pourrait être utile de savoir ....

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc acpi_pm

J'ai essayé la configuration de construction avec diverses options, mais à ce stade, je ne me souviens pas de détails, alors ne demandez pas. De ma recherche, j'ai trouvé et testé plusieurs paramètres du noyau, comme clocksource=pitet notsc, mais tous échouent également. Encore une fois, j'aurais aimé avoir écrit tout ce que j'ai essayé jusqu'à présent, avec le recul ...

La plupart des exemples de forum sont pour les noyaux 2.x et ont été résolus avec une certaine variation des options de démarrage, mais mon bon noyau utilise uniquement root=/dev/sdaX ro. Je sais donc que je suis en or avec cette combinaison matériel et noyau 3.1.0 si je peux trouver la bonne configuration de construction.

De plus, la plupart des gens qui ont publié un problème similaire disent qu'après quelques minutes, le système continuera de se charger et que tout est pêche. Je l'ai laissé inactif assez longtemps pour cuisiner le souper et il n'a toujours pas repris le chargement.

J'espère que l'un de vous gourou lira ceci et dira "hé ouais je viens de configurer CONFIG_XXX = y sur mon dinosaure P4 et cela a très bien fonctionné." :)

Faites-moi savoir ce dont vous avez besoin pour essayer ou vérifier, je serai heureux de publier les résultats.

linux linux-kernel

— rfmodulator
source

@tripleee Où puis-je voir ces informations ... la raison d'un vote serré?

— rfmodulator

Peut-être que vous ne pouvez pas, votre réputation peut ne pas suffire. Quoi qu'il en soit, puisque ce n'est pas lié à la programmation, il est logique de bouger, mais il suffit de quelques votes plus serrés. J'ajouterai le mien aussi.

— tripleee

Je rencontre des problèmes similaires avec le nouveau noyau avec Pentium 4. Tout fonctionne si je désactive l'hyperthreading. J'ai passé deux nuits à déboguer, je ne suis pas encore sûr des détails.

— choroba

@choroba nohtne le fait pas pour moi. Faites-moi savoir si vous avez d'autres idées.

— rfmodulator

En fait, j'ai dû désactiver ht au niveau du BIOS, ou spécifier acpi=off.

— choroba

8

À partir d'une recherche rapide, ce problème semble avoir de nombreuses raisons possibles, et semble indiquer que la valeur par défaut de votre nouveau noyau pour la source d'horloge est incorrecte pour votre carte mère.

Un conseil qui a fonctionné pour certains était d'utiliser clocksource=hpetou clocksource=acpi_pm.

Dans un autre thread , quelqu'un a corrigé ce problème clocksource=jiffies, un autre a conseillé d'essayer noapicou nolapicun autre de désactiver l'acpi dans le BIOS, et un autre a blâmé le pavé tactile Synaptics et a résolu son problème en supprimant Xorg.conf.

Un constructeur de noyau a résolu son problème en recompilant initrd sans fbcondecor.

J'espère que cela vous aidera, car il semble que ce problème puisse avoir de nombreuses causes.

— harrymc
source

Merci pour votre réponse, cependant je cherche des options de configuration de construction de noyau qui causeront (ou empêcheront) le blocage au démarrage que j'observe, pas un travail. J'ai essayé tous les paramètres de démarrage relavent ( clocksource=, no*, etc.) qui ont été notés dans divers fils de discussion, sans aucun effet. J'ai fait ces expriments pour tenter de réduire mon vrai problème. J'ai déjà un noyau qui démarre parfaitement sans aucun paramètre spécial (à part root=et ro) construit à partir de la même arborescence source, mais ce noyau contient plus de choses dont je n'ai pas besoin, que celles que je fais ...

— rfmodulator

... sauf cet CONFIG_indicateur clé qui résoudra mon problème.

— rfmodulator

Est-il possible que votre problème soit que vous ayez désactivé trop d'options de noyau?

— harrymc

Précisément. :) C'est la réponse que je cherche, qu'est-ce que j'ai désactivé qui est réellement nécessaire. Je l'ai fait plusieurs fois sans changer le résultat.

— rfmodulator

Je ne peux pas t'aider avec un mot magique. Il semble que votre source d'horloge actuelle soit acpi_pm, mais vous devrez vous plonger dans les sources du noyau pour découvrir avec la configuration du noyau que vous avez ratée. L'autre option consiste à revenir à la configuration qui a fonctionné et à désactiver les options par incréments afin de localiser le problème. Pour vous «remonter le moral», je peux également dire que cela pourrait ne pas être une option mais plusieurs, ce qui signifie un conflit ou une combinaison de configuration non viable ou une dépendance non documentée.

— harrymc

0

J'ai eu exactement le même problème ici et j'ai lu BEAUCOUP. @harrymc a fait un assez bon résumé.

Je vais juste ajouter 2 choses que j'ai apprises de mes recherches:

Le problème vient de votre noyau Linux qui ne sait pas comment gérer votre processeur car il ne sait pas quelle est votre horloge de traitement. Vous pouvez observer cela en consultant le journal de démarrage du noyau. Il semble que le noyau essaie de mesurer votre horloge de traitement (pour moi, c'était comme "2997.1333" mais chaque démarrage change en "2997.1445", "2997.1379", ...).
Après avoir essayé beaucoup de choses, je suis finalement arrivé ici et j'ai découvert le BIOS. Le mien est GYGABITE UEFI. J'ai remis les paramètres à "Paramètres par défaut optimisés" et défini "Intel Virtualization Technology" sur "activé".

Maintenant, tout est revenu à la normale pour moi! Espère que cela aide.

— MaximeBernard
source

0

À quelques centimes de moi, je ne sais pas si c'est une chose courante ou non, mais j'ai réussi à faire fonctionner Ubuntu en désactivant le `` temporisateur de haute précision '' dans le BIOS. Mon mb est gigaoctet z77x-d3h

— Oxy
source

Le système de l'OP ne prend pas en charge la minuterie d'événement haute précision. Cela a été introduit en 2005, et le système de l'affiche originale est antérieur de plusieurs années.

— ChrisInEdmonton

-2

J'ai résolu le problème en ajoutant le paramètre de noyau suivant:

noapic

— Kiroe
source

5

Bienvenue dans Super User. Pouvez-vous développer votre réponse en expliquant ce que cela fait / comment cela résout le problème du PO?

— Je dis Réintégrer Monica le

aucun sry, juste joué avec les paramètres du noyau.

— Kiroe