Noyau 2.6.3 dans les bacs

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes :
0
19
fév.
2004
Noyau
Le dernier noyau de la série stable des 2.6 est disponible depuis la nuit dernière. Il comporte un nombre assez impressionnant de changements parmi lesquels des corrections pour SPARC64, USB, ACPI, ALSA, I2C, compilation compatible gcc 3.5, overflow sur iptables(6).

La rc4 contenait encore quelques corrections mineures à effectuer avant cette version.

Merci à LinuxToday pour l'info.

NdM: D'après Linus Torvalds, la nouvelle vulnérabilité concernant mremap() n'est pas présente dans le 2.6.3 (pas plus que dans le 2.4.25). Il est donc important de passer à un de ces deux noyaux.

Aller plus loin

  • # Re: Kernel 2.6.3 dans les bacs

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

    Il y a aussi pas mal de nouveautés PPC (32 et 64) (entre autres, le SMP est supporté sur les G5, cpufreq pour les derniers portables, thermal management); un nouveau radeonfb, quelques nouveaux drivers (scsi, son, ...) que du bon :)

  • # Re: Kernel 2.6.3 dans les bacs

    Posté par  . Évalué à 0.

    Inutile d'employer le mot "impressionant" . C'est toujours le cas pour les premieres versions d'un nouveau kernel.

    Le contraire serait inquietant.

  • # Re: Kernel 2.6.3 dans les bacs

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

    "compatible gcc 3.5"

    vache, ça c'est impressionnant, le 3.4 est sorti hier et déja une nouvelle version...

    • [^] # Re: Kernel 2.6.3 dans les bacs

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

      Ils compilent deja le kernel sur la version CVS de GCC juste pour éviter les dérapage genre GCC 3.3 à l'époque.

      Steph

    • [^] # Re: Kernel 2.6.3 dans les bacs

      Posté par  . Évalué à 1.

      quoi le 3.4 est sorti hier? J'ai rien vu sur le site de gcc..

      • [^] # Re: Kernel 2.6.3 dans les bacs

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


        Active release branch:
        will become GCC 3.4.0


        Branch status: 2004-02-05
        (open for bug fixes for regressions only).


        Current release series:
        GCC 3.3.3 (released 2004-02-14)


        Branch status: 2004-01-28
        (open for all bugfixes).

        Active development (mainline):
        will become GCC 3.5.0 (current changes)


        Stage 1;
        open for all maintainers.

        • [^] # Re: Kernel 2.6.3 dans les bacs

          Posté par  . Évalué à 1.

          Le changelog est ici:
          http://gcc.gnu.org/gcc-3.4/changes.html(...)
          et en gros il dit:
          Caveats

          * GNU Make is now required to build GCC.
          * With -nostdinc the preprocessor used to ignore both standard include paths and include paths contained in environment variables. It was neither documented nor intended that environment variable paths be ignored, so this has been corrected.
          * GCC no longer accepts the options -fvolatile, -fvolatile-global and -fvolatile-static. It is unlikely that they worked correctly in any 3.x release.
          * GCC no longer ships <varargs.h>. Use <stdarg.h> instead.
          * Support for all the systems obsoleted in GCC 3.3 has been removed from GCC 3.4. See below for a list of systems which are obsoleted in this release.
          * GCC now requires an ISO C90 (ANSI C89) C compiler to build. K&R C compilers will not work.
          * The implementation of the MIPS ABIs has changed. As a result, the code generated for certain MIPS targets will not be binary compatible with earlier releases.
          * The implementation of the SPARC ABIs has changed. As a result, the code generated will not be binary compatible with earlier releases in certain cases.
          * The configure option --enable-threads=pthreads has been removed; use --enable-threads=posix instead, which should have the same effect.
          * Code size estimates used by inlining heuristics for C, Objective-C, C++ and Java have been redesigned significantly. As a result the parameters of -finline-insns, --param max-inline-insns-single and --param max-inline-insns-auto need to be reconsidered.
          * --param max-inline-slope and --param min-inline-insns have been removed; they are not needed for the new bottom-up inlining heuristics.
          * The new unit-at-a-time compilation scheme has several compatibility issues:
          o The order in which functions, variables, and top-level asm statements are emitted may have changed. Code relying on some particular ordering needs to be updated. The majority of such top-level asm statements can be replaced by section attributes.
          o Unreferenced static variables and functions are removed. This may result in undefined references when an asm statement refers to the variable/function directly. In that case either the variable/function shall be listed in asm statement operand or in the case of top-level asm statements the attribute used shall be used to force function/variable to be always output and considered as a possibly used by unknown code.

          For variables the attribute is accepted only by GCC 3.4 and newer, while for earlier versions it is sufficient to use unused to silence warnings about the variables not being referenced. To keep code portable across different GCC versions, you can use appropriate preprocessor conditionals.
          o Static functions now can use non-standard passing conventions that may break asm statements calling functions directly. Again the attribute used shall be used to prevent this behavior.
          As a temporary workaround, -fno-unit-at-a-time can be used, but this scheme may not be supported by future releases of GCC.

          General Optimizer Improvements

          * Usability of the profile feedback and coverage testing has been improved.
          o Performance of profiled programs has been improved by faster profile merging code.
          o Better use of the profile feedback for optimization (loop unrolling and loop peeling).
          o File locking support allowing fork() calls and parallel runs of profiled programs.
          o Coverage file format has been redesigned.
          o gcov coverage tool has been improved.
          o make profiledbootstrap available to build a faster compiler.

          Experiments made on i386 hardware showed an 11% speedup on -O0 and a 7.5% speedup on -O2 compilation of a large C++ testcase.
          o New value profiling pass enabled via -fprofile-values
          o New value profile transformations pass enabled via -fvpt aims to optimize some code sequences by exploiting knowledge about value ranges or other properties of the operands. At the moment a conversion of expensive divisions into cheaper operations has been implemented.
          o New -fprofile-generate and -fprofile-use command line options to simplify the use of profile feedback.
          * A new unit-at-a-time compilation scheme for C, Objective-C, C++ and Java which is enabled via -funit-at-a-time (and implied by -O2). In this scheme a whole file is parsed first and optimized later. The following basic inter-procedural optimizations are implemented:
          o Removal of unreachable functions and variables
          o Discovery of local functions (functions with static linkage whose address is never taken)
          o On i386, these local functions use register parameter passing conventions.
          o Reordering of functions in topological order of the call graph to enable better propagation of optimizing hints (such as the stack alignments needed by functions) in the back end.
          o Call graph based out-of-order inlining heuristics which allows to limit overall compilation unit growth (--param inline-unit-growth).
          Overall, the unit-at-a-time scheme produces a 1.3% improvement for the SPECint2000 benchmark on the i386 architecture (AMD Athlon CPU).
          * More realistic code size estimates used by inlining for C, Objective-C, C++ and Java. The growth of large functions can now be limited via --param large-function-insns and --param large-function-growth.
          * A new cfg-level loop optimizer pass replaces the old loop unrolling pass and adds two other loop transformations -- loop peeling and loop unswitching -- and also uses the profile feedback to limit code growth. (The three optimizations are enabled by -funroll-loops, -fpeel-loops and -funswitch-loops flags, respectively).

          The old loop unroller still can be enabled by -fold-unroll-loops and may produce better code in some cases, especially when the webizer optimization pass is not run.
          * A new web construction pass enabled via -fweb (and implied by -O3) improves the quality of register allocation, CSE, first scheduling pass and some other optimization passes by avoiding re-use of pseudo registers with non-overlapping live ranges. The pass almost always improves code quality but does make debugging difficult and thus is not enabled by default by -O2

          The pass is especially effective as cleanup after code duplication passes, such as the loop unroller or the tracer.
          * Experimental implementations of superblock or trace scheduling in the second scheduling pass can be enabled via -fsched2-use-superblocks and -fsched2-use-traces, respectively.

          • [^] # Re: Kernel 2.6.3 dans les bacs

            Posté par  . Évalué à 1.

            Merci pour ces infos. J'attendais cette version avec impatience pour voir les ameliorations sur les architectures amd64. Je vais pouvoir m'occuper ce week-end ;)

    • [^] # Re: Kernel 2.6.3 dans les bacs

      Posté par  . Évalué à 1.

      Tiens en parlant de gcc, je cherche le meilleur moyen pour optimiser le binaire final pendant la compilation. je bosse sur de (très) vieilles bécannes, ( en occurence je recompile pour un PowerPC @ 200 Mhz) j'ai tenté le flag -O3, ça passe, je gagne 1 Mo/s+ de tranfert de disque. Il y a d'autres techniques ? (-O4 ?).

      Parce que je vais bientôt attaquer un LC 475 que je vais switcher sous Linux, et la en plus le temps de compilation va être amusant.
      Comme je pense que je ne suis pas le seul à travailler avec des trucs de cet âge, je m'en remet à vous.

      Voila, idées, suggestions :)

      (je sais, c'est sans doute H.S.)

  • # Re: Noyau 2.6.3 dans les bacs

    Posté par  . Évalué à 1.

    J'ai bon espoir pour le framebuffer radeon :

    <akpm@osdl.org>
    [PATCH] add device id to radeonfb

    From: Andreas Steinmetz <ast@domdv.de>

    The attached patch adds the pci id 5961 to radeonfb. Without the patch my
    9200 displays only a blank screen. lspci output below.

    05:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV280
    [Radeon 9200] (rev 01) (prog-if 00 [VGA])
    Subsystem: Giga-byte Technology: Unknown device 4018
    Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 16
    Memory at e0000000 (32-bit, prefetchable) [size=128M]
    I/O ports at b800 [size=256]
    Memory at feaf0000 (32-bit, non-prefetchable) [size=64K]
    Expansion ROM at feac0000 [disabled] [size=128K]
    Capabilities: [58] AGP version 3.0
    Capabilities: [50] Power Management version 2

    Je compile ça ce soir :)

    • [^] # Re: Noyau 2.6.3 dans les bacs

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

      si tu veux utiliser le nouveau truc i2c du radeonfb, mets i2c support dans le noyau, sinon ca ne compile pas (en tt cas chez moi)

    • [^] # Re: Noyau 2.6.3 dans les bacs

      Posté par  . Évalué à 1.

      lup,
      bon ca marche chez moi, SAUF que :
      - quand je passe sous X et que je reviens en console c'est degeullasse (essayez de faire un clear par exemple)
      - et je n'ai pas trouve le bon mode avec mplayer pour passer en plein ecran (svga est en petit)
      et surtout n'essayez pas le mode vesa !!!!

      PS: je suivais le truc d'assez pret et c'etait bon en rc3.

      a+
      Kirin

      • [^] # Re: Noyau 2.6.3 dans les bacs

        Posté par  . Évalué à 1.

        a priori avec la sdl ca marche assez bien

        • [^] # Re: Noyau 2.6.3 dans les bacs

          Posté par  . Évalué à 1.

          rahhh trop fort, ca marche pas du tout, mais par contre ca me remet d'equerre mon pb d'affichage :)))
          excelent.
          bon sinon le pb d'affichage est connu et est pris en compte (cf kernel mailing list)
          A+
          et merci pour l'astuce pour remettre mon affichage d'equerre .
          Kirin

          • [^] # Re: Noyau 2.6.3 dans les bacs

            Posté par  . Évalué à 1.

            Pas mieux....

            Toujours un écran blanc au boot (avec radeonfb en module ausi...).
            Qd je load le module radeonfb l'écran (hors X) est illisible.
            C'est pas encore au point on dira.


            Et c'est impossible de compiler avec radeonfb en dur.

  • # Re: Noyau 2.6.3 dans les bacs

    Posté par  . Évalué à 1.

    Je passe ma vie à recompiler ;(

  • # Re: Noyau 2.6.3 dans les bacs

    Posté par  . Évalué à 1.

    Il ont retiré le support scanner USB (via le module scanner) ? Mais c'est quoi alors maintenent le bon module ? déja avec printer et usblp...

    • [^] # Re: Noyau 2.6.3 dans les bacs

      Posté par  . Évalué à 4.

      C'est censé être géré en userland via la libusb d'après ce que j'ai compris.

    • [^] # Re: Noyau 2.6.3 dans les bacs

      Posté par  . Évalué à 1.

      rm scanner.ko

      Je l'avais fait tout seul: il etait responsable non seulement du non fonctionnement de mon scanner, mais aussi d'un kernel-freeze lors du lancement de xsane !

      Ca tombe bien, je n'aurai pas a le re-supprimer a la prochaine version (flemme de decocher l'option)

      Le bonjour chez vous,
      Yves

    • [^] # Re: Noyau 2.6.3 dans les bacs

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

      Ca y'est, j'ai trouvé. On ne peut pas dire que la doc soit d'une clarté totale.

      C'est là :

      http://www.freecolormanagement.com/sane/libusb.html(...)

      Donc pour faire une doc relativement générique, il faut d'abord trouver l'id de son scanner :

      # cat /proc/bus/usb/devices
      ...
      T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
      D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1
      P: Vendor=04b8 ProdID=011b Rev= 1.00
      S: Manufacturer=EPSON
      S: Product=EPSON Scanner
      C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA
      I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      ...

      Ce qui compte, c'est Vendor=04b8 ProdID=011b

      Si c'est un epson comme moi, modifier /etc/sane.d/epson.conf et remplacer
      usb /dev/usb/scanner0
      par
      usb 0x4b8 0x11b (avec les bons id trouvé ci-dessus bien sur)

      Et ça doit déjà marcher en tant que root.

      Pour que ça marche en tant que user, appliquer la manip indiquée dans la page ci-dessus vu que ça n'est qu'un problème de droits sur le port (modifier /etc/hotplug/usb.usermap pour rajouter la ligne qui va bien et créer un script pour donner les bon droits).

      Dans mon cas :

      # tail -2 /etc/hotplug/usb.usermap
      # Epson Perfection 2400
      epson_scanner 0x0003 0x04b8 0x011b 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000


      Voilà :-)

      • [^] # Re: Noyau 2.6.3 dans les bacs

        Posté par  . Évalué à 2.

        argh !
        C'est pas très user-friendly ;)

      • [^] # Re: Noyau 2.6.3 dans les bacs

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

        A priori, modifier epson.conf n'est nécessaire que si le scanner est trop
        récent pour être reconnu par sane.

        Quand à moi, je n'ai pas réussi à faire marcher la machinerie des
        scripts hotplugs.

        Heureusement, on trouve sur

        http://www.abul.org/article121.html(...)

        un petit script (à lancer comme root bien sûr, par exemple à la
        fin des scripts de démarrage) qui permet de mettre les droits nécessaires
        pour les gens du groupe scanner:

        Si on a plusieurs périphériques Epson, il suffit de remplacer
        epson par l''identificateur du périphérique pour ne pas avoir de
        problème (on le trouve par exemple avec un lsusb).

        #!/bin/sh

        echo "Script à lancer dès qu'on connecte le scanner Epson perfection 1670"
        echo ""
        echo "Eric Seigne, le 14/01/2004 pour RyXéo: <eric.seigne at ryxeo.com>"

        echo "Droits avant:"
        ls -al `lsusb | grep Epson | cut -d ':' -f1 | awk '{print "/proc/bus/usb/"$2"/"$4}'`

        chmod g+w `lsusb | grep Epson | cut -d ':' -f1 | awk '{print "/proc/bus/usb/"$2"/"$4}'`
        chown :scanner `lsusb | grep Epson | cut -d ':' -f1 | awk '{print "/proc/bus/usb/"$2"/"$4}'`

        echo "Droits après:"
        ls -al `lsusb | grep Epson | cut -d ':' -f1 | awk '{print "/proc/bus/usb/"$2"/"$4}'`

        echo "Changement des droits terminé, vos utilisateurs membres du groupe scanner peuvent maintenant utiliser sane sans problème."

        • [^] # Re: Noyau 2.6.3 dans les bacs

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

          > A priori, modifier epson.conf n'est nécessaire que si le scanner est trop
          > récent pour être reconnu par sane.

          Il faut le modifier mais si sane est assez récent, il suffit d'indiquer usb.
          Sinon, il faut indiquer l'identifiant du scanner.

          Avec la 1.0.12, mon Perfection 2400 n'était pas reconnu directement.

  • # Samsung X10

    Posté par  . Évalué à 2.

    Quelqu'un a testé ce noyau avec le samsung X10 ? Pour l'instant, la gestion de l'ACPI ne marche pas à moins de patcher le noyau à la main et de charger la table DSDT modifiée avec initrd... Pas très pratique, hein !

    • [^] # Re: Samsung X10

      Posté par  . Évalué à 0.

      Salut,

      J'ai le meme portable que toi, et ca m'ennuie vraiment de devoir patcher le noyau, avec toutes les complications par dessus.

      En plus j'utilise une mandrake ce qui ne simplifie rien a l'affaire. Qu'est ce que tu as comme distribution ?

      Y a-t-il d'autres personnes qui ont un X10 ?

      • [^] # Re: Samsung X10

        Posté par  . Évalué à 1.

        Oui. un XTC 1400.

        Pour l'instant, je reste au 2.4.23 avec le acpi-dsdt-initrd-patch. De plus, j'utilise le driver eagle pour Free dégroupé et j'attends encore qqs versions de la branche 2.6 pour tenter un changement.

        Je viens de tester la dernière version des drivers Nvidia (ok, pas libre mais enfin l'accélération !)
        Vous avez réussi à faire fonctionner le modem interne et la carte Wifi ?

        • [^] # Re: Samsung X10

          Posté par  . Évalué à 1.

          En ce qui concerne le driver eagle, j'utilise une version CVS du driver un peu vieille (qques mois), et ça passe nickel en 2.6 avec free dégroupé

        • [^] # Re: Samsung X10

          Posté par  . Évalué à 1.

          J'ai le même, avec un 2.6.1.

          Je n'ai eu aucun problème pour l'ACPI. (pour le reste, c'était plus coton par contre)

          A partir d'une Mandrake 9.0, il m'a suffit de

          * installer les modutils + module-init-tools nouveaux. A la barbare; par-dessus les trucs installés par rpm. Attention, lire la doc (une option "-keep-old, ou qqch dans le genre...)

          * compiler un joli kernel 2.6.1 avec (de mémoire)
          - devfs
          - alsa
          - support pour chipset IDE Intel PIIX (pour avoir le dma, c'est
          plus rapide)
          - acpi

          Résultat, l'acpi marche toute seule (bon, pour moi ca veut dire que l'ordinateur peut s'auto-éteindre, ce qui me suffit). Après, il est possible de changer la fréquence, mais c'est advanced level, là:-)

          Par contre, c'est galère galère pour bien reconfigurer devfs; si vous y arrivez mieux que moi (et aboutissez à une configuration qui pourrait marcher avec le kernel original de la distribution et le 2.6.1), ca m'intéresserait.

          Sinon, usb, ca à l'air de marcher, carte réseau filaire ca marche bien, firewire, j'ai pas essayé. Eh ! Même le touchpad est reconnu (je ne sais pas pourquoi, mais mon kernel l'a reconnu ("Synaptic qqch, has extended capabilities," etc...) !!

          De toute facon, avant de faire la moindre install, j'utilise une knoppix avant pour qu'elle m'autodetecte tout le matériel !

          Pour le réseau sans fil... et bien c'est le problème des centrinos. Passez votre chemin, ou installez autre chose :-(

          Alexis


          PS. Par contre, et je sais pas comment deux traces (rayures courtes) se sont mises sur l'écran. Si quelqu'un à une idée.. ca à l'air délicat ces petites choses!

          • [^] # Re: Samsung X10

            Posté par  . Évalué à 1.

            pour tes rayures, je crois qu'il y a un défaut de fabrication des écrans sur certains modèles de samsung (une trace noire au milieu de l'écran). reste à savoir si c'est bien ça.

            Pour moi, j'ai un compaq presario X1000, et pas moyen de faire marcher l'acpi : il ne me trouve pas le niveau de charge de la batterie (c'est embêtant de s'entendre dire constamment qu'elle est vide) ; quelqu'un a la solution ?

            A propos des centrino : http://www.linuxant.com/driverloader/(...)
            J'ai téléchargé, par contre il refuse de me charger le module (mdk 9.2). y'en a -til chez qui ça a marché ?

            Et enfin, pour être général, quelqu'un a-t-il des conseils (patchs, etc...) à me donner pour faire bien marcher linux sur ce X1000 ? Merci

            Marc

            P.S : non, rien sur http://www.lea-linux.org/_src/redir.php3?url=http%3a%2f%2flinux-on-(...) ni sur lea-linux

            • [^] # Re: Samsung X10

              Posté par  . Évalué à 1.

              J'ai rien dit à propos de Linux on laptops : http://olivier.mondoloni.free.fr/indexcompaq.html(...)

              c'est tout frais apparemment ! Par contre rien sur ma batterie :-(

            • [^] # Re: Samsung X10

              Posté par  . Évalué à 1.

              pour tes rayures, je crois qu'il y a un défaut de fabrication des écrans sur certains modèles de samsung (une trace noire au milieu de l'écran). reste à savoir si c'est bien ça.


              Ca m'intéresse... tu as une référence ? Plutôt que d'attaquer le problème au Miror, j'aimerais bien me dire que c'était d'origine, et faire jouer la garantie... je suis parti de chez moi, je suis revenu: hop deux traces, horizontales, parfaitement alignées, que j'avais pas vues avant :-(

              Bon, j'ai fini d'embeter le monde. La prochaine fois, je reviens avec une config devfs complète pour Mandrake :-)

          • [^] # Re: Samsung X10

            Posté par  . Évalué à 1.

            Après, il est possible de changer la fréquence, mais c'est advanced level, là:-)

            Pareil, un 2.6.2 compilé avec le support de cpufreq -> marche nickel.
            Seul bemol, par defaut il tourne avec la fréquence minimale. Soit 400 MHz chez moi. J'ai mis une semaine à me rendre compte du truc :)

          • [^] # Re: Samsung X10

            Posté par  . Évalué à 1.

            Chez moi, j'ai des traces noires de temps en temps dues au clavier qui touche l'ecran.
            Pour retirer cela, j'utilise un produit pour laver les fenetres (tout simplement)

      • [^] # Re: Samsung X10

        Posté par  . Évalué à 2.

        J'ai une gentoo. En patchant le noyau l'acpi fonctionne (cherche HOWTO : Fix Common ACPI Problems sur les forums gentoo). Ce qui m'étonne, par contre, c'est que la table DSDT corrigée est disponible depuis des mois et qu'elle n'est toujours pas intégrée au noyau officiel ! (ni au noyau patché de gentoo, d'ailleurs).

        Sinon, si tu as une mandrake, j'ai entendu dire que la 9.2 était patchée. Pour être précis, la table DSDT n'est pas intégrée au noyau, mais ce patch permet de charger une table modifiée au démarrage avec initrd. Tu auras plus de renseignements ici :

        http://www.andreasgrau.de/index.php?lang:english;loc:x10;subloc:(...)

        et

        http://gaugusch.at/kernel.shtml(...)

        Tu trouveras également quelques infos sur les forums officiels de nvidia (il y a quelques utilisateurs du X10).

        Pour l'instant, j'essaye de faire fonctionner correctement speedstep. Ma carte Nvidia "fonctionne" enfin avec les pilotes du constructeurs -il y avait un bug qu'ils ont corrigé dans la dernière version-, mais elle n'apprécie pas la version 2.6.3 de linux. Elle va presque plus vite sans la 3D, et mon score avec glxgears est inférieur à 100...

  • # -mm

    Posté par  . Évalué à 1.

    Perso j'en reste à la série -mm ne serait-ce que pour le cfq

    • [^] # Re: -mm... et -ck !

      Posté par  . Évalué à 5.

      Ne pas oublier aussi que les -ck sont de retour depuis qlqs temps. J'avais testé le 2.6.1-ck3, et franchement s'était pas mal du tout. Ne pas oublier non plus d'utiliser schedtool et ionice avec si vous voulez complètement en tirer parti, et d'abuser du boot param elevator={as,deadline,cfq} pour tester les différences.

      J'ai jamais pu faire marcher le 2.6.2-ck1 par contre, mais j'ai jamais rien pu booter qui commençait par 2.6.2 de toute façon.

      Vu que ce problème, qui devait juste concerner mon matériel, est réglé depuis les premiers 2.6.3-rc, j'ai bon espoir pour en le 2.6.3-ck1, sorti lui aussi aujourd'hui: http://members.optusnet.com.au/ckolivas/kernel/(...)
      - am6: Autoregulates the virtual memory swappiness.
      - batch8: Batch scheduling.
      - iso2: Isochronous scheduling.
      - smtbase3: Base patch for hyperthread modifications
      - smttweak2: Tiny performance enhancements for hyperthreading
      - smtnice4: Make "nice" hyperthread smart
      - smtbatch4: Make batch scheduling hyperthread smart
      - cfqioprio: Complete Fair Queueing disk scheduler and I/O priorities
      - schedioprio: Set initial I/O priorities according to cpu scheduling policy and nice
      - sng204: Supermount-NG v2.0.4

      • [^] # Re: -mm... et -ck !

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

        Moi j'utilise le 2.6.2-ck1 depuis quelques jours avec un P4 3.0 C et j'avoue que je suis resté sur le cul quand j'ai vu l'efficacité de ce patch sur le ressenti à l'utilisation de tous les jours ! (je précise que j'ai toujours Seti@Home qui tourne donc je suis pile le public concerné par ce patch).

        Ma machine n'est pas précisément une brouette mais là, elle s'est transformée en fusée !!!

        Et comme le patch -ck pour le 2.6.3 vient de sortir : joie :-)

        • [^] # Re: -mm... et -ck !

          Posté par  . Évalué à 2.

          Ils servent à quoi les patches -mm et -ck ?

          • [^] # Re: -mm... et -ck !

            Posté par  . Évalué à 7.

            À se la péter sur les forums

            • [^] # Re: -mm... et -ck !

              Posté par  . Évalué à 4.

              Exactement, comme de passer au 2.6, ou de passer sous Linux même, toutes ces histoires de noyau et d'os c'est que de la frime, en fait ils sont tous pareil...

              • [^] # Re: -mm... et -ck !

                Posté par  . Évalué à 0.

                Pas vrai. Sur un portable le 2.6 c'est 10 fois mieux que le 2.4, qui gère très mal les économies d'énergie.

                • [^] # Re: -mm... et -ck !

                  Posté par  . Évalué à 1.

                  J'espere que je vais avoir une autonomie de 10 h alors.
                  Parce que déjà avec un 2.4 j'ai 3h15 d'autonomie en moyenne, sur une spec officielle de 3h :)

          • [^] # Re: -mm... et -ck !

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

            Pour faire une réponse plus intelligente que le gros malin ci-dessus, ça permet de corriger un GROS problème des P4 3.0 C.

            C'est vu comme un bi proc mais certaines unités de calcul et le cache sont partagés entre les 2 unités, ce qui en pratique veut dire que, contrairement à un vrai bipro, une appli qui tourne sur un des CPU peut effondrer les performances de celui qui tourne sur l'autre.

            Si toutes les taches avaient la même priorité, ça ne serait pas un problème vu que le P4 les ferait tourner du mieux qu'il peut, c'est à dire 1.1 à 1.2 fois plus vite que le même CPU tournant sans l'hyperthreading. (on ne gagne pas plus en activant l'HT mais c'est toujours ça de pris quand ça marche).

            Sauf que quand les priorités sont très différentes (genre Seti@Home en nice 19 et une tache sur le bureau en priorité 0) entre 2 taches en train de tourner, ça se passe très mal.


            Sur un monopro classique, la tache en nice 19 ne tourne quasiment plus quand une tache doit tourner en priorité 0.
            Sur un bipro, les 2 tournent à fond et c'est pas bien grâve.
            Sur un P4 HT, vu comme un bipro normal par Linux, il fait tourner les 2 taches à fond (toujours logique) et du coup la tache en priorité 0 se retrouve ralentie quasiment de moitié !

            Le but des patchs de Con Kolivas est de rendre le scheduler conscient de ce cas de figure en empéchant de tourner les taches de priorité inférieure sur l'autre CPU quand une tache de priorité supérieur à besoin de tourner.


            Bon, évidement, il n'y a pas que ça dans le patch CK.


            Pour la version en VO et expliquée plus clairement :

            http://members.optusnet.com.au/ckolivas/kernel/(...)

  • # Re: Noyau 2.6.3 dans les bacs

    Posté par  . Évalué à 0.

    wouiiiiiiin, les modules vmware patchés pour les noyaux 2.6 n'y compilent plus :/

  • # Re: Noyau 2.6.3 dans les bacs

    Posté par  . Évalué à 1.

    Salut,

    quelqu'un a-til déjà testé une Pinnacle PCTV Pro (nomenclature réelle marquée sur la boite de la carte) récente (exemple été 2003) sur les kernels 2.6.x ?
    parce qu'en 2.4.22-26 (sous Mandrake 9.2) ben j'ai toujours aucune chaîne sous XawTV (toujours écran bleu).

    Merci.

    • [^] # Re: Noyau 2.6.3 dans les bacs

      Posté par  . Évalué à 2.

      As-tu essayé de changer les options du module bttv?
      J'ai du le faire pour ma vieille MIRO, sinon écran bleu aussi...

      Mon /etc/modules.conf:
      options bttv card=1 tuner=3 gbuffers=4

      La liste des tuners et des cartes est disponible dans:
      /usr/src/linux/Documentation/video4linux/bttv/CARDLIST
      pour le 2.6:
      /usr/src/linux/Documentation/video4linux/CARDLIST.bttv,CARDLIST.tuner

      Pour pinnacle:
      card=1 - MIRO PCTV
      card=11 - MIRO PCTV pro
      card=39 - Pinnacle PCTV Studio/Rave
      card=52 - Pinnacle PCTV Studio Pro
      card=94 - Pinnacle PCTV Sat

      Pour l' ecran bleu chez moi ,il me semble que le problème venais du tuner...

      Je n'ai pas essayé sur le 2.6... mais ça doit être similaire.

    • [^] # Re: Noyau 2.6.3 dans les bacs

      Posté par  . Évalué à 1.

      pour la pctv rave (tuner mt2050) et le kernel 2.6.2, le tuner est reconnu, mais impossible de trouver les chaines avec scantv

      • [^] # Re: Noyau 2.6.3 dans les bacs

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

        Perso j'avais le même problème, mais avec tvtime il y'a un utilitaire du meme genre que scantv, mais qui peux passer en revue toutes les frequences et pas seulement celles definies dans un fichier. Et depuis, je capte les chaines de mon operateur cable...

        En plus, Tvtime est un excellent logiciel (et non, il ne fait pas le shtroupfage de c+)

        http://tvtime.sourceforge.net(...)

    • [^] # Re: Noyau 2.6.3 dans les bacs

      Posté par  . Évalué à 1.

      Moi j'utilise ma PCTV Rave avec le 2.4.22 j'ai du patcher le noyo avec les patches que j'ai trouvé sur le site de bttv. En fait le probleme c'est que le tuner est supporté mais le chanegemnt de freq du tuner ne fonctionne pas donc tu ne peux pas changer de chaine mais si j'avais une chaine avant de reboot je l'avai toujours meme avec le noyo non patché apres reboot

      • [^] # Re: Noyau 2.6.3 dans les bacs

        Posté par  . Évalué à 1.

        Ok, ben merci à tous.
        Je vois que c pas encore gagné d'avoir la télé avec une PCTV récente (2003) (très répandue) sous linux. C bien dommage. J'ai tout comme sous Win$ SAUF la télé. C rageant !

        Je vais quand même tester le post de petit_bibi avec son module conf, mais j'ai peu d'espoir vu que j'ai déjà testé pas mal de trucs.

        Je regarderai quand même le cardlist du 2.6.

        Merci.

  • # Re: Noyau 2.6.3 dans les bacs

    Posté par  . Évalué à -1.

    lo,

    hey ben moi je suis tjs a la version 2.6test6 .... je pense que je vais devoir me faire ca ce soir :p

    ++

  • # Wireless Cisco Airo 350

    Posté par  . Évalué à 2.

    Vu que je suppose que je suis pas le seul à avoir un Thinkpad T40 (le modèle intermédiaire de l'offre étudiante), je signale que la carte Cisco est maintenant supportée par le driver airo du kernel et qu'il n'y a donc plus besoin d'utiliser le drivers airo_mpi patché de chez monsieur Bellet.

  • # Re: Et le noyau 2.4.25 ? et la faille de sécu sur les anciennes versions?

    Posté par  . Évalué à 6.

    Bon en fait je viens de tomber sur un journal qui indique une faille de sécurité sur les noyaux précédents :

    http://linuxfr.org/~d0h/9534.html(...)

    Pour résumer : il y a une vulnérabilité dans le code de gestion de la mémoire dans le mremap(2).

    Corigé dans le 2.4.25 et 2.6.3 non affecté (nouvelle version de mremap)
    (voir les commentaires du journal pour plus de détails :)


    Je pense que ca peut-etre intéressant d'indiquer cela dans la news non?

  • # Re: Et toujours pas grand chose pour les laptop :(

    Posté par  . Évalué à 0.

    Ben oui, il y a pas mal de chose qui pourraient aider les heureux détenteurs de portables comme par exemple:

    - avec un S2R et S2D qui fonctionne (actuellement il y a 3 façons de faire et pas une ne fonctionne dans son intégralité) Par exemple sur 2 testées, j'ai eu des "oops".

    - une PM qui s'adapte à son environnement. Oui il y a un début de support mais perso pour économiser de la batterie j'ai été obligé de suivre et mettre en oeuvre une partie de ce howto: http://www.tldp.org/HOWTO/Battery-Powered/(...)


    Enfin ça va de mieux en mieux mais en bon râleur, je me plains quand même ;)

    (Note: il y a quand même des bonnes choses comme l'ACPI qui est de mieux en mieux)

  • # Re: Noyau 2.6.3 dans les bacs

    Posté par  . Évalué à 5.

    Personne ne semble s'etre rendu compte que cdrdao est passé en version 1.1.8 et supporte maintenant les graveurs ATAPI. Pour rappel la version 1.1.7 en cvs ne semblait supporter que les lecteurs ATAPI, et encore...

    Grace a cette bonne nouvelle, on va enfin pouvoir virer définitivement l'émulation SCSI qui était passée obsolète dans les 2.6 et qu'on était obligé d'activer tout de même faute d'outils derrière !

    Ah, et pour ceux que ça intéresse, le patch bootsplash ne fonctionne plus en 2.6.3 même en modifiant à la main les sources (fb.h) : ça plante grave le noyau au boot ! Un correctif est dispo via la mailing liste.

    Autre info et c'est passé inaperçu aussi, le 2.6.3 est fourni avec Alsa 1.0.2c, le dernier donc !

    Bon moi je fonce installer le patch ck1 qui semble nickel pour mon p-iv.

    • [^] # Re: Noyau 2.6.3 dans les bacs

      Posté par  . Évalué à 3.

      Je confirme tout ce que tu as dit et je me permets de rajouter que le -ck1 est vraiment bluffant en terme de perfs.

      Je l'ai mis en place hier soir sans grande conviction mais "juste pour voir" et vraiment un 2.6.3 de base contre un 2.6.3-ck1 (donc boosté), c'est le jour et la nuit.

      • [^] # Re: Noyau 2.6.3 dans les bacs

        Posté par  . Évalué à 1.

        Dans la config du noyau il faut modifier des choses particulières ?

      • [^] # Re: Noyau 2.6.3 dans les bacs

        Posté par  . Évalué à 2.

        pourrais(iez)-tu(vous) preciser ce en quoi le ck1 vous semble plus rapide (est plus rapide) ?

        est-ce une impression, quelque chose de mesurable, une difference dans les options de compilation (support d'une architecture/d'un processeur) specifique ou l'ajout de patchs/fonctionnalites ?

        Merci pour ces (futures) precisions

        • [^] # Re: Noyau 2.6.3 dans les bacs

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

          Tout est expliqué là :

          http://members.optusnet.com.au/ckolivas/kernel/(...)

          Une partie des patchs concerne surtout le scheduling sur Pentium 4 Hyper Threading ou la différence est vraiment flagrante mais même sur mon PIII du boulot, la différence est notable. Je ne pense pas qu'on gagne grand chose dans les benchs.

          J'ai fait tourner de vieux trucs genre LMbench et Byte Unix Bench ou le 2.6.3-ck1 apparait plus mauvais que le 2.6.2 de base qui lui même est plus mauvais que le 2.4.24...

          Sauf qu'a l'utilisation interactive, l'impression est complètement inverse, et de beaucoup ! Il faut toujours se méfier des benchs qui mesurent plus la performance absolue que l'interactivité.

    • [^] # Re: Noyau 2.6.3 dans les bacs

      Posté par  . Évalué à 1.

      ça fait longtemps que cdrdao peut marcher avec les graveur ATAPI : lors de la compilation tu peut choisir d'utiliser les biblioteques fournies ou utilisee celle de cdrecord. Et comme celle de cdrecord (et notament les dernieres qui on un support avance pour le 2.6) surporte l'ATAPI....

      D'ailleur je crois que c'est ce qu'il ont fait : mettre a jour les libs incluses. Donc c'est pas vraiement extraordinaire.

  • # Re: Noyau 2.6.3 dans les bacs

    Posté par  . Évalué à 0.

    Remarquons l'enorme travail de l'equipe de SuSE et de linux.org.uk

    Il fallait le souligner.
    Je vais tester ce noyau dès ce soir

  • # Re: Noyau 2.6.3 dans les bacs

    Posté par  . Évalué à 3.

    Tiens je me demandais... A quand le 2.7 ?

  • # Re: Noyau 2.6.3 dans les bacs

    Posté par  . Évalué à 0.

    Bon là je vais friser le hors sujet mais tant pis.
    J'ai un certain nombre de pb avec cette série de noyeaux et je ne sais pas trop d'où cela proviens donc si une ame charitable pouvais éclairer ma lanterne.
    1) impossible de monter un CD-ROM : un mount /mnt/cdrom me sort un joli "mount: wrong fs type, bad option, bad superblock on /dev/cdroms/cdrom0,
    or too many mounted file systems". Alors qu'un mount /dev/cdroms/cdrom0 /mnt/cdrom -t iso9660 fonctionne correctement.

    2) impossible d'obtenir un fonctionnement correct de pppd j'ai un "pppd was unable to register a discipline to line ttyS0"

    voila si quelqu'un à des idées.

    • [^] # Re: Noyau 2.6.3 dans les bacs

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

      Quelle distribution ? Tu pourrais nous filer la ligne correspondante du /etc/fstab ? Est-ce que "mount /mnt/cdrom -t iso9660" marche ?

      • [^] # Re: Noyau 2.6.3 dans les bacs

        Posté par  . Évalué à 1.

        voila la ligne de mon fstab
        /dev/scd0 /mnt/cdrom auto noauto,iocharset=iso8859-15,ro,user,nodev,umask=0,nosuid 0 0

        et non "mount /mnt/cdrom -t iso9660" ne fonctionne pas (erreur de syntaxe)

        mais "mount /dev/scd0 /mnt/cdrom -t iso9660" fonctionne lui

        • [^] # Re: Noyau 2.6.3 dans les bacs

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

          Essaie de mieux spécifier le système de fichier en remplaçant "auto" par "iso9660,udf"; et de ne pas spécifier le charset (enlever "iocharset=...").

          et non "mount /mnt/cdrom -t iso9660" ne fonctionne pas (erreur de syntaxe)
          ... J'aurais juré que cette syntaxe était valide... excuse moi.

    • [^] # Re: Noyau 2.6.3 dans les bacs

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

      1) ton fstab ne comprends pas ton /dev, mauvaise syntaxe ou tu n'as pas pris en compte devFS dedans.

      2) Souviens toi du kernel 2.4 et de PPP, pourrais bien être pareil, regarde les forums. Je peux pas te renseigner car mon ppp c'est du rp-pppoe sur un serveur en 2.4

      Steph

    • [^] # Re: Noyau 2.6.3 dans les bacs

      Posté par  . Évalué à 1.

      1 -> je suppose que le fs est compiler en modules...
      du dois avoir un pb avec de chargement automatique des modules...

      • [^] # Re: Noyau 2.6.3 dans les bacs

        Posté par  . Évalué à 2.

        oui, j'ai trouvé :
        /proc/sys/kernel/modprobe contenait /bin/true
        c'est le script d'init de ma Mandrake qui me fesais des blagues. j'ai corrigé pour y mettre /sbin/modprobe et tout est rentré dans l'ordre.

        Question subsidiaire est-ce que /proc/ksyms est toujours présent en 2.6 ?

Suivre le flux des commentaires

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