En rapport avec des journaux récents sur le prochain noyau:
http://linuxfr.org/~quzqo/7179.html(...)
http://linuxfr.org/~ngc891/7203.html(...)
Un thread de la lkml met le doigt où ça gratouille:
http://testing.lkml.org/slashdot.php?mid=433931(...)
En gros, à la question "Le kernel sera-t-il stable d'ici un mois, pour sa sortie", la réponse est "non, mais c'est normal, cf noyau 2.4". Larry McVoy dit même que le 2.6.0 ne servira pas à grand chose. Il faudra attendre plusieurs mois pour avoir quelque chose d'exploitable.
Je ne sais pas ce que vous en pensez, mais moi ça me fait un peu mal. Je me souviens d'avoir attendu le 2.4.18 pour faire marcher correctement ma webcam , qui n'a rien d'exotique par ailleurs, alors que ce noyau était estampillé "support USB".
Je préférerais sincèrement que la sortie du 2.6.0 soit repoussée de plusieurs mois afin d'offrir un niveau de finition supérieur à la série 2.4. Après tout, si certaines personnes sont pressées, elles peuvent utiliser les versions de test.
J'ai hâte de voir l'intervention de Linus dans ce thread (il semble hors-ligne depuis quelque temps)
Journal Le kernel 2.6.0 stable, c'est pas pour demain
29
nov.
2003
# Re: Le kernel 2.6.0 stable, c'est pas pour demain
Posté par Moby-Dik . Évalué à 8.
Il y a trop de variabilité dans les configs de PC actuellement (notamment avec tout le bordel des machins USB, bidules wi-fi & co) pour espérer avoir un noyau stable dès la première version. Microsoft permet aux drivers d'être livrés sous forme de binaires indépendants de la version du noyau, ce qui résoud le problème pour eux (ils sortent l'OS d'abord et les constructeurs s'occupent des errata dans leur coin). Linux n'a pas fait ce choix (notamment pour que la GPL ne perde pas de sa force dans le cadre du noyau), et doit gérer la cohérence et la stabilité des drivers à l'intérieur du noyau lui-même.
[^] # Re: Le kernel 2.6.0 stable, c'est pas pour demain
Posté par Jérôme Pinot (site web personnel) . Évalué à 2.
http://lkml.org/lkml/2003/11/27/107(...)
Ça fait peur. Surtout que les bugzillas en question datent du -test4
C'est un problème de base du système qui est loin d'être évident. Il y a eu d'autres rapport de bugs sur des corruptions de mémoire, plus ou moins aléatoires et plus ou moins reliées à CONFIG_PREEMPT.
On ne parle pas de drivers et/ou code annexe, mais bien du core. Le 2.6.0-test est quasi-inexploitable chez moi, même en virant toutes les options.
[^] # Re: Le kernel 2.6.0 stable, c'est pas pour demain
Posté par Jak . Évalué à 2.
[^] # Re: Le kernel 2.6.0 stable, c'est pas pour demain
Posté par Jérôme Pinot (site web personnel) . Évalué à 4.
Le problème est bien plus ancien (-test4) mais il n'apparait sur ma bécane que maintenant, ce n'est donc pas le passage -test9 -test10 qui est en cause. C'est juste un catalyseur. C'est pour ça que c'est assez grave: c'est une mise en lumière d'un défaut de base.
Je t'incite fortement à tester le -test11. Peu importe la config (mais avec PREEMPT, c'est plus facilement reproductible), pour le tester essaie juste de recompiler un noyau 2.6 avec pas mal d'option pour mettre ta bécane en charge. Chez moi, ça plante systematiquement à la première compilation.
Tu peux réessayer 2 ou 3 fois à la suite pour être sur.
J'ai même reproduit le oops avec un tout petit noyau de 700Ko, c'est indépendant d'à peu près tout, même l'architecture: les gars d'IBM avait reproduit le truc sur ppc64. Tout ce qu'on sait, c'est que l'endroit où ça plante (slab.c) n'est pas en cause. Il y a juste un bit d'erreur en mémoire.
Et personne ne sait comment résoudre ce oops.
[^] # Re: Le kernel 2.6.0 stable, c'est pas pour demain
Posté par mickabouille . Évalué à 2.
Et je n'ai ni plus ni moins de plantages qu'avant (nvidia oblige).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.