Sortie de Linux 2.6.20

Posté par  (site web personnel) . Modéré par j.
Étiquettes :
0
5
fév.
2007
Noyau
Fidèle à son rythme de sortie quasi-bimestriel, voici le tout nouveau noyau Linux, le premier de l'année 2007.

Rappelons le processus ayant conduit à la sortie de cette nouvelle version. Après la sortie du 2.6.19, Andrew Morton a indiqué la liste des patchs suffisamment stables pouvant migrer de sa branche de test (la -mm) vers la branche de Linus pendant la période d'intégration. Cette période, d'une durée de deux semaines, permet l'ajout de toutes les nouveautés prévues.
Une fois ce délai de deux semaines écoulé, Linus annonce la sortie de la première release-candidate (la -RC1) et il n'est plus permis d'ajouter de nouvelles fonctions. Seul le travail de correction des bugs et de stabilisation est autorisé, rythmé régulièrement par les releases-candidates successives toutes les quelques semaines. La -RC3 est ainsi apparue juste avant la nuit du réveillon pour éviter, selon Linus, tout problème avec l'organisation MADR ("Mothers Against Drunk Releases").
La RC6, annoncée le 24 janvier dernier (voir le message d'annonce) devait être la version finale, cependant quelques régressions persistaient et Linus a insisté le 30 janvier pour sortir une RC7 afin de corriger cela.

En dépit des espoirs initiaux d'une version facile à développer, car sans grandes nouveautés conceptuelles, le chemin n'a pas été semé de roses. Un bug vicieux et subtil a notamment déclenché une véritable traque à grande échelle dont la saga est narrée en plusieurs épisodes sur le site Kerneltrap.
C'est Linus lui-même qui a finalement eu la peau du bug et un article explicatif (très technique) est disponible ici pour les curieux. Les nouveautés marquantes du nouveau noyau :
  • La principale innovation de la version 2.6.20 est l'intégration de la technologie de virtualisation KVM dans le noyau. C'est la première fois qu'une telle technologie est acceptée dans la branche principale (mainline) car ses concurrents (Xen et autres) sont des patchs externes. C'est la simplicité qui a payé car KVM consiste seulement en un module noyau et un composant en espace utilisateur. Il s'appuie sur les extensions hardware des processeurs récents (Intel VT et AMD SVM). Selon cet article détaillé la solution KVM est plus simple et plus maintenable et la communauté des développeurs va maintenant converger vers cette solution au détriment de Xen.

  • Une option de fonctionnement du noyau à 300 Hz a été ajoutée. Elle permet d'obtenir des nombres entiers quand on la divise par le nombre d'images par seconde des vidéos PAL ou NTSC. Les formats à 25 images/s et 30 images/s sont donc plus facilement supportés.

  • Le support du protocole UDP-Lite est ajouté dans le noyau. UDP-Lite est spécialement adapté pour le transport en streaming des flux média. Un survol technique de ce nouveau protocole est disponible sur ce wiki

  • Toujours en ce qui concerne le réseau on note que DCCP supporte maintenant l'infrastructure de sécurité SELinux ce qui permet un contrôle plus fin.

  • Les bus SCSI peuvent maintenant être scannés de façon asynchrone ce qui améliore la vitesse de démarrage.

  • Le système permettant d'observer les entrées/sorties (I/O Accounting) est largement modifié pour améliorer sa précision. Les développeurs Samba se réjouissent de cette amélioration qui va permettre d'observer plus précisément le comportement de leur logiciel dans tous les cas de figure.

  • Le système de fichier pour cluster GFS2 (introduit dans le noyau précédent) est largement amélioré. Le gestionnaire des verrous (lock manager) supporte maintenant les connections TCP.

  • La couche générique HID n'est plus réservée seulement aux pilotes des périphériques USB et accepte maintenant d'autres protocoles (Bluetooth...etc). L'utilisation de cette couche générique permet une réutilisation et un partage optimal du code.

  • Le mécanisme de Workqueue est largement modifié afin de réduire drastiquement son empreinte mémoire. Cela a conduit à des modifications de l'API et à des corrections à travers tout le noyau. Workqueue est utilisé pour gérer les processus afin de les "endormir" et les "réveiller" après un intervalle de temps spécifié.

  • Le travail d'annotation du code du noyau continue afin de permettre les travail de sparse. Cet outil, écrit à l'origine par Linus Torvalds, utilise des annotations sémantiques présentes dans le code pour faire une analyse des erreurs potentielles lors de la compilation (pointeurs mémoires, verrous...etc). Le sous-système réseau est maintenant largement annoté pour permettre cette analyse automatique.

  • Pour améliorer encore la qualité et la robustesse du noyau une infrastructure d'injection d'erreur a été ajoutée. Cela semble paradoxal mais c'est en fait très simple : le noyau Linux actuel est très stable ce qui entraîne que le code de gestion des erreurs n'est pas souvent sollicité. Pour s'assurer de la robustesse de ce code la nouvelle infrastructure va permettre de générer des erreurs afin de vérifier que le noyau se comporte comme prévu dans tous les cas imaginables. Une documentation complète est disponible pour utiliser au mieux ce mécanisme original.

  • Un nettoyage des fichiers de header de Linux a été effectué. Cela diminue le nombre d'includes afin d'accélérer la compilation du noyau.

  • Comme d'habitude énormément de pilotes sont améliorés, corrigés ou ajoutés. Il est impossible de tous les citer mais, à titre d'exemple parmi d'autres, on peut noter l'intégration du pilote "usbvision" qui permet le support générique de plus de cinquante webcams USB.


En ce qui concerne les évolutions futures du noyau Linux on peut se pencher sur les patchs qui ont rejoint la branche expérimentale -mm d'Andrew Morton.
Une première évolution sera la possibilité d'avoir des entrées/sorties asynchrones dans les fichiers tampons (Asynchronous buffered file I/O). Actuellement ces entrées/sorties asynchrones existent seulement en cas de connexion directe mais si le système de fichier utilise la couche d'abstraction (Virtual File System) alors cette possibilité n'existe plus. Une série de patchs est maintenant en phase de test afin de corriger cela.
On trouve également dans la branche -mm le support unifié des pilotes en espace utilisateur. Il peut être utile dans certains cas, par exemple quand il est trop gros pour rejoindre le noyau, de faire fonctionner un pilote en tant que programme en espace utilisateur (userspace). Afin d'éviter l'anarchie de douzaines d'implémentations différentes il sera possible d'utiliser cette future interface standard. Le support unifié permettra de n'implanter dans l'espace du noyau qu'un minuscule module qui communiquera avec le pilote complet vivant, lui, en espace utilisateur.

Aller plus loin

  • # Le linux nouveau est arrivé!

    Posté par  . Évalué à 4.

    Tout ceci est fort intéressant...

    Mais j'aurais voulu avoir quelques informations supplémentaires: par exemple, existe-t-il un site répertoriant les webcams USB gérées par le noyau?

    De même, pourquoi la fréquence de 300Hz a-t-elle été choisie pour donner des nombres entiers en PAL et NTSC? Je suppose qu'il fallait un nombre divisible à la fois par 25 et par 30, mais dans ce cas-là, pourquoi ne pas avoir choisi 150?


    Si quelqu'un peut éclairer ma lanterne, je l'en saurais gré

    • [^] # Re: Le linux nouveau est arrivé!

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

      De même, pourquoi la fréquence de 300Hz a-t-elle été choisie pour donner des nombres entiers en PAL et NTSC? Je suppose qu'il fallait un nombre divisible à la fois par 25 et par 30, mais dans ce cas-là, pourquoi ne pas avoir choisi 150?


      25Hz et 30Hz correspondent à une moitié d'une image entrelacée. Pour l'image complète, il faut donc compter avec 50 et 60Hz. D'où les 300Hz.

      • [^] # Re: Le linux nouveau est arrivé!

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

        Mais malheureusement, 300Hz n'est pas multiple de 29,97Hz, qui est la fréquence exacte du NTSC (voir http://groups.google.com/group/sci.engr.advanced-tv/msg/1088(...) pour la raison historique) :o

        • [^] # Re: Le linux nouveau est arrivé!

          Posté par  . Évalué à -2.

          Ni de 120 et 180 Hz, qui sont les standards de la télévision de demain...

          • [^] # Re: Le linux nouveau est arrivé!

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

            La télévision de demain c'est du 1080*1920 en 30 images/seconde.
            La télévision d'après-demain, si tu pensais à ça, c'est 2000 (environ, pas encore décidé)*4096 ("4K" pour son petit nom) en 30 images/seconde.
            La télévision d'après-après-demain, c'est du "4K" en 60 images/seconde.
            Bref, le 120, 180 Hz, c'est du Marketing foireux qui n'existe pas en réalité dans notre monde numérique (il vient des marketeux qui quand ils recoivent un signal analogique en entrelacé, augmente les images pour compenser cet entrelacement. Avec le numérique 100%, on arrête de plus en plus l'entrelacé pour passer à du progressif, mais aujourd'hui sans augmenter le nombre d'image/seconde)

            • [^] # Re: Le linux nouveau est arrivé!

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

              pour le ciné numérique, il ya le 4K 30i/s et le 2K/60i/s (ce qui est le mieux pour restituer le mouvement, même si l'optimum est >70i/s)

              "La première sécurité est la liberté"

            • [^] # Re: Le linux nouveau est arrivé!

              Posté par  . Évalué à 2.

              La télévision de demain c'est du 1080*1920 en 30 images/seconde.

              Pour la télé "de demain" c est 1080p@60 , pour le cinéma ( blueray et hd-dvd ) c est 1080p@24

              Bref, le 120, 180 Hz, c'est du Marketing foireux

              Absolument pas , 120hz c est la fréquence idéale pour afficher a la fois du 24fps et du 60fps ( ce sont juste des multiples de 120 ) sans avoir de phénomene de judder .

              • [^] # Re: Le linux nouveau est arrivé!

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

                Pour la télé "de demain" c est 1080p@60

                Ah? C'est nouveau, je ne vois rien comme ca...
                La TNT sait a peine afficher du 720p@30 (ou du 720i@60, mais ce sont 60 demi-images!), et aucun contenu n'est enregistré en 1080p@60, donc "demain", c'est un peu présomptueux non?

                120hz c est la fréquence idéale pour afficher a la fois du 24fps et du 60fps

                C'est des choses plus nécessaires avec le numérique, l'écran n'a plus de balayage, donc il peut s'adapter a chaque 'fréquence' sans faire de scintillement ou autre.
                C'est beau le numérique ;-)

                • [^] # Re: Le linux nouveau est arrivé!

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

                  C'est des choses plus nécessaires avec le numérique, l'écran n'a plus de balayage, donc il peut s'adapter a chaque 'fréquence' sans faire de scintillement ou autre.
                  C'est beau le numérique ;-)

                  hum... je crois que tu es passé à coté du problème.

                  Numérique ou pas. Un film enregistré à 24fps, à une image prévu pour rester 1/24s à l'écran. Si ton écran diffuse à 60 fps c'est impossible. Chaque image peut être mis sur 2 ou 3 frame mais cela fera du 1/30s ou du 1/20s mais jamais 1/24s.

                  "La première sécurité est la liberté"

          • [^] # Re: Le linux nouveau est arrivé!

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

            Et pourquoi pas 680 fps, standard de qualité requis pour bien jouer à Doom !!

      • [^] # Re: Le linux nouveau est arrivé!

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

        En plus, 150 Hz ça fait un peu léger pour avoir un système multimédia réactif ... La dernière fois que j'ai compilé mon noyau, on pouvait monter jusqu'à 1 kHz, ça donne une idée. Bien sûr, monter trop haut en fréquence, ça fait effondrer le ratio entre l'exécution de code utile/productif (les applications utilisateur) et l'exécution de code de service (changement de contexte ...)

        Adhérer à l'April, ça vous tente ?

      • [^] # Re: Le linux nouveau est arrivé!

        Posté par  . Évalué à 6.

        25Hz et 30Hz correspondent à une moitié d'une image entrelacée. Pour l'image complète, il faut donc compter avec 50 et 60Hz.

        Je signale que c'est l'inverse.

    • [^] # Re: Le linux nouveau est arrivé!

      Posté par  . Évalué à 2.

      en tapant usbvision dans google, je suis tombé sur ça :

      http://usbvision.sourceforge.net/index.php?page=device

      qui parle de cartes TV, et de vieux noyaux linux (2.6.1)......

      Quelqu'un a trouvé mieux ? :-/

      • [^] # Re: Le linux nouveau est arrivé!

        Posté par  . Évalué à 3.

        Voici un site qui a pour objectif de recenser les périphériques usb qui fonctionnent avec Linux : http://www.qbik.ch/usb/devices/devices.php

        Il y a une catégorie pour les périphériques vidéo (webcam, etc) : http://www.qbik.ch/usb/devices/showdevcat.php?id=9

        J'espère que tu vas y trouver ton bonheur.

        • [^] # Re: Le linux nouveau est arrivé!

          Posté par  . Évalué à 1.

          C'est gentil mais la question n'était pas là.

          C'est juste que la news indique :

          "pilote usbvision maintenant intégré super feature car il permet le support de près de 50 modèles de webcam. "

          Or, usbvision sert à supporter des cartes TV, donc je comprends pas trop...

          Si ce pilote permet le support de 50 webcams, ben je les ai pas trouvé.

          Et je pense que ça intéresse pas mal de monde, si c'est réellement le cas.

          Merci d'autres retours.

          • [^] # Re: Le linux nouveau est arrivé!

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

            Ma phrase est juste la traduction d'une partie de texte (dans le troisième lien) sur le site LWN.

            The "usbvision" driver has been merged, adding support for "more than 50" USB video camera devices.

            • [^] # Re: Le linux nouveau est arrivé!

              Posté par  . Évalué à 2.

              Oui oui je critique pas ta news ;-)

              J'essaie juste de mettre en exergue que sur le site d'usbvision que j'ai mis plus haut (à moins que ce ne soit pas le bon site) ben ya rien de frais, et que ça parle de cartes TV.

              C'est pour ça que je trouve ça bizarre.

              Si le support de webcam d'une certaine marque est intégré dans le noyau alors je m'empresserai de faire de la pub pour elle, mais j'attends d'avoir cette marque ;-).

              P.S. bon, ok, certains vont me dire, takachercher... :D

              • [^] # Re: Le linux nouveau est arrivé!

                Posté par  . Évalué à 1.

                Si tu regardes dans le Changelog du noyau 2.6.20 il y a une ligne expliquant succintement de quoi il s'agit.

                commit 781aa1d1ab7ba13314af0af6c5d70c0eb0e96bf4
                ....
                V4L/DVB (4922): Add usbvision driver
                This patch adds usbvision into V4L/DVB HG tree.
                Usbvision driver is a GPL driver, made by:
                Joerg Heckenbach <joerg@heckenbach-aw.de>
                and
                ...

                A partir des adresses mèl données j'ai cherché un peu sur internet et il s'agit bien du projet sourceforge que tu cites.

                Il semblerait donc qu'il s'agisse d'un pilote pour cartes d'acquisition vidéo usb (Hauppauge, Pinnacle, Miro, ...).


                CQFD! (^^)

      • [^] # Re: Le linux nouveau est arrivé!

        Posté par  . Évalué à 2.

        extrait du Kconfig, ca a l'air de concerner les caméras
        à base de N1003/1004/1005... je ne sais pas ce que c'est...
        mais vu la dépendance sur SAA711A, c'est surement des cartes TV

        +config VIDEO_USBVISION
        + tristate "USB video devices based on NT1003/1004/1005"
        + depends on I2C && VIDEO_V4L2
        + select VIDEO_SAA711X if VIDEO_HELPER_CHIPS_AUTO
        + ---help---
        + There are more than 50 different USB video devices based on
        + NT1003/1004/1005 USB Bridges. This driver enables using those
        + devices.
        +

        • [^] # Re: Le linux nouveau est arrivé!

          Posté par  . Évalué à 1.

          bon, ben c'est dommage :-(

          • [^] # Re: Le linux nouveau est arrivé!

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

            A propos de web cam... J'ai une logitech qui utilise linux uvc (cf http://linux-uvc.berlios.de/ ) comme pilote. Est ce que quelqu'un sait si un jour ce pilote sera intégré au noyau ? (je veux dire "un jour dans un avenir pas trop lointain, avec des chances raissonables que cela aboutisse")

            Mathias

          • [^] # Re: Le linux nouveau est arrivé!

            Posté par  . Évalué à 3.

            Concernant les changements sur usbvision/v4l, c'est effectivement axé sur les tuners TV.
            Je suis à l'origine de ce changement, car c'est un ami qui a tout repris pour faire fonctionner mon tuner usb (win TV usb).
            Vous pouvez en consulter les multiples modif en recherchant son nom (thierry merle).
            A noter aussi qu'il continue à optimiser les drivers... ;)

            • [^] # Re: Le linux nouveau est arrivé!

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

              Donc tu confirme qu'il y a une erreur dans la news (et sur LWN) au sujet de ces drivers ?
              C'est uniquement des tuners TV et pas du tout des webcams USB ?

              • [^] # Re: Le linux nouveau est arrivé!

                Posté par  . Évalué à 3.

                a priori, oui, que les tuner usb (chipset usb NT1004 et 1003 je crois, puis qq MAJ de tuners analogiques).
                Mais bon, comme je n'y comprends pas grand chose, je ne sais pas s'il y a autre chose, ou une fonction dérivée pour les webcams.

              • [^] # Re: Le linux nouveau est arrivé!

                Posté par  . Évalué à 1.

                Juste une petite remarque "USB video camera devices" ne veut pas forcement dire "webcam USB". Je pense que la traduction n'est pas assez precise ; "USB video camera devices" inclus aussi je pense certains camescopes par exemple.
                Apres je ne sais pas si les tuners TV sont inclus dans ce groupe...

                Mes 2 cents...

  • # Rahhhhhh

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

    Il pouvais pas le sortir un peu plus tot, histoire d'occuper mon dimanche !!

    2 grosses nouveautés high tech :
    La paravirtualisation avec l'intégration de KVM pour exploiter la virtualisation matériel des puces Intel et AMD.
    Le relogement du kernel, idéal pour kdump sans avoir besoin d'un second kernel compilé sur mesure. Curieusement, le patch permetant le relogement du kernel est tout petit !!

    • [^] # Re: Rahhhhhh

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

      Linus n'a pas l'air d'accord avec toi pour penser qu'il y a des grosses nouveautés high-tech dans ce noyau.

      En fait il indique explicitement ici => http://lkml.org/lkml/2007/2/4/119 qu'il a essayé de faire une release la plus stable possible :

      I tried rather hard to make 2.6.20 largely a "stabilization release".
      Unlike a lot of kernels lately, there aren't really any big fundamental changes to some core infrastructure area, and while we always have bugs, I really am hoping that we fixed many more than we introduced.

      Rappelons que ce kernel sera celui de la future Ubuntu Feisty et, je crois, de la future Fedora 7. C'est donc un noyau important et je trouve très bien que l'accent soit mis avant tout sur la plus grande stabilité possible.

      • [^] # Re: Rahhhhhh

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

        > Linus n'a pas l'air d'accord avec toi pour penser qu'il y a des grosses nouveautés high-tech dans ce noyau.


        Ce n'est pas tout à fait ça qu'il dit.

        Il dit précisement :
        "Unlike a lot of kernels lately, there aren't really any big fundamental
        changes to some core infrastructure area,"

        En français, les fondamentaux du système n'ont pas été bouleversé. Ce qui est différent de "ne pas avoir ajouté de nouveautés".

        Or, la paravirtualisation et le relogement du système ne touche justement pas au fondamentaux du noyau, ce sont juste des fonctionnalités supplémentaires. Ce qui ne contredit en rien linus Torvalds.
        Et comme je le disais, je suis justement surpris de la petite taille des patchs pour ajouter ses fonctionnalités.

  • # debian

    Posté par  . Évalué à 1.

    Faut-il encore espérer que le noyau 2.6.19 soit un jour intégré à debian experimental

    Bon sans plaisanterie, je sait pas comment dire ça pour pas me faire mal voir
    mais je comprend pas pourquoi le 2.6.19 est jamais rentré dans les dépots

    Rémi

  • # 2.6.20 et Core2Duo et JMicron

    Posté par  . Évalué à 1.

    Si quelqu'un dans le même cas que moi pouvait me dire comment ça se passe chez lui, ce serait sympa!
    Chez moi les RC4, 5 et 6 m'empêchaient d'utiliser un de mes disques durs, mon lecteur de cartes mémoires,...et internet!
    Carte-mère Asus P5B-VM.
    J'attends l'arrivée du 2.6.20 final chez debian pour voir s'il y a eu un miracle:
    http://kernel-archive.buildserver.net/debian-kernel/pool/mai(...)

    • [^] # Re: 2.6.20 et Core2Duo et JMicron

      Posté par  . Évalué à 1.

      Pour les disques durs and co, je ne sais pas, mais pour l'accès internet, j'ai eu un problème avec Netfilter :
      Il y a eu pas mal de changement d'organisation dans la config de netfilter et du coup certains paramètres n'étaient pas retrouvés après un simple make oldconfig... j'ai du les reconfigurer à la main pour que tout le nécessaire soit compilé (en particulier le NAT) et retrouver l'accès au Net.

      • [^] # Re: 2.6.20 et Core2Duo et JMicron

        Posté par  . Évalué à 1.

        Merci beaucoup!
        Est-ce que tu aurais le temps de copier tes modifications ici pour tous les linuxiens qui vont avoir la même mauvaise surprise?
        Sinon, tant pis, c'est déjà une bonne piste pour google.

        • [^] # Re: 2.6.20 et Core2Duo et JMicron

          Posté par  . Évalué à 1.

          J'utilise le firewall Firestarter, donc je n'ai jamais vraiment mis les mains dans le cambouis au niveau d'internet/réseau. Donc en fait Netfilter ça ne veut rien dire pour moi! :D

          • [^] # Re: 2.6.20 et Core2Duo et JMicron

            Posté par  . Évalué à 1.

            A priori, Firestarter s'appuie sur netfilter...
            Une rapide explication de ce qui est nécessaire pour qu'il fonctionne est donnée ici :
            http://www.fs-security.com/docs/kernel.php

            Si tu as installé le 2.6.20 sans trop te poser de question (make oldconfig et basta, comme je l'ai d'abord fait), certaines parties de netfilter ne sont pas compilées. Il faut faire un make menuconfig (ou gconfig ou....), retrouver les options indiquées dans la page ci dessus, les activer et recompiler.

            Je ne peux pas etre plus précis ici, je n'ai pas les infos sous la main... c'est une bonne occasion de te plonger un peu la dedans.

            Bon courage !

            • [^] # Re: 2.6.20 et Core2Duo et JMicron

              Posté par  . Évalué à 2.

              Encore un grand merci!
              En fait je me contente de télécharger les .deb du kernel, de cliquer dessus, et Kpackage les installe!
              Je me demande ce qui va se passer pour des millions de nouveaux utilisateurs de linux avec les modifications à ce niveau, et au niveau de l'unification des drivers pour les disques durs. Ça risque d'être le chaos. Je ne vois vraiment pas comment l'utilisateur normal de Windows pourrait s'en sortir.

              • [^] # Re: 2.6.20 et Core2Duo et JMicron

                Posté par  . Évalué à 2.

                dans ce cas, c'est les packageurs qui devront faire le boulot. c'est plutot basique pour eux, et pour l'utilisateur normal ce sera transparent.
                mais pour ceux qui veulent du "bleeding edge", c'est sur qu'il faut parfois retrousser les manches :)

                • [^] # Re: 2.6.20 et Core2Duo et JMicron

                  Posté par  . Évalué à 1.

                  Bonne nouvelle! :)

                  P.S.: il y en a qui ont le doigt sur la gachette ici!

                • [^] # Re: 2.6.20 et Core2Duo et JMicron

                  Posté par  . Évalué à 1.

                  Je suis maintenant sous le 2.6.20 final debian experimental et effectivement internet marche. Ouf!
                  Par contre j'ai toujours le même disque dur qui ne marche pas alors qu'il marche parfaitement sous 2.6.19. C'est un PATA sur port SATA par un adaptateur (comme un autre des mes disques durs). Au boot il me dit qu'il faut que je fasse un fschck sur ce disque dur /dev/sdc1. Résultat, quand je met une carte SD dans le lecteur mémoire, celui-ci essaie de prendre /dev/sdc1 au lieu de /dev/sdd1 normalement et ne marche pas non plus.
                  J'ai aussi ce message qui fait peur dans mes logs: Feb 5 09:08:19 localhost kernel: TCP: Treason uncloaked! Peer 86.142.4.254:53202/47101 shrinks window 1039080972:1039083892. Repaired.

                  Et plus généralement des tonnes de messages de connections INBOUND.

                  • [^] # Re: 2.6.20 et Core2Duo et JMicron

                    Posté par  . Évalué à 1.

                    Le contrôleur SATA supplémentaire rajouté par Asus n'est pas reconnu par le kernel 2.6.20, alors qu'il l'était par le 2.6.19. Il m'a suffit de brancher le disque dur sdc sur le contrôleur SATA Intel puis d'aller dans le bios pour que ça marche. C'est donc une régression pour ce kernel. Mon lecteur de cartes mémoires marche bien.
                    Et finalement internet ne marche pas quand Firestarter est activé il me semble. Pourtant mon kernel est un kernel debian officiel. C'est vraiment chiant. Pour moi l'objectif de Linux est raté: ce kernel n'est pas le moins buggé depuis longtemps, au contraire.

                    • [^] # Re: 2.6.20 et Core2Duo et JMicron

                      Posté par  . Évalué à 2.

                      je vais me la jouer couillon mais as tu rapporter le probleme avant la sortie?

                      Sinon je vois pas trop comment Linus (pas Linux) pouvait deviner qu'il y avait une regression. Certes d'autre personnes doivent avoir le meme probleme mais si ils pensent que qq'un d'autre l'a signale ca va pas faire avancer les choses...

                      • [^] # Re: 2.6.20 et Core2Duo et JMicron

                        Posté par  . Évalué à 1.

                        Oui, c'est vrai. J'ai failli m'inscrire sur linuxhelp.com pour intervenir dans la discussion avec Linus sur les régressions samedi, mais je me disais que c'était peut-être de ma faute car j'utilise encore la "vieille" dénomination des disques durs dans fstab, au lieu de passer aux labels par exemple. Etant un linuxien de base, j'avais un peu peur de les déranger pour rien. Ça a commencé à me préoccuper sérieusement seulement 1 jour avant la sortie du kernel 2.6.20, quand j'ai vu que ce n'était toujours pas réglé..
                        En plus je ne sais pas où on fait les bug reports pour le kernel, et je ne sens pas qualifié pour aller déranger les génies de linux. Mais je vais devoir chercher.

                        • [^] # Re: 2.6.20 et Core2Duo et JMicron

                          Posté par  . Évalué à 4.

                          Alors, pour reporter les bugs du kernel, c'est là: bugzilla.kernel.org.
                          Tu crées uncompte et tu rapporte le bug.

                          Et puis,n'aie pas peur les "génies du kernel" aiment etre dérangés pour des rapports de bug. C'est très important que les bugs soient rapportés dans un processus de dévellopement libre...

                          Le seul truc, qu'il faut savoir, c'est qu'il te faut expliquer le plus clairement possible, et avec le maximum de détails ton bug, ton environnement, dans quel cas il apparait et comment le reproduire. Et si possible: appuyés par des extraits de logs .

                    • [^] # Re: 2.6.20 et Core2Duo et JMicron

                      Posté par  . Évalué à 2.

                      Les pilotes SATA ont été regroupés dans un bloc SATA, donc au passage vers le nouveau noyeau il n'as pas été gardé.

                      Pour firestarter, coir le commentaire netfilter dessous, il faut refaire la selection des paquets netfilter.

                      (J'ai eu le problème SATA ET NetFilter, mais ce n'est pas la mer a boire.)

                      • [^] # Re: 2.6.20 et Core2Duo et JMicron

                        Posté par  . Évalué à 1.

                        D'accord! En fait c'est surtout que c'est intimidant de devoir recompiler un kernel pour la première fois.

                        • [^] # Re: 2.6.20 et Core2Duo et JMicron

                          Posté par  . Évalué à 1.

                          même après quelques compilation de kernel a la main, et une machine qui fait un make oldconfig && make menuconfig pour retrier les options, j'y ai passé des heures sur cette réorganisation ;)

                          Mais je ne suis pas non plus une référence, et loin de la.

  • # Patch temps-réel

    Posté par  . Évalué à 4.

    A noter que le patch de Ingo Molnar qui ajoute le scheduling temps-réel à Linux est en train de faire son chemin vers l'inclusion dans la branche principale du noyau.

    Une partie des nouveautés apportés par le patch a déjà été mergée dans la version 2.6.19 : diminution du nombre de réveils du noyau en l'absence de tâches à scheduler (utile pour l'économie d'enrgie), timer haute résolution.

    Ingo a changé son modèle de développement et suis maintenant la branche principale du noyau : il intègre les modifications apportées dans les versions 2.6.x.y au fur et à mesure. Auparavant, ses patches n'étaient fournies que pour les versions en '.x'.

    Ca sera peut-être un peu juste pour l'inclusion dans le 2.6.21, mais on devrait voir ça en 2.6.22.

    A titre d'exmple, le serveur audio Jack fonctionne sans problème avec 1 ms de latence à l'aide ce patch, là où le noyau standard a déjà du mal avec 50 ms de latence.

    http://people.redhat.com/mingo/realtime-preempt/

    • [^] # Re: Patch temps-réel

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

      En effet, ce patch et d'autres bidules du noyau permettent d'avoir une latence ridiculement faible, ce qui intéressera surtout les MAOistes :)

      Le soucis actuel est qu'il faut souvent recompiler son kernel, ce qui n'est pas forcément aisé pour un musicien, ou parfois tout bêtement impossible (par exemple, le patch d'Ingo ne passe pas sur la version usuelle du kernel d'Ubuntu Edgy). Mais de plus en plus de distributions fournissent des paquets « lowlatency » ou « realtime » où tout est déjà prêt.

      Avec l'intégration du patch dans la branche principale, ça deviendra encore plus simple ; de quoi motiver les gens à s'intéresser ''enfin'' à linux pour la MAO ?

      • [^] # Re: Patch temps-réel

        Posté par  . Évalué à 10.

        ce qui intéressera surtout les MAOistes :)


        Quand on vous dit que linuxfr est un repère de communistes !

      • [^] # Re: Patch temps-réel

        Posté par  . Évalué à 1.

        Surtout que le noyau par défaut de la Ubuntu est en 250 Hz, ce qui cause même des problèmes pour des utilisations très basiques comme écouter de la musique tout en compilant :)

  • # Hans si tu nous lis !

    Posté par  (site web personnel, Mastodon) . Évalué à -9.

    Je propose d'imprimer et d'envoyer le changelog aux companions de cellule de Hans Reiser pour qu'ils puissent l'occuper avec un troll :

    "Hans, boooohh, Reiserfs 4 ça devait vraiment être de la m**** car il et toujours pas intégré dans Linux ..."

    M.

  • # ext4

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

    Je profite de cette dépêche pour poser la question, des infos sur ext4 ?
    Il était dans le noyau 2.6.19rc1-mm1, est-il bientôt opérationnel ?

    • [^] # Re: ext4

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

      Borf d'après ce qu'on lit le développement d'un file system c'est un boulot lent et méthodique. On peut pas se permettre de perdre des données donc je pense qu'Ext4 mettra du temps (même si c'est pas un FS from scratch).
      ici on trouve quelques mentions de délai => http://lwn.net/Articles/189950/

      Je parie pour la fin 2007.

    • [^] # Re: ext4

      Posté par  . Évalué à 2.

      L'inclusion dans le kernel ne veut pas dire qu'il soit bientôt opérationnel..
      Un FS n'est pas déstabilisant pour le reste (si tu n'as pas de partition ext4) donc les devs ont acceptes qu'ext4 soit directement dans le kernel même en cours de développement.

      • [^] # Re: ext4

        Posté par  . Évalué à 3.

        Ce n'est pas la seule raison.
        La raison principale selon moi, est qu'il y a une communauté de développeur nombreuse (toute chose étant égale par ailleurs), douée et avec une solide réputation de sérieux.
        L'autre raison est que ext4 n'est pas une écriture complete d'un FS, mais une évolution (majeur) d'un FS existant.
        Ext4 a aussi un roadmap assez précis.

  • # netfilter

    Posté par  . Évalué à 1.

    Je fais appel à une âme charitable pour m'expliquer quelles sont les (nouvelles) options à sélectionner pour faire tourner iptables/netfilter. J'ai récupéré le .config de mon 2.6.19, et je me mange une erreur de la part d'iptables
    iptables: No chain/target/match by that name


    Ca fait 3 fois que je recompile mon noyau en essayant différentes options, mais rien n'y fait...

    Merci

    • [^] # Re: netfilter

      Posté par  . Évalué à 4.

      Désolé, je ne peux pas t'aider, mais je trouve que la dev de netfilter ont fait une bêtise (et Linus n'aurait pas du l'accepter), les options de compilations c'est une forme d'interface utilisateur du kernel.

      Les 'early adopters' sont important pour tous le monde: les risques qu'ils prennent permettent d'avoir un système debuggé plus rapidement, pas la peine de les dégouté avec une modif comme ça..

      • [^] # Re: netfilter

        Posté par  . Évalué à 2.

        Je suis d'accord, c'est une connerie, surtout quand on touche à quelque chose d'aussi critique que netfilter. En plus, ça fait quand même quelques fois que je recompile mon noyau, je sais où se trouvent les différentes options, etc. C'est quand même dingue que je ne sois pas foutu de trouver ce qui cloche.
        Généralement, j'évite d'adopter un noyau aussi récent, mais là c'est le meilleur depuis un long moment en ce qui me concerne (correction de bugs qui trainaient depuis un moment, amélioration du pilote wifi, etc). C'est dommage que ce soit gâché par ça...

        • [^] # Re: netfilter

          Posté par  . Évalué à 2.

          J'ai eu le même problème, c'est au moment ou tu fait ton iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT que tu te mange l'erreur.

          Pour le corriger, (de tête) c'est une option dans netfilter la 3 ièeme ligne du choix dans net filter.

          1° tu as l'activation ou non
          2° tu as la version
          3° général
          4° des options spécifique je crois

          Ayant fait cette modif il y as environ 12 heures, je peux pas t'en dire plus, d'autant que j'ai pas ma machine sous la main ;)

    • [^] # Re: netfilter

      Posté par  . Évalué à 3.

      Bon, je me réponds à moi-même, je crois que j'ai trouvé:
      dans mon cas, c'est le "match state" qui avait dégagé:

      CONFIG_NETFILTER_XT_MATCH_STATE=m


      networking->networking options->network packet filtering framework->core netfilter configuration->nefilter Xtables support->"state" match support

      Je viens de vérifier, cette option était bien activée dans mon précédent .config (2.6.19), mais a dégagé ce coup ci. Mystère...

      • [^] # Re: netfilter

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

        J'ai eu le même problème.
        J'ai aussi du réactiver le match state cependant mes règles ne passe pas. Il drope tout (très embetant). Il m'affiche ceci lorsque je lance le script :

        can't load conntrack support for proto=2
        iptables : Invalid argument


        Quelqu'un a une idée ?

        • [^] # Re: netfilter

          Posté par  . Évalué à 1.

          réactiver les conntrack dans le kernel ;)

          au même endroit que le state il me semble.

          • [^] # Re: netfilter

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

            Je l'ai fait mais ça ne change rien, c'est dans :
            networking->networking options->network packet filtering framework->core netfilter configuration->nefilter Xtables support->conntrack connection tracking match support.

  • # Bug avec ReiserFS

    Posté par  . Évalué à 2.

    Salut !
    En utilisant ce kernel, j'ai eu le fameux problème
    avec le NAT pour IPTABLES que je n'ai pas su résoudre
    car je trouve que l'aide est un peu succinte....
    Mais le principal problème chez moi est venu de plantages
    de mon système en accédant à des fichiers ou en voulant en
    supprimer : le cpu monte à 100% et tout se fige.
    Donc retour au 2.6.19 et tout va bien.

    • [^] # Re: Bug avec ReiserFS

      Posté par  . Évalué à 6.

      Eh ben, reste plus qu'a esperer qu'un developpeur du noyau vienne lire les rapports de regression sur DLFP.
      Merci donc pour ta contribution au libre ...

  • # Xen

    Posté par  . Évalué à 1.

    Selon cet article détaillé la solution KVM est plus simple et plus maintenable et la communauté des développeurs va maintenant converger vers cette solution au détriment de Xen.


    What's the current state of the common parvirtualization interface that e.g. Xen depends on?

    It's coming together. I'd expect support for Xen's "Domain U" function to be merged in 2.6.21 or 2.6.22.

    http://fosdem.org/2007/interview/andrew+morton

    Pas le domain0, certes.

    • [^] # Re: Xen

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

      Tu sors ton Morton , je sors mon Corbet :

      One can almost see the interest in Xen (for example) fading; KVM comes across as a much simpler, more maintainable way to support full and paravirtualization. The community seems to be converging on KVM as the low-level virtualization interface; commercial vendors of higher-level products will want to adapt to this interface if they want their products to be supported in the future.

      • [^] # Re: Xen

        Posté par  . Évalué à 2.

        En attendant KVM à du retard sur Xen alors pour parier sur l'avenir, c'est surement KVM, mais concernant aujourd'hui, c'est Xen.

        • [^] # Re: Xen

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

          >> En attendant KVM à du retard sur Xen

          Pas d'accord !

          KVM est maintenant intégré en mainline alors que Xen n'est qu'un patch externe.
          C'est donc KVM qui est en avance !

          • [^] # Re: Xen

            Posté par  . Évalué à 2.

            oui, si on exclu tout l'aspect technique ainsi que l'aspect performance.

            Xen a un ensemble de librairies que n'a pas (encore) KVM. De plus niveau performance, Xen est pour l'instant devant.

            Donc oui, Xen est en avance, l'inclusion dans le kernel ne change rien à ce niveau.

Suivre le flux des commentaires

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