Sortie du noyau Linux 2.6.13

Posté par  (site web personnel) . Modéré par Jaimé Ragnagna.
Étiquettes :
0
29
août
2005
Noyau
Linus Torvalds vient d'annoncer la sortie de la version 2.6.13 du noyau Linux qui est au coeur de toutes les distributions GNU/Linux. Le cycle de test a été particulièrement long puisqu'il n'a pas fallu moins de sept versions de déverminage (RC ou Release Candidate).

Parmi les nouveautés, on remarquera les points suivants :
  • l'inclusion de l'architecture microprocesseur Xtensa pour l'embarqué
  • Inotify qui remplace Dnotify pour surveiller en temps réel les événements concernant le système de fichiers
  • Kexec qui permet lors d'un crash système de charger un nouveau noyau et de démarrer dessus rapidement sans passer par le BIOS
  • Kdump qui facilite l'examen d'un noyau défaillant
  • l'horloge d'interruption (Timer interrupt) est désormais configurable et passe par défaut à 250 Hz au lieu de 1000 Hz pour l'architecture i386
  • CFQ, l'ordonnanceur d'entrées-sorties (IO scheduler) souvent utilisé par défaut dans les distributions, est grandement amélioré avec sa version 3 et supporte maintenant la gestion des priorités
  • les processeurs de type i386 utilisent désormais le code générique de configuration du bus PCI pour découvrir les ressources éventuelles qui n'auraient pas été configurées par le BIOS
  • etc.

NdM : merci à YodaBZH pour avoir également proposé une dépêche à ce sujet. Comme annoncé lors du dernier sommet Linux le mode de développement du noyau est maintenant modifié afin de permettre des sorties de versions plus rapides et plus fiables. Les grands changements dans le code se font maintenant uniquement dans les deux semaines suivants la sortie d'une version et le reste du temps est consacré à la correction des bugs et aux tests.

