bonjour tout le monde,
Ayant un ordi vieillissant (ça doit bien plus de 5 ans que je l'utilise), j'ai décidé de le fourguer à mes parents et de m'acheter une nouvelle bécane. Voulant leur mettre un linux, mon choix s'est dans un premier temps orienté vers une ubuntu.
j'installe l'OS, je le blinde de logiciels et je teste le tout pendant un certain temps pour voir si l'usage en reste simple pour les Lucette & Henri moyens.
Je suis moyennement satisfait (ceci pourrait faire l'objet d'un journal, mais j'attends vendredi), mais surtout, je m'aperçois avec horreur que mes lecteurs cd partent en live au bout de quelques minutes (et pourtant, j'ai pu installer la distrib depuis le cd).
l'ordi est dès lors inutilisable.
Je me rabat alors vers une Zenwalk, plus proche de ma philosophie. Y'a pas photos, l'empreinte mémoire est incomparable. Mais hélas, même souci avec les lecteur cd.
Ayant dans un premier temps incriminé HAL, je m'aperçois que le problème viendrait plutôt de la libATA introduite à partir du noyau 2.6.19 (et en effet ma vieille slackware tournait parfaitement bien auparavant). Je tope donc les sources du 2.6.17 d'une vieille version de zenwalk et je me compile mon noyau aux petits oignons, entre autre pour pouvoir installer le driver nvidia, qui veut la même versions de gcc que celle qui a compilé le noyau. Et là tout va mieux, les lecteurs cd fonctionnent, sauf que, et là j'en viens à ce qui m'amène devant vous, l'ordi freeze systématiquement au bout de 70 minutes précises (un petit watch uptime me le montre bien). Affichage gelé, le son bloqué sur une boucle d'une seconde, etc... Ce qui rend l'ordi tout aussi inutilisable, vous en conviendrez.
Que se passe-t-il ? cela doit sans doute venir de mes options de compilation puisque les binaires 2.6.22 et 2.6.17 initiaux ne plantaient pas. J'ai pisté les processus, mais je n'ai rien vu, à moins que top n'ai pas le temps d'afficher le processus qui plante. Rien non plus dans les logs.
Cette précision (au bout de 70 mn exactement) me trouble... Avez-vous une idée de ce qui pourrait provoquer ce plantage? cela provient-il bien du noyau ?
Forum général.cherche-logiciel mon système se blo
21
nov.
2007
# précision
Posté par ianux (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: précision
Posté par jlh . Évalué à 2.
70 min ~= 2^32 microsecondes (ou un problème de compilateur).
Je n'ai pas de solution particulière si ce n'est d'essayer avec un kernel plus récent ou une autre version du compilateur.
# comparer les options des kernel
Posté par argt (site web personnel) . Évalué à 1.
La dernière fois, pour trouver l'option foireuse, j'ai fait un diff sur les .config des 2 versions et j'ai ensuite commencer à vérifier les options (j'ai commencé par les options qui me semblait en rapport avec le problème, en mettant des flags sur les lignes des options vérifiées, bref, il faut etre organisé), je recompilais sur un ordi récent avec la meme architecture pour gagner du temps.
C'est long, pas très rigolo et c'est du bricolage.
Mais vu que le nombre d'option est fini, l'algorithme termine.
[^] # Re: comparer les options des kernel
Posté par totof2000 . Évalué à 3.
J'ai jamais eu de probème avec NEtBSD lorsque j'ai changé de version de noyau ... :D
Au delà du troll, je sais que sous NetBSD il existe un script (perl je crois) qui permet de générer un fichier de configuration de noyau à partir de la config hardware ... Ca n'existe pas ça sous Linux ? Ca me serait assez utile, je dois installer linux sur une petite machine, et je voudrais gagner un peu de place ...
# résolu!
Posté par ianux (site web personnel, Mastodon) . Évalué à 1.
blague à part, j'ai recompilé mon noyau en changeant des trucs et des machins (je sais pas lesquels, je me souviens juste que j'ai rajouté le support RTC), et tout a l'air d'aller mieux...
c'est cool, zenwalk ça roxor, idéal pour les petites configs
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.