Aller plus loin

  • # Changements

    Posté par  (site web personnel) . Évalué à 10.

    J'ai fait une liste complete des changements entre le 2.6.12 et le 2.6.13. C'est assez impressionnant le nombre de modifications qu'il y a eu:

    ftp://ngc891.blogdns.net/pub/linux/misc/ChangeLog-2.6.12-2.6.13.tx(...)

    Attention, le fichier fait environ 3,7Mo. Linus a poste egalement un ChangeLog plus leger et des explications detaillees pour les faire soi-meme avec git:

    http://lkml.org/lkml/2005/8/28/94(...)

    Ca suppose bien sur d'avoir une copie locale des sources en developpement, voir la doc de Jeff Garzik:

    http://lkml.org/lkml/2005/5/26/11(...)

    • [^] # Re: Changements

      Posté par  . Évalué à 3.

      Est ce que qqn serait capable de décoder ou au moins de fournir un lien vers une doc le permettant sur les Changelog c quoi tt ces codes??

      • [^] # Re: Changements

        Posté par  . Évalué à 9.

        D'après ce que j'ai compris :

        Les gros trucs hexadecimaux, c'est des hash qui servent d'identifiants dans git.

        Pour chaque patch mergé dans un arbre git, git calcule ce gros hash sur le contenu du patch. Vu la taille du hash et l'algo de calcul utilisé, il est tres peu probable que deux patchs aient le meme hash. Ca permet donc d'identifier rapidement tous les patchs, meme si ca n'est pas tres intuitif.

        Les différentes revisions de l'arbre git en entier sont aussi identifiées par des hash du même genre.
        Ainsi, chaque commit peut être caracterisé par le hash du patch associé, ou le hash de l'arbre avant et apres le commit.
        Apparemment, chaque commit est aussi associé aux hash de chaque fichier avant et apres le commit.

  • # Commentaire supprimé

    Posté par  . Évalué à 8.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Et le Cell?

      Posté par  . Évalué à 10.

      C'est beau beau de vouloir adapter le noyau au Cell, mais il va falloir commencer par le compilateur ... hop hop, gcc, on y va !

      • [^] # Re: Et le Cell?

        Posté par  . Évalué à 6.

        Des patchs rajoutant le support du cell sont deja disponible (voir la mailling list ppc devel). Ils sont realises par IBM et s'ils ne sont pas encore incorpores j'imagine que c'est parcequ'ils estiment que ce support n'est pas encore finis et de plus seul les labos d'ibm et autres fabricant du cell doivent posseder le materiel donc il ne sert a rien de presser son inclusion dans le noyau officiel.

        On peut toujours jeter un coup d'oeil au code (personellement je n'en ai pas eu le temps)...

        • [^] # Re: Et le Cell?

          Posté par  . Évalué à 5.

          Je crois que c'est déjà incorporé dans 2.6.13 dans arch/pp64/bpa_* via l'option de config CONFIG_PPC_BPA,non ?
          Le ChangeLog de 2.6.13 contient plusieurs entrées parlant de Cell.

          Et un post récent sur LKML
          http://lkml.org/lkml/2005/8/31/296(...)
          propose de bouger ces fichiers dans arch/powerpc/platforms/cell et de changer l'option de config en CONFIG_PPC_CELL car l'ancienne dénomination BPA (Broadband Processor Architecture) doit être remplacée par Cell.

    • [^] # Re: Et le Cell?

      Posté par  . Évalué à 4.

      Oui et un Cell c'est quoi ?

    • [^] # Re: Et le Cell?

      Posté par  . Évalué à 10.

      Ils ont p'tet décidé de laisser le codage du Cell aux fans...

      ==>[]

      • [^] # Re: Et le Cell?

        Posté par  (site web personnel) . Évalué à 8.

        Certains cherchent la route vers le futur : Coup de chance, le Cell y mène...

        • [^] # Re: Et le Cell?

          Posté par  (site web personnel) . Évalué à -3.

          *toulouloulouloute* Cell, Cell, Cell, Cell y mène *toulouloulouloute* Cell, Cell, Cell, Cell y mène ...

          ca va, ca va pousser pas

          PS: pour ceux qui ont pas compris, la compagnie creole toussa

          • [^] # Re: Et le Cell?

            Posté par  . Évalué à -3.

            C'est pas David Martial plutôt Célimène ?

            M'enfin La Compagnie Créole a du faire une reprise...

        • [^] # Re: Et le Cell?

          Posté par  . Évalué à 9.

          Et puis tu sais comment faire marrer une PS3 ?
          for (compteur=0; true; compteur++), parce que quand le Cell est comptant, le Cell rie.

          Et puis tu connais le comble du geek tennisman ?
          Amener sa PS3 à Roland Garros, parce que le Cell y bat terre.

          Et tu sais ce que dit le gaimeur à sa PS3 quand il a battu le super boss de fin ?
          « Cell, u loose!»


          Oulala, j'ai honte...

          • [^] # Re: Et le Cell?

            Posté par  (site web personnel) . Évalué à -2.

            je pertinente : la dernière phrase l'est :)

          • [^] # Re: Et le Cell?

            Posté par  . Évalué à 0.

            J'vais rajouter mon grain de Cell 0:-)

            Si je ne me gourre pas, ce n'est que le processeur ... il reste le support du reste du hardware à coder ...

            bref, on verra quand ça sortira :)

          • [^] # Re: Et le Cell?

            Posté par  . Évalué à 3.

            On va pouvoir graisser sur l'Anglais après ce superbe contournement de troll sur le Cell : on dit pas "loose" mais "lose" ou plutot on n'écrit pas "loose" mais "lose" et on dit "loose".

      • [^] # Re: Et le Cell?

        Posté par  . Évalué à 6.

        Un anglophone m'a dit l'autre jour qu'il adorait utiliser les Cell qui sont déjà dispo dans une des villes de Lineage II :

        « I love Cell in Dion »

      • [^] # Re: Et le Cell?

        Posté par  . Évalué à 2.

        Il y a des programmeuses qui ont déjà la version 'U-lite'...

        OK, ~~~~~-->[]

    • [^] # Re: Et le Cell?

      Posté par  . Évalué à 10.

      Moi je vais tous les jours a la Cell


      désolé

      • [^] # Re: Et le Cell?

        Posté par  (site web personnel) . Évalué à 7.

        C'est pertinent, mais ça mérite une baffe : Cell, la baffe que j'préfère, Cell, la baffe !

        Ok, je pars en courant --->[ ]

        • [^] # Re: Et le Cell?

          Posté par  (site web personnel) . Évalué à 4.

          Mais IBM ne veut pas utilise le processeur Cell dans les walkmans ou dans ce genre là, car ne dit on pas : Cell à Watt
          ^_^

          bon ok, /me se sauve en zigzag ~~~~~~~~~~~~> [ ]

          • [^] # Re: Et le Cell?

            Posté par  . Évalué à 4.

            Ouais, c'est un processeur un pur dur avec les piles, mais c'est comme ça. Dura Cell, etc.

            • [^] # Re: Et le Cell?

              Posté par  (site web personnel) . Évalué à 7.

              La pile Duracell est par ailleurs l'amie privilègiée de ceux et celles qui compensent leur vide affectif à l'aide de jouets électriques:

              Duracell, l'aide sexe

            • [^] # Re: Et le Cell?

              Posté par  . Évalué à 8.

              Oui, car quand l'Intel pleure, le Cell rit !

  • # RC != deverminage

    Posté par  (site web personnel) . Évalué à 10.

    Je suis surpris de voir les versions RC (candidats de sortie) associes dans la nouvelle avec la notion de deverminage.

    Les RC, etant des candidats finaux, ne servent pas a deboguer mais a tester que tout marche, ce qui n'est pas du dout a mon sens la meme demarche. Apres, il peut y avoir des vermines [1] dans une version, qui doivent evidemment etre corrigees mais ce sont en theorie de vermines mineures.

    La phase de deverminage a lieu normalement pendant le developpement de nouvelles fonctionnalites, c'est a dire bien en amont de la phase des RC.

    [1] : j'avoue que j'ai quand meme du mal a ne pas appeler ca un "bug".

    • [^] # Re: RC != deverminage

      Posté par  . Évalué à 8.

      En effet, mais Linux préfère appeler tous ces versions "rc" au lieu de "pre" puis "rc" comme avant.
      Il ne faut plus parler de "rc" pour "release candidate".
      "ridiculous counter" a par exemple été proposé à la place.

      • [^] # Re: RC != deverminage

        Posté par  (site web personnel) . Évalué à 3.

        Tout ça pour éviter le 2.7...

      • [^] # Re: RC != deverminage

        Posté par  . Évalué à 3.

        En effet, mais Linux préfère appeler (...)

        tu voulais dire 'Linus' je suppose...

        d'autre part, les nouveautés sont censées être testées dans les branches de test (d'Andrew Morton, Andrea Arcangeli...) donc elles entrent effectivement en phase 'rc' quand elles sont inclues dans la branche principale.

      • [^] # Re: RC != deverminage

        Posté par  (site web personnel) . Évalué à 7.

        Bon, on en revient a ma conviction premiere, a savoir que Linus, malgre toutes ses qualites, ne sait pas gerer un systeme de versionnage lisible et propre.

        Pour comprendre ce que j'appelle lisible et propre, il suffit de regarder la facon dont fonctionne KDE ou Mozilla. Il n'y a pas 24 numero de versions, et les versions en dev s'appellent beta, alpha ou autre, les versions super stables ont un no de release unique, et les versions presque stables avant la release sont notes RC.

        On peut suggerer a Linus que les versions dont les 4 chiffres sont multiples d'un meme nombre premier sont stables, celles ou la sommes des 4 chiffres est divisible par 7 sont des release candidate, et les autres sont instables. Ca me paraitrait a peu pres aussi lisible que le systeme actuel.

        • [^] # Re: RC != deverminage

          Posté par  (site web personnel) . Évalué à 6.

          les versions dont les 4 chiffres sont multiples d'un meme nombre premier sont stables, celles ou la sommes des 4 chiffres est divisible par 7 sont des release candidate

          Oui mais non, ça ne fonctionne pas, parce que le 2.6.8 serait une release canditate et stable à la fois :p


          Je préfères le système de Linus. C'est peut être pas plus lisible, mais c'est plus propre (au sens où il n'y a pas de collisions) :)

          • [^] # Re: RC != deverminage

            Posté par  . Évalué à 4.

            2+6+8 = 16
            Or 2*7 = 14 ; 3*7 = 21
            Donc 16 = 2*7 + 2
            Conclusion : le 2.6.8 n'est pas une release candidate et stable en même temps.

            • [^] # Re: RC != deverminage

              Posté par  (site web personnel) . Évalué à 4.

              Ah oui :)

              Ne soit pas si pointilleux ! :p

              Je voulais dire 2.4.8, mais j'avais peur que ce soit pas assez bleeding edge :)
              Il fallait bien sûr comprendre 2.6.6 :) (ou 2.6.20 pour le prochain).


              Pardon aux familles, toussa.

        • [^] # Re: RC != deverminage

          Posté par  . Évalué à 0.

          On peut suggerer a Linus que les versions dont les 4 chiffres sont multiples d'un meme nombre premier sont stables, celles ou la sommes des 4 chiffres est divisible par 7 sont des release candidate, et les autres sont instables. Ca me paraitrait a peu pres aussi lisible que le systeme actuel.


          Super, on va devenir super fort au buzz de 7 et multiple d'un nombre premier.

          Par contre, je recherche une prof pour le buzz de 7 et de 3.

    • [^] # Re: RC != deverminage

      Posté par  . Évalué à 9.

      Avec le noyau Linux, les RC c'est tout ce qui se passe après les deux premières semaines de développement acharné d'une nouvelle version. Ça va clairement de l'alpha à la vraie "release candidate", et les premières -rc sortent avec entre autre du code testé de façon anecdotique, voire des problèmes connus. Il est donc très improbable qu'on voit un jour un 2.6.X-rc1 aboutir au 2.6.X directement (alors que dans pas mal d'autres projet c'est l'objectif en général quand cette dénomination est utilisée). Linus a d'ailleurs expliqué maintes fois qu'il s'en foutait pas mal des distinctions (bien subjectives) entre alpha, beta et RC, et que donc il appellerait tout pareil pour ne pas avoir à y réfléchir.

      • [^] # Re: RC != deverminage

        Posté par  (site web personnel) . Évalué à 3.

        ...et que donc il appellerait tout pareil pour ne pas avoir à y réfléchir


        Ben oui, c'est Linus, hein...

      • [^] # Re: RC != deverminage

        Posté par  (site web personnel) . Évalué à 3.

        Je sais qu'il y a eu des changements ...
        Le noyau 2.6.13 est il stable ou faut il attendre le 2.6.14 ?
        Tant qu'on est dans la branche 2.6 on est stable ?

        • [^] # Re: RC != deverminage

          Posté par  . Évalué à 3.

          2.6.13 et la branche 2.6 sont considérés comme stable, en particulier avec les 2.6.13.x qui suivront pour fixer qqs bugs.
          L'idée des noyaux impairs instables a été abandonnée.

          • [^] # Re: RC != deverminage

            Posté par  (site web personnel) . Évalué à 1.

            Non. Le deuxième nombre, si il est impair indique un noyau instable. (2.3, 2.5). Le troisieme n'indique qu'un numéro de version.

            Quelqu'un a le lien sur la politique de versionnage GNU ? il y en a une il me semble qui indique tout cela.

            • [^] # Re: RC != deverminage

              Posté par  . Évalué à 3.

              Non, on ne parle pas du deuxieme mais du troisieme nombre.
              Linus avait proposé il y a qqs mois que 2.6. soit stable alors que
              2.6. serait instable.
              Ca a été abandonné, tous les 2.6 pair et impair sont considérés comme stable.

              • [^] # Re: RC != deverminage

                Posté par  . Évalué à 2.

                oops probleme de mise en forme

                linus avait proposé :
                2.6.pair = stable
                2.6.impair = instable

    • [^] # deverminage

      Posté par  . Évalué à 10.

      [1] : j'avoue que j'ai quand meme du mal a ne pas appeler ca un "bug".

      Je voudrais juste rebondir aussi un peu la dessus. Je ne suis pas du tout fan de la Francisation à outrance, si une chose à trouvé appelation via un mot Anglais alors pourquoi necessairement le Franciser, l'important étant que chacun sache de quoi l'on parle. Commencer à Franciser absolument un terme ne témoigne généralement que d'un sursaut d'orgueil inutile.

      Je pense, de surcrois que le mot deverminage n'est pas du tout adapté. Je n'ai compris son sens dans la phrase qu'après avoir fait une analogie avec le mot bug (ah en fait vermine est l'appelation Française de bug). Car, dans un dictionnaire :

      Vermine :
      1. Ensemble des insectes parasites de l'homme et des animaux
      2. Péjoratif, ensemble d'individus jugés vils, inutiles ou néfastes.

      Ce qui ne correspond pas du tout à l'appelation bug du language informatique, un bug, même s'il est parasite, n'est pas un bout de code vil, nefaste ou inutile, mais plutôt une erreur de code (ou un effet secondaire).

      Le terme bug à un sens totalement différent, en France dans l'univers informatique, qu'il avait à l'origine (insecte). C'est justement l'utilisation du terme dans un contexte informatique qui en a déformé le sens. Si l'on retourne en arrière en appliquant spécifiquement un terme Français à l'informatique, c'est tout un apprentissage qui sera necessaire et surtout on va se retrouver avec un terme qui aura plusieurs sens, sans forcèment qu'ils soient lié (le sens vermine est trop fort, à mon avis, pour la description Francisé d'un bug).

      Juste un avis en passant :-)

      • [^] # Re: deverminage

        Posté par  . Évalué à 3.

        mais quand tu francise bug en vermine (qui a quand meme un sens) ou bogue (qui n'en a aucun) y'a pas une des deux versions qui te parrait plus logique que l'autre (et plus marrante surtout)

        comme ca après tu traduit bug squashing parti par la fete de la chaasse à la vermine... et le sens est conservé

      • [^] # Re: deverminage

        Posté par  (site web personnel) . Évalué à 5.

        Sans compter que le terme déverminage réfère à un procédé industriel qui n'a rien à voir avec l'amélioration ou la réparation, comme c'est le cas des bugfixes : c'est un procédé de _destruction sélective_ des éléments non conformes.

        Donc déverminer un kernel, ça veut dire en faire exploser les parties qui correspondent pas au spécs. Je suis pas sûr que faire sauter toute la gestion du système de fichiers ext3 à cause d'un bug dans ce code soit une démarche très utile :)

        Version de test : ok
        Préversion : ok
        Version de déverminage : ça ira merci j'aime mon kernel entier

        • [^] # Re: deverminage

          Posté par  . Évalué à 3.

          oui mais bon, il y a bien longtemps quand les ordinateur n'etais que relais, cela degagé beaucoup de chaleur. Les cafards, voir la vermine causaient des disfonctionnement. Il etait commun alors de parler de bug (sous entendu la bete a fait declenché un mauvais relais)

          si la france avait été precurseur (dans quoique ce soit d'ailleur :) ) dans l'informatique cela serait appelé vermine ou cafard.

          tiens prend un autre petit jaune

          • [^] # Re: deverminage

            Posté par  (site web personnel) . Évalué à 5.

            Je me demande si l'appellation bug n'est pas plus ancienne encore. Je me souviens d'un bugs bunny ou on voit un vilant "bug" essayer de faire exploser des bombes d'avions militaires. Il me semble du coup que c'est lie a une legende, de petits etres qui viendraient foutre la merde dans un truc cense marcher parfaitement.

            Ce que confirme au moins partiellement wikipedia:
            http://en.wikipedia.org/wiki/Computer_bug(...)

            • [^] # Re: deverminage

              Posté par  . Évalué à 7.

              c'est lie a une legende, de petits etres qui viendraient foutre la merde dans un truc cense marcher parfaitement.


              Erreur, grave erreur !!

              En fait d'une légende cartoonesque, c'est en réalité un phénomène qui précéde un peu ce qu'on coutume d'appeler (traduction directe et peu trompeuse), les "urban legends" ou les "hoaxes".

              Il y a eu toute une série de "racontars", "histoires de bonnes femmes" à l'époque pré-industrielle aux Etats-Unis d'Amérique (très exactement entre la 1ere Révolution Industrielle (vapeur) et la 2eme RI (electricité)) pour déconsiderer la mécanisation et globalement le progrès technique, que les ouvriers des manufactures ont intuitivement perçu comme des sources de sous-emploi.

              Sur les RI, premier choix Google pour les oublieux :
              http://membres.lycos.fr/bleu/revolution_industrielle.htm(...)

              Idéologiquement, ces manoeuvres (dans un vocabulaire actuel, on évoquerait une "intoxication") auraient en réalité été en corrélation forte avec les mouvements Luddites (mais pas de théorie du complot : les mouvements Luddites sont restés cantonnés en Grande-Bretagne alors que le phènomène que j'évoque est strictement Nord Américain).

              http://en.wikipedia.org/wiki/Luddism(...)

              Un jour de désoeuvrement, j'avais lu ça dans une publication canadienne francophone, j'avais mêmepris des notes (oui, à la BU de Valrose, il y a des Bandes Dessinées mais aussi des trucs encore plus folkloriques ;); ils s'interrogeaient justement sur une résurgence du phènoméne à l'occasion de la troisième révolution industrielle informatique lié avec un formidable outil de propagation des rumeurs, "L'Internet" (sic) puisqu'on était en pleine bulle....

              L'étude candienne reprenait les travaux du Professeur Joseph W. Dante (Senior Lecturer in ethno-psychology ou approchant) de la Christophus Colombus University, qui pensait que si la contestation des machines avait pris en Amérique du Nord une dimension aussi folklorique, voire infantile, c'était largement du à l'atomicité du monde ouvrier (grandes distances entre centre de productions, communications chères et difficile) et à une structuration politique et syndicale bien plus faible qu'en Angleterre.

              www.ccolombus-univ.edu/dept/anthsci/lecturers/jw_dante/publications#1984

              D'autres travaux avaient, globalement corroboré cette anlayse, ceux des professeurs Barret, Bird et Bird de Stanford sur les premièresusines automobiles du secteur des Grands Lacs (avec des réminescences de culture indienne ["Native American" pour adoipter le jargon PC en vigeur dans les Universités Nord-Americaines] dans des groupes cultures d'origine européenne, si je me souviens bien...)

              http://www.stanford.edu/dept/anthsci/faculty.html(...)

              Ca passe ce coup-ci, mais n'y revenez plus, ...sed perserverare..

              Yoj'

              Ps : oups, j'allais oublié le lien vers le papier en question : http://www.imdb.com/title/tt0087363/(...)

              • [^] # Re: deverminage

                Posté par  . Évalué à 3.

                Et bien en réalité non, bien qu'il soit difficile de répondre à un texte aussi décousu.

                Pour en revenir aux bugs, il s'agit tous simplement de l'époque ou l'élèctronique prenait beaucoup de place, il arrivait qu'une petite bête se prommene sur les circuits et autour des lampes et se prenne une décharge élèctrique fatal, causant généralement sa mort en même temps qu'un disfonctionnement (court circuit, lampe grillé etc). Le problème n'était généralement visible que par sa conséquence, l'appelation "bug" pour un problème est apparût à ce moment là.
                Actuellement, ceci n'est plus de circonstance, je verrais mal des cafards se prommener dans un Datacenter (mais sait on jamais) et surtout se prommener dans le code du Kernel.

                Pour le reste, bien qu'il soit exacte que l'ére de l'industrialisation ait causé différents troubles, et pas seulement chez les ouvriers, et qu'il y ait effectivement eu des mouvement de "casseur de machines", celà n'a pas grand chose à voir avec les bugs...

                Quant aux Grimlins, je pense plutôt que l'auteur s'est inspiré de cette histoire de bugs plutôt que l'inverse...

                • [^] # Re: deverminage

                  Posté par  . Évalué à 3.

                  En fait le terme 'bug' était déjà utilisé avant comme l'a montré un texte de Thomas Edison envoyé en 1878 à un collègue, et on peut en voir un extrait ici [1]. Cependant le premier bug 'physique' (qui était une mite et non un cafard) a été trouvé précisément le 9 septembre 1945 dans le Mark II de l'université d'Harvard court-circuitant un relais. Les logs écrits par les opérateurs font mention du "First actual case of bug being found" (premier cas effectif de 'bug' ayant été trouvé) ce qui montre encore que le terme était déjà en cours. La mite en question a même été gardée et est exposée dans un musée de la marine en Virginie. Pour une photo de l'insecte légendaire, c'est ici [2] !

                  [1] http://en.wikipedia.org/wiki/Computer_bug(...)
                  [2] http://www.history.navy.mil/photos/images/h96000/h96566kc.htm(...)

            • [^] # Re: deverminage

              Posté par  . Évalué à 1.

              La creature du Bugs Bunny est un gremlin: http://www.answers.com/topic/gremlin(...)

    • [^] # Re: RC != deverminage

      Posté par  . Évalué à 0.

      Personnellement j'utilise le mot bogue et ses dérivés depuis que je suis tout petit...

    • [^] # Re: RC != deverminage

      Posté par  . Évalué à 1.

      Pour pouvoir trouver les bugs, il faut un maximum de gens pour faire les tests et trouver ce qui ne marche aps. C'est encore plus vrai pour tout ce qui touche au matériel ou un changement qui marchera sur la machine du développeur fonctionnera parfaitement mais risque de ne pas marcher sur une machine avec un matériel légèrement différent.
      Donc pour faire un débuggage correct, il faut un maximum de gens qui testent le noyau. Et un des seuls moyens que Linus a trouvé pour attirer un maximum de testeurs, c'est de coller un -rc aux noyaux très tôt, les numéros de version instables ou les -pre ayant plutôt tendance à faire peur à des testeurs potentiels.
      Si tu as une solution miracle à ce pb et que ça te tient tant à coeur que l'étiquette -rc corresponde à ce que les gens qui écrivent des jolis livres sur le génie logiciel appellent -rc, je pense que tu devrais en parler à Linus...

  • # L'uptime des mediabox home-made va-t-il s'envoler ?

    Posté par  (site web personnel) . Évalué à 4.

    Kexec qui permet lors d'un crash système de charger un nouveau noyau et de démarrer dessus rapidement sans passer par le BIOS



    La fin des reboot pour MAJ le noyal ? Hop un coup de Kexec sur mon nouveau pépin fraichement compilé sans remettre à zéro mon compteur de geekisme.

    • [^] # Re: L'uptime des mediabox home-made va-t-il s'envoler ?

      Posté par  . Évalué à 10.

      encore faut-il réussir à crasher le système avec l'autre, sinon ça marche pas

      non, c'est bon, je sais où c'est... ~~~>[]

    • [^] # Re: L'uptime des mediabox home-made va-t-il s'envoler ?

      Posté par  . Évalué à 10.

      Non, ca n'est pas une update du noyau qui tourne actuellement.
      C'est juste un reboot plus rapide puisqu'il ne passe pas par le BIOS.
      Le noyau reboote entierement, toutes les structures de données sont perdues, donc en particulier tes processus.
      Donc uptime remis à 0.

      On ne peut pas conserver ces structures de données puisque le nouveau noyau pourrait très bien avoir des types différents, par exemple un champ de plus ou de moins dans une structure.
      C'est pour la même raison que tu ne peux pas, apres un suspend to disk, utiliser la sauvegarde du systeme avec un autre noyau (il verifie que c'est la meme version).

  • # Testé et approuvé

    Posté par  (site web personnel) . Évalué à 0.

    A l'heure où j'écris ces lignes, il n'est pas dispo sur le miroir français, mais sur l'allemend.

    Compilé sans pbmes, démarré sans pbme, nickel.
    J'ai l'impression qu'il est plus rapide, mais je ne sais pas comment tester cela avec certitude.

    Bye

    • [^] # Re: Testé et approuvé

      Posté par  . Évalué à 3.

      alors j'y connais rien en noyau, mais l'amélioration du I/O scheduler n'est-elle pas censée justement accélérer pas mal de choses?

      • [^] # Re: Testé et approuvé

        Posté par  . Évalué à 5.

        "pas mal de choses", je sais pas. "un peu", surement.
        Mais encore faudrait-il utiliser le bon scheduler.
        On parle d'amélioration du scheduler CFQ, mais très peu de personnes ne l'utilisent puisque par défaut c'est l'Anticipatory et qu'on ne sait pas forcément comment le changer...


        macvin:~% cat /sys/block/hda/queue/scheduler
        noop [anticipatory] deadline cfq

        • [^] # Re: Testé et approuvé

          Posté par  (site web personnel) . Évalué à 8.

          >> très peu de personnes ne l'utilisent puisque par défaut c'est l'Anticipatory

          Vu sur http://lwn.net/Articles/114770/(...)

          "The new CFQ scheduler has spawned a low-key debate over which scheduler should be used by default. The default scheduler currently is AS, but some people (Andrea Arcangeli in particular) are saying that it should be CFQ instead. SUSE apparently already makes CFQ the default scheduler for its enterprise kernel. Andrew Morton is unsure; AS still seems to be better for desktop systems and IDE disks. Even so, he is ready to consider a change in the default scheduler."

          Donc y'a pas mal de gens qui utilisent CFQ (tous les gens qui ont une Suse entreprise) et de plus cela pourrait bien devenir le scheduler par défaut.

        • [^] # Re: Testé et approuvé

          Posté par  (site web personnel) . Évalué à 5.

          Interressant et vrai. Suite à ta remarque, j'ai cherché comment changer de scheduler, j'ai trouvé un howto gentoo, mais qui marche pour tout le monde, oeuf corse :
          http://fr.gentoo-wiki.com/HOWTO_ioscheduler(...)

          Bye

      • [^] # Re: Testé et approuvé

        Posté par  . Évalué à 6.

        Encore faudrait-il définir "accélérer" (le scheduler d'IO le plus fluide ou réactif pour un utilisateur "desktop" peut aussi être le moins performant dans d'autres cas de figures, voir http://bhhdoa.org.au/pipermail/ck/2005-August/004086.html(...) pour un rapide aperçu de tout ça), mais oui, le support des priorités dans CFQ peut avoir des effets visibles. Perso la première que je l'ai essayé, j'ai trouvé mes "emerge" (les installation from-sources de paquets Gentoo) renicés en tâche de fond encore plus discrets qu'avant par exemple. Bon après, c'est difficile de chiffrer tout ça, c'est plutôt une impression générale, et je ne suis pas plus que quiconque à l'abri des biais psychologiques, donc je ne m'avancerai pas trop non plus...

    • [^] # Re: Testé et approuvé

      Posté par  . Évalué à 3.

      Peut être avec Bootchart :
      http://www.bootchart.org/(...)

      Il me semble qu'il mesure le temps de démarrage du démarrage du noyau jusqu'a la fin de l'execution d'init. Et d'aprés mes souvenirs l'installation est assez simple.

  • # Plusieurs "reboots" avec kexec?

    Posté par  (site web personnel) . Évalué à 2.

    Je me demande s'il est possible de "rebooter" plusieurs fois avec kexec?
    En effet il conserve la mémoire de l'ancien noyau, donc au "reboot" suivant qu'est-ce qu'il se passe?
    Il le perd?
    Ca marche pas?
    À chaque reboot plus de mémoire est utilisée?
    De quand j'avais vu le code source ca serait plutot ca marche pas ...
    enfin il écrase la mémoire du noyau actuel... au lieu de se mettre à côté
    enfin c'est ce que j'ai cru comprendre

    • [^] # Re: Plusieurs "reboots" avec kexec?

      Posté par  . Évalué à 4.

      Non il ne conserve pas la mémoire. Enfin tout depend du truc que kexec lance. Si tu kexec un noyau linux, il ecrase tout comme n'importe quel boot de noyau linux.
      Par contre, kdump utilise kexec avec un tout petit noyau qui a la particularité de ne pas tout ecraser et permet donc d'aller voir la mémoire de l'ancien noyau. Mais kdump ne permet pas de travailler, juste de debugguer un peu.

  • # ...

    Posté par  . Évalué à 10.

    l'horloge d'interruption (Timer interrupt) est désormais configurable et passe par défaut à 250 Hz au lieu de 1000 Hz pour l'architecture i386

    Pour la petite histoire ce changement a ete apporté pour que les portables aient plus d'autonomie. En effet a 1000hz, le nombre d'interuption etait trop grand, ce qui empechait le processeur de passer en mode d'economie d'energie (state C3) pendant de longue duree. Mais l'inconvenient c'est que certaines appli multimedia et temps reel vont en patir...
    Une idee qui est en cours de test c'est d'avoir un Timer interrupt dynamique (IIRC ca existe deja sous arm), dont la frequence diminurait si celle ci n'est pas necessaire.
    Apres certains test qui on ete realise, ca permet de decendre jusqu'a 60Hz (du au driver clavier/souris qui fait du polling a cette frequence) et d'ecomiser encore un peu plus d'energie.

    Au passage l'utilisation de l'usb empeche actuellement le processeur de passer en mode de basse consomation. Pour s'en convaicre il suffit de regarder la difference de conso dans /proc/acpi/battery/*/state et l'etat du processeur dans /proc/acpi/processor/*/power

    • [^] # Re: ...

      Posté par  . Évalué à 4.

      Je n'ai pas suivi le troll jusqu'au bout sur LKML, est-ce que les resultats de comparaison de la consommation d'energie en 250Hz et 1000Hz ont été concluants ?

      • [^] # Re: ...

        Posté par  . Évalué à 4.

        oui ca permetait de gagner quelques pourcents, par contre il ne faut pas utiliser l'usb en meme temps...

        • [^] # Re: ...

          Posté par  . Évalué à 1.

          Si tu as une souris externe branchée sur l'usb, cela veut-il dire que ça ne sert à rien ou la souris se "met en veille" aussi ?

          • [^] # Re: ...

            Posté par  . Évalué à 3.

            Non des que tu branche un periph usb, les dma sont utiliser meme si on se sert pas de la souri et ca empecherais le processeur de passer en mode d'economie d'energie. A verifier dans le /proc/acpi/processor/*/power...

            • [^] # Re: ...

              Posté par  . Évalué à 1.

              J'ai du mal à comprendre. Des dma tu en as pour tout un tas de trucs autres que l'USB, non?. Et il n'y aurait que celui de l'USB qui empêcherait le passage en mode eco?

    • [^] # Re: ...

      Posté par  . Évalué à 5.

      Les 'Timer interrupt' dynamiques ont été proposés par pas mal de monde déjà, notamment pour l'embarqué. Le principal souci, de souvenir, c'est que les patch proposés était intrusifs et pas forcément judicieux.

      Je crois qu'il s'agit d'une partie du noyau qui est très discuter en ce moment et on peut s'attendre à du nouveau de ce côté.
      <a verifier>
      La variable avait déjà été changée de 100 à 1000 par les distributions majeurs (Redhat, Suse...) sur le 2.4, puis intégré au noyau 2.6.
      </a verifier>

  • # On l'a échappé belle

    Posté par  (site web personnel) . Évalué à 10.

    > Linus Torvalds vient d'annoncer la sortie de la version 2.6.13 du noyau Linux qui est au coeur de toutes les distributions GNU/Linux.

    Un instant j'ai eu peur que les distributions GNU/Linux aient un noyau NetBSD. Me voilà rassuré

    • [^] # Re: On l'a échappé belle

      Posté par  . Évalué à 3.

      bein ! et Hurd alors ? ^^

      • [^] # Re: On l'a échappé belle

        Posté par  (site web personnel) . Évalué à 3.

        Le Hurd est au coeur des distributions GNU (ou GNU/Hurd si on veut), certainement pas GNU/Linux.

      • [^] # Re: On l'a échappé belle

        Posté par  . Évalué à 0.

        hein ? hurd va être au coeur de linux maintenant ??


        ----> ok je cours je cours ------> [ ]

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: On l'a échappé belle

      Posté par  . Évalué à 2.

      Un instant j'ai eu peur que les distributions GNU/Linux aient un noyau NetBSD. Me voilà rassuré

      le noyau freebsd, il est mieux pour ça en fait...

      http://lists.debian.org/debian-devel-announce/2005/08/msg00013.html(...)

    • [^] # Re: On l'a échappé belle

      Posté par  (site web personnel) . Évalué à 8.

      >> Un instant j'ai eu peur que les distributions GNU/Linux aient un noyau NetBSD. Me voilà rassuré

      Oui je sais c'est un peu bête mais en même temps j'étais obligé de faire un peu de contexte pour ceux qui ne s'y connaissent pas trop. Quand on soumet une news on essaye d'écrire pour tous le monde et pas que pour les kernel hackers.

      • [^] # Re: On l'a échappé belle

        Posté par  (site web personnel) . Évalué à 3.

        Je comprends ta raison, mais bon, c'est vrai que c'était pas très fin comme contexte, sans compter que ça sent un peu la prise de position (GNU/Linux vs Linux) glissée en douceur :p

        Mettre un lien vers un howto "compiler son kernel", ou "migrer de 2.4 à 2.6" (ça m'intéresse ça :p), aurait été une démarche quand même plus utile.

        Bon, enfin je disais juste ça pour remarquer que tu essayais de lancer un troll. Pas bien !

    • [^] # Re: On l'a échappé belle

      Posté par  (site web personnel) . Évalué à 3.

      Un instant j'ai eu peur que les distributions GNU/Linux aient un noyau NetBSD.


      C'est déjà le cas pour Debian:

      http://www.debian.org/ports/netbsd/(...)

      • [^] # Re: On l'a échappé belle

        Posté par  (site web personnel) . Évalué à 1.

        Dans ce cas, Debian n'est pas une distribution GNU/Linux mais GNU/plein_de_noyaux.
        Dans la mesure où GNU/Linux = système GNU qui a un noyau Linux, on peut retourner le problème dans tous les sens, on n'arrivera pas à mettre autre chose comme noyau.

        Et sinon, Gentoo fait pareil sur un *BSD (Free ?) et the Hurd.

    • [^] # Re: On l'a échappé belle

      Posté par  (site web personnel) . Évalué à 1.

      [mode pénible]

      En même temps, la dépêche du nouveau kernel est passée sur clubic avant de passer sur linuxfr... ça fait un peu désordre !

      12:02 sur Clubic : http://www.clubic.com/journal-112-0-0-0-0-linux.html(...)
      Modéré le lundi 29 août à 12:39 sur Linuxfr

      [/mode pénible]

      Booooh, c'est pas grave, on fera mieux la prochaine fois ! :)

      • [^] # Re: On l'a échappé belle

        Posté par  . Évalué à 6.

        la dépêche du nouveau kernel est passée sur clubic avant de passer sur linuxfr... ça fait un peu désordre !


        Ça ne me gêne pas tant que ça, et ce pour au moins deux raison. Premièrement, les gens de clubic sont payés pour faire leur boulot, contrairement aux rédacteurs et aux modéros de dlfp qui sont bénévoles. Deuxièmement, la news dlfp est quand même plus étoffée.

  • # powerpc boot problème

    Posté par  . Évalué à 8.

    Si vous avez un problème au boot sur ppc, voir ce message
    http://lkml.org/lkml/2005/8/29/35(...) pour une solution.

  • # Faute de francais

    Posté par  (site web personnel) . Évalué à -1.

    << puisqu'il n'a pas fallu moins de>>

    il a fallu pas moins de ...

    • [^] # Re: Faute de francais

      Posté par  . Évalué à -7.

      Désolé, je trouve sa tournure beaucoup plus correcte que la tienne.

      Franchement, je pense que tu aurais pu t'épargner ce commentaire qui ressemble quand même fortement à de l'enculage de mouches.

      Désolé pour les mouches.

  • # Pilote vfat

    Posté par  . Évalué à 3.

    Savez vous si le pilote vfat a été retouché ? Il y avait un problème de vitesse avec ce pilote, notamment au niveau des clés usb car pour chaque bit copié, c'est synchronisé et la table fat est mise à jour (ce qui ne devait pas être le cas sur les 2.6.11).

    Il y a une astuce pour ne pas que ce soit le cas : enlever les sync du fstab et mettre à false la ligne
    <merge key="volume.policy.mount_option.sync" type="bool">true</merge>
    de /usr/share/hal/fdi/90defaultpolicy/storage-policy.fdi - sur une Gentoo en tout cas.
    Je ne sais pas si c'est très propre et il faut éviter de débrancher à chaud sans avoir démonter le système de fichiers mais ça fonctionne.

    Donc des infos de ce coté ?

    • [^] # Re: Pilote vfat

      Posté par  . Évalué à 5.

      Auparavant aussi, il fallait déjà éviter avant de débrancher à chaud sans démonter.
      Même si tu avais sync dans les options de mount, il n'était pas supporté par vfat avant 2.6.12. Donc ca allait vite puisque ce n'était en fait pas synchronisé.

      Depuis 2.6.12, soit tu enleves sync et tu as le comportement d'avant.
      Soit tu mets sync et ca rame mais tu peux debrancher sans démonter.
      Je n'ai pas vu de différence avec les 2.6.13-rc*.

      Certains ont conseillé de mettre dirsync pour que les modifications des répertoires soient synchrones.

  • # Plus de devfs

    Posté par  (site web personnel) . Évalué à 10.

    Personne ne l'a noté, mais le support de devfs a été supprimé.
    Il nous faut maintenant utiliser udev ou /dev static.

    udev est maintenant très performant, particulièrement appréciable pour sa granularité. Il est aussi supporté par la quasi-totalité des distributions, donc si vous souhaitez passer en 2.6.13, pensez a migrer en udev ;)

    Je n'ai pas trop suivi l'affaire du ndevfs, nano devfs, écrit par Greg KH dont le but était de fournir un devfsd pour les architectures embarquées qui n'ont aucun besoin d'un dev dynamique ou d'un nommage personaliser des devices.

    Quelques liens :
    udev : http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html(...)
    ndevfs : http://kerneltrap.org/node/5347(...)
    plus de devfs : http://kerneltrap.org/node/5340(...)

    • [^] # Re: Plus de devfs

      Posté par  (site web personnel) . Évalué à 7.

      >> Personne ne l'a noté, mais le support de devfs a été supprimé.

      Question : les lignes de code de devfs ont-elles été vraiment éradiquées du noyau ou n'est-ce pour l'instant qu'un masquage de l'option de configuration pour "forcer" les gens à migrer vers udev ?

    • [^] # Re: Plus de devfs

      Posté par  (site web personnel) . Évalué à 3.

      Je ne sais pas si c'est un bien ou un mal ....

      Avant j'aimé bien devfs : Dynamic, et tout et tout.
      Puis quand j'ai vu obsolet, j'ai essayé udev.

      J'ai trouvé cela super pratique. (nommé les periphérique utilisé fréquement, ...)

      Finalement devfs ne sert plus a rien.
      Pour les systèmes embarqué ne peut-on pas utiliser un système statique ?

      • [^] # Re: Plus de devfs

        Posté par  . Évalué à 1.

        Maintenant, je n'arrive plus a charger alsa sous forme de module. J'ai du mal suivre un truc mais du coup il manque des symbole au chargement, il lui manque en fait un periphérique ds dev

        • [^] # Re: Plus de devfs

          Posté par  (site web personnel) . Évalué à 4.

          Pourtant moi avec udev, je n'ai aucun problème pour charger mes modules ALSA (emu10k1).
          Par contre en statique, il faut créer les periphériques statique à la main ( à l'ancienne).

          • [^] # Re: Plus de devfs

            Posté par  (site web personnel) . Évalué à 5.

            Parmis ceux qui font de l'embarqué sur LinuxFr. Peuvent-ils expliquer si il est mieux dans ce cas d'utiliser udev, devfs, ou tout mettre en statique dans /dev ? (Aprés tout, dans l'embarqué, les periphériques connectés ne risque pas de changer tous les jours, non ?

            Devfs prenant de la mémoire, je pense que c'est problèmatique pour les système embarqué (la mémoire coute cher).

            Sinon pour tous le monde. Qui de vous preferes devfs et qui prefere udev ?
            Personnelement je prefére udev (Nommage spécifique des périfériques, une option en moin dans le noyaux, ....)

            • [^] # Re: Plus de devfs

              Posté par  (site web personnel) . Évalué à 2.

              pour l'embarqué j'utilise un /dev en statique, vu comme tu le fait remarquer que les périfs ne changent jamais. Faut voir la consomation mémoire de udev/devfs et la taille du code, c'est peut-être intéressant si on utilise l'USB ?

    • [^] # Re: Plus de devfs

      Posté par  . Évalué à 9.

      udev est maintenant très performant, particulièrement appréciable pour sa granularité. Il est aussi supporté par la quasi-totalité des distributions, donc si vous souhaitez passer en 2.6.13, pensez a migrer en udev ;)

      J'ai un gros doute quant au support de udev par toutes les distros. Je veux dire que certaines sont restées à la 0.34 ou un numéro du genre, complètement incompatible avec les versions supérieures. Il y a encore eu de grosses modifs dans les 0.6x. Il faut avouer que ça marche bien cependant. Il y a encore une chose qui me turlupine avec le dernier udev (0.68) : il est censé remplacer complètement hotplug, mais j'ai encore besoin de hotplug pour initialiser certains périphériques dans /dev. Je n'utilise pas de coldplug ou de truc du genre. En tout cas, ça fonctionne bien, mais que de changements depuis la 0.2x, c'est impressionnant. Les fichiers de conf ont changé complètement au moins 4 fois !!!
      J'espère que ça va se stabiliser, la dernière en date, c'est le support de devfs retiré de udev, ou fortement abîmé en tout cas. Bonjour la surprise au reboot ...

  • # Souci avec un joystick Logitech

    Posté par  (site web personnel) . Évalué à 2.

    Depuis mon upgrade en 2.6.13 mon joystick (enfin, mon joypad) Logitech Wingman branché sur le port approprié de ma SB Live n'est plus reconnu. Je charge bien le module du gameport (emu10k1-gp.ko) ainsi que les modules du joystick (joydev.ko et adi.ko) mais ces deux derniers semblent ne rien faire du tout. En 2.6.12 et en ne touchant rien au setup, il fonctionnait. Quelqu'un a le même problème ?

    • [^] # Re: Souci avec un joystick Logitech

      Posté par  (site web personnel) . Évalué à 2.

      Tien ca serait pour ca que chez moi ca marche pas.....
      MMmmm
      Bon sinon modprobe joydump, dans dmesg il te dit quoi?

      • [^] # Re: Souci avec un joystick Logitech

        Posté par  (site web personnel) . Évalué à 1.

        Je reboote histoire d'avoir tout clean. Je jette un oeil à /dev, tout est là:

        /dev/js0
        /dev/js1
        /dev/js2
        /dev/js3
        /dev/input/js0
        /dev/input/js1
        /dev/input/js2
        /dev/input/js3
        /dev/js

        Je load joydump.ko, il est bien là:

        Module Size Used by
        joydump 3136 0
        gameport 11592 3 joydump

        Je load le module du port joystick de ma SB Live, à savoir emu10k1-gp.ko:

        gameport: EMU10K1 is pci0000:01:09.1/gameport0, io 0x9800, speed 852kHz
        joydump: ,------------------ START ----------------.
        joydump: | Dumping: pci0000:01:09.1/gameport0 |
        joydump: | Speed: 852 kHz |
        joydump: >------------------ DATA -----------------<
        joydump: | index: 0 delta: 0 us data: 11111110 |
        joydump: | index: 1 delta: 0 us data: 11111111 |
        joydump: | index: 2 delta: 521 us data: 11111110 |
        joydump: `------------------- END -----------------'

        Je load joydev.ko, rien de particulier n'apparaît dans le dmesg.
        Je load adi.ko, rien de plus.

        J'ai pas l'impression de trop avancer :/ Ça me rappelle douloureusement le passage en 2.6 avec lequel le port joystick de ma ens1371 a subitement fini de fonctionner... m'obligeant à acheter une nouvelle carte son. Je sais, ça serait plus simple d'acheter un nouveau joystick en USB mais celui-là je l'aime bien...

  • # Inotify

    Posté par  (site web personnel) . Évalué à 1.

    Cool, Inotify qui remplace Dnotify pour surveiller en temps réel les événements concernant le système de fichiers

    Je vais pouvoir réinstaller famd, le truc qui m'empêchait d'éjecter un cd-rom quand Nautilus l'avait parcouru (=> je killais Nautilus pour pouvoir éjecter mes cd).

    Je vais m'amuser avec Beagle du coup ;-)
    http://www.beaglewiki.org/Inotify_Kernel(...)

    Y'a d'autres outils sympas dans ce genre là ?

    Haypo

    • [^] # Re: Inotify

      Posté par  . Évalué à 1.

      Pour KDE, y'a Kat (encore en version béta qui a justement besoin du module inotify) avec un logo sympa :-)

      http://rcappuccio.altervista.org/(...) (traduit en 11 langues en plus de l'anglais comme ils disent sur le site)

      Voilà !

    • [^] # Re: Inotify

      Posté par  . Évalué à 3.

      famd c'est la misère quand même. Si tu n'as pas besoin de toute la partie réseau de fam (notamment pour NFS), je te conseille plutôt d'installer gamin à la place : pas de serveur à démarrer, aucune config nécessaire (sauf si tu veux un polling pour tes partitions NFS), il ne fait, par défaut, pas de dnotify sur les répertoires /mnt et /media (donc tranquille avec ton CD).

      Bref gamin c'est super mieux que famd en règle générale, et gamin supporte inotify en plus.
      linux-libc-headers n'étant pas à jour, j'ai rajouté à la main le inotify.h dans /usr/src/linux. Ceci dit, bien que ça impacte ce que dit le configure, je ne pense pas que ça impacte vraiment la compilation.

  • # Alsa est cassé

    Posté par  . Évalué à 1.

    Pas glop, j'ai perdu le son avec ce noyau. Ou du moins, il cesse de fonctionner après 1-2 secondes ! C'est court pour la tv :)
    Je vais investiguer, mais pour l'instant, je reste sur le 12.

    • [^] # Re: Alsa est cassé

      Posté par  (site web personnel) . Évalué à 2.

      si le drivers alsa a changé de version dans le noyo faut la version de alsa-lib et alsa-utils qui convient

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.