Linux 2.6.8, suivi de près par Linux 2.6.8.1

Posté par (page perso) . Modéré par Florent Zara.
0
14
août
2004
Noyau
Linux 2.6.8 vient de sortir. Il apporte son lot de mises à jour, corrections, nouvelles fonctionnalités. Quelques heures plus tard, il a été suivi du 2.6.8.1, qui corrige un gros problème avec NFS et qui causait des «Oopses».
Le 2.6.8.1 n'est pas encore arrivé sur kernel.org, mais ne va pas tarder.

Mise à jour : Colin rajoute « attention, Linux 2.6.8 a un gros problème de fuite mémoire lors de la gravure de CD audios. Les utilisateurs de graveurs devraient attendre un 2.6.8.2. Alternativement, le dernier noyau exempt de ces problèmes est le 2.6.8-rc2. La liste des changements, comme souvent, est impressionnante. Elle comprend, entre autres, deux nouvelles plateformes ppc32 (e500 et 85xx), une mise à jour massive de l'architecture MIPS, quelques tonnes de réparations trouvées par sparse (Static Parser, un outil développé par Linus pour trouver les déréférencements de pointeurs user-space dans le noyau); les pilotes ne sont pas en reste, avec l'arrivée du support du chipset SATA d'nVidia, des mises à jour (bugfixes, optimisations) de différents framebuffers (radeonfb, rivafb, ...), des réparations du sous-système USB (Oopses, nettoyages de code, mises à jour de différents pilotes comme ceux des lecteurs de cartes, cdc-acm (modem GPRS), usblp (imprimantes), contrôleurs (ehci), ...).

Le 2.6.8.1 a quant à lui un Changelog beaucoup plus réduit: "[PATCH] Fix NFS client screw-up in fcntl f_op removal: Fix stupid thinkos in the fcntl f_op removal code." et répare un bug assez gênant trouvé juste après la sortie du 2.6.8.

Le patch 2.6.7-2.6.8 fait 4Mo, les changements continuent donc à arriver à un rythme soutenu. Cependant, la méthode de travail trouvée, avec le couple Linus Torvalds / Andrew Morton, fait ses preuves. Linux 2.6 est la branche la plus stable comparativement aux autres au même âge, tellement qu'un nouveau modèle de développement est envisagé, plus de changements dans la branche stable, avec les essais dans la branche -mm (celle d'Andrew Morton), et le 2.7.x n'est pas encore prévu.
  • # commentaires des journaux

    Posté par (page perso) . Évalué à 2.

    http://linuxfr.org/~Ayrton/14943.html(...)
    http://linuxfr.org/~Acetik/14946.html(...)

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Le bug NFS

    Posté par (page perso) . Évalué à 10.

    Ben en fait, je suis tombé dedans. Depuis un client en 2.6.8, je ne pouvais plus lancer un executable localisé sur un serveur NFS sans avoir un Oops (non crashant) du Kernel.

    La modif ne tient qu'a un seul caractère :

    http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.1/2049.html(...)

    --- 1.40/fs/nfs/file.c 2004-08-09 11:58:00 -07:00
    +++ edited/fs/nfs/file.c 2004-08-14 03:35:11 -07:00
    @@ -89,7 +89,7 @@
    int res;

    res = nfs_check_flags(filp->f_flags);
    - if (!res)
    + if (res)
    return res;

    lock_kernel();


    C'est fou ce qu'un petit ! mal placé peut faire comme boxon :-)
    • [^] # Re: Le bug NFS

      Posté par (page perso) . Évalué à 9.

      Ben en fait, je suis tombé dedans.

      Quand vous étiez petit? ;-) Comment faites-vous pour lire un changelog aussi gros, et décider d'installer un nouveau kernel en si peu de temps? Une telle réactivité m'épate autant qu'elle me conforte une fois de plus dans l'idée qu'il est rarement nécessaire de se jeter comme un mort de faim sur la toute dernière version d'un kernel.
      <Mode papy on> Ca n'est en rien le propre du kernel ou même de l'OS, il y a 20 ans déjà avec VMS sur PDP11 on attendait plusieurs semaines avant de valider un patch de l'OS. Et combien de fois cette règle nous a donné raison. </Mode papillon>
      • [^] # Re: Le bug NFS

        Posté par (page perso) . Évalué à 9.

        Parce que là, c'est sur mon PC et pas sur un serveur de prod que je l'installe et j'aime bien bidouiller :-)

        (et moi aussi j'ai été admin VMS depuis la V4.7 ;-)
      • [^] # Re: Le bug NFS

        Posté par . Évalué à 2.

        avec VMS sur PDP11

        Ah, ça a existé, ça ? J'ai toujours cru que VMS (Virtual Memory System) avait commencé sa carrière sur les VAX (Virtual Address eXtension)...

        tth.
        • [^] # Re: Le bug NFS

          Posté par (page perso) . Évalué à 4.

          Non, ça n'a pas existé. Le PDP 11 est basé sur un processeur 16 bits alors que le Vax (Virtual Adress eXtension) est un processeur 32 bits.

          l'OS des Vax, c'est VMS (et Ultrix, NetBSD, voire même Linux, entre autres)

          Les OS du PDP 11 sont RSX-11M (OS Tems réel), RSTS-11(Time Sharing, multi utilisateurs), RT-11(OS light, single user, temps réel), Ultrix-11 et éventuellement TSX/11 pour créer plusieurs machines virutelles RT-11.

          Y'a aussi un certain Tompson et un certain Ritchie qui on écrit un petit truc sur cette bécanne :-)
      • [^] # Re: Le bug NFS

        Posté par (page perso) . Évalué à 10.

        > Comment faites-vous pour lire un changelog aussi gros, et décider d'installer un nouveau kernel en si peu de temps?

        Parce qu'il y a eu des -rc qui fonctionnait trés bien avant

        > Une telle réactivité m'épate autant qu'elle me conforte une fois de plus dans l'idée qu'il est rarement nécessaire de se jeter comme un mort de faim sur la toute dernière version d'un kernel

        Et si tout le monde attends 3 semaines avant de tester un nouveau, ben c'est au bout de 3 semaines que le bug est découvert et ça fait un belle jambe a tout le monde.

        Au lieu de s'interroger sur pourquoi quelqu'un teste un noyau dés qu'il sort en se demandant s'il est pas mort de faim sur un ton légèrement pérojatif, il vaudrait mieux lui dire merci d'être aventurier et de tester le noyau afin que d'autres puisse l'utiliser sans risque et sans avoir à piquer une petite suée.
      • [^] # Re: Le bug NFS

        Posté par . Évalué à 4.

        Tout bêtement parce que souvent, il marche mieux (au moins dans une branche donnée).
        Exemple pour moi : l'accès au système de fichier ISO9660 a été modifié pour que l'option "cruft" ne soit pas utilisée par défaut pour des systèmes de fichiers de plus de 850Mo. Du coup, on peut lire correctement des DVD gravés sous Mac (je suppose que sous Mac, on peut graver en UDF mais mes interlocuteurs m'envoient régulièrement des DVD gravés en ISO).
        Voila, c'est pas grand chose, mais ça aide.

        De toutes façons, je garde toujours au moins un autre kernel qui marche. Si le nouveau est instable, je peux donc toujours revenir en arrière.

        Richard
    • [^] # Re: Le bug NFS

      Posté par . Évalué à -2.

      > C'est fou ce qu'un petit ! mal placé peut faire comme boxon :-)

      Houlà ! un troll sur la syntaxe du (à la) C qui débute ?
    • [^] # Re: Le bug NFS

      Posté par . Évalué à 1.

      j'propose :
      
      if (res=nfs_check_flags(filp->f_flags))
         return res;
      lock_kernel();
      
      c'est toujours ça de gagné...
      • [^] # Re: Le bug NFS

        Posté par (page perso) . Évalué à 2.

        Je trouve ça nul comme notation.
        Rien de tel pour tout embrouiller, et pour faire chier quand tu t'apperçois finalement que ton if tu veux le décaler 10 lignes plus bas.
        • [^] # Re: Le bug NFS

          Posté par . Évalué à 1.

          dans une recette de cuisine c'est plutot rare de te rendre compte qu'il faut faire cuire la pate avant de mélanger les oeufs et la farine...
          ----->[ ]
        • [^] # Re: Le bug NFS

          Posté par (page perso) . Évalué à 1.

          Pour ma part,je suis zéro en C.Mais j'ai suivi quelques introductions à la programmation.Je me demandais si vous parliez d'utiliser un correctif temporaire orienté objet plutôt que d'utiliser If.

          Si c'est possible répondre par message privée de templeet car je passe rarement sur DLFP et encore moin deux fois sur le même thread.

          Merci bien.

          sime le curieux
      • [^] # Re: Le bug NFS

        Posté par (page perso) . Évalué à 2.

        ça fait un warning gcc. Plus propre est de montrer que ton assignation dans un if est volontaire:

        if ((res=nfs_check_flags(filp->f_flags) != 0)
             ...

        ça fait une notation un peu lourde, du coup.
  • # et toujours pas de support natif de multideskOS...

    Posté par . Évalué à -7.

    Franchement je trouve que le couple Andrew/Linux n'en fait qu'à sa tête...

    ok... je sors par la porte des étoiles.. --------->[**]
  • # sparse

    Posté par . Évalué à 7.

    > quelques tonnes de réparations trouvées par sparse (Static Parser, un outil
    > développé par Linus pour trouver les déréférencements de pointeurs user-space
    > dans le noyau)

    Un peu limitatif. Je crois que sparse est destiné à être un peu plus que ça. Il devrait être un outil du genre du stanford checker, et repérer toutes sortes d'erreurs.
    Mais forcément, il faut lui dire quel genre d"erreur on cherche, et comment les trouver. Alors peut être que pour le moment, il est un peu limité.
    Par exemple, je crois que les erreurs o!=NULL dont il avait été question ici avaient été cherchées via sparse.
    • [^] # Re: sparse

      Posté par (page perso) . Évalué à -1.

      Est-ce que tu peux détailler un peu plus ce Sparse s'il te plait

      ps : sinon, je trouve regrettable que l'on puisse trouvé de la pub pour des téléphones portable sur la LKML : http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.1/0003.html(...)
      ca m'agace, encore plus quand ce sont des français
      • [^] # Re: sparse

        Posté par . Évalué à 5.

        (beaucoup de mailing lists sont pourries par les spammeurs. Ça ne veut pas dire que je ne trouve pas ça énervant pourtant ;)

        Ici, sur lwn : http://lwn.net/Articles/87538/(...) avec effectivement des commentaires sur les utilisations incorrectes de pointeurs en usermode. Mais il est surtout question d'interfaces (? backends?) pour le système. Et plus bas, il y a d'autres exemples (switch vides, constantes...).

        Et ici, sur les NULL :
        http://lwn.net/Articles/93574/(...)
        • [^] # Re: sparse

          Posté par (page perso) . Évalué à 1.

          oki d'accord, donc en gros c'est pour repérer des erreurs de code et autre code qui 'ne sert a rien et qui fait avoir un plus noyau qui marche moins bien' ?

          je jete un coup d'oeil a tes liens :)
          merci
          • [^] # Re: sparse

            Posté par (page perso) . Évalué à 3.

            D'après ce que j'en ai compris, c'est un outils d'analyse statique de code (d'où le nom, cqfd :).
            Le but de l'analyse statique est de repérer tout un tas d'erreurs de programmation en dehors de l'exécution, principalement : des déférencement de pointeur (NULL en particulier), du code mort (càd qui ne devrait jamais être exécuté, mais qui est quand même là), de l'analyse sur les boucles (valeurs utilisées...), etc...

            Bref, l'analyse statique est un outils très puissant, mais malheureusement complexe est qui a tendance à manger beaucoup de temps proc. Certains compilos l'utilise en particulier pour enlever le code mort ou remplacer des variables constantes par leur valeur, mais guère plus. Et on utilise alors un outils séparé si l'on veut aller plus loin.

            Il doit y avoir pleins d'autres info sur le net (regarder les cours d'ulm je crois, ou sinon chercher treillis, correspondance de Gallois, ce genre de choses)
      • [^] # Re: sparse

        Posté par (page perso) . Évalué à 3.

        Rien ne t'empêche de demander au numéro de téléphone joint la désinscription de la LKML, et de demander des précisions sur comment cette liste a été inscrite sans autorisation, patati patata.

        Disons Lundi à 10h du matin. tous ensemble...
      • [^] # Re: sparse

        Posté par (page perso) . Évalué à 4.

        Et moi ça m'agace de tomber sur du spam quand je lis dlfp. Peut être pourrait tu éviter de faire de liens sur des spams. C'est déjà un fléau suffisemment lourd à supporter pour que tu ne te sentes pas obliger de relayer ce genre de pourriels.
  • # Enfin une gestion correcte des touchpads synaptics !

    Posté par . Évalué à 6.

    Pour tous ceux qui ont un portable affecté du syndrome de la souris folle (vous savez, la souris qui traverse l'écran à toute berzingue en cliquant toute seule), il semble que ce noyau règle enfin ce problème.
    Testé sur 2 portables complètement différents en marque, âge, etc.

    Il s'agit des portables équipés d'une souris synaptics (voir cat /proc/bus/input/devices), qui perd la synchro de temps en temps (voir dans /var/log/messages s'il n'y a pas des messages du genre synaptics lost syn --- resync)

    Comme quoi, ça vaut le coup de se précipiter sur un kernel tout neuf, puisque ça fait au moins 3 ans que ce bug traînait et pourrissait la vie des utilisateurs de portables.
    • [^] # Re: Enfin une gestion correcte des touchpads synaptics !

      Posté par . Évalué à 2.

      Ça doit pas être tous les synaptics qui étaient touchés, parceque perso j'ai jamais remarqué quoi que ce soit d'anormal avec le mien (sur un thinkpad T40), et plus généralement je n'ai pas souvenir d'avoir lu quoique soit dans ce genre sur la ML linux-thinkpad depuis ~1an que j'y suis abonné (m'enfin bon, ça ça vaut ce que ça vaut, j'ai pu ne pas y prêter attention). Enfin tout ça pour dire que ça ne pourrissait pas la vie de tous les utilisateurs de synaptics, loin de là, ce qui explique peut-être que ton bug ait mis si longtemps à être fixé.
      • [^] # Re: Enfin une gestion correcte des touchpads synaptics !

        Posté par . Évalué à 3.

        Effectivement, ce n'est pas tous les touchpads de la marque qui sont touchés, mais le phénomène est assez répandu.
        Les symptômes sont un peu différents selon les machines et les versions du noyau/serveur X. Parfois, c'est assez discret. Le juge de paix, dans ce cas, est le fichier /var/log/messages
        Je n'ai pas d'expérience avec des IBM.
        Il y a eu des échanges récemment à ce sujet sur le noyau, et une modification a été faite dans le noyau 2.6.7, sans résultat pour tout le monde.
        Les deux machines défaillantes testées semblent bien fonctionner depuis hier (il y avait parfois plusieurs décrochages de la souris en une minute, d'autres fois un décrochage toutes les quelques minutes).
        Beaucoup de gens ne pensaient pas à faire remonter ce bug, hésitant entre une défaillance du matériel, un défaut du serveur X, etc.
        En tous cas, c'est un très ancien bug qui semble enterré.

        A+

        Gérard
    • [^] # Re: Enfin une gestion correcte des touchpads synaptics !

      Posté par . Évalué à 1.

      Cool !

      Quand j'avais testé le 2.6, dès que je bougeait la souris (ou le touchpad Synapsis) ben ça avancait de quelques pixels vers le haut (12 pixels ? dans ces eaux là mais la distance était fixe), puis de quelques pixels vers la droite, puis ça cliquait... puis ça recommençait tant que je l'utilisait. Si je relachait la souris était immobile.

      C'est ce bug là ?

      Bon par contre je vais encore attendre un bail pour passer au 2.6 (avec toutes les m***** que j'ai ma philosophie est devenue "tant que ça marche, touche surtout à RIEN").
      Sinon, reste un seul problème avant que je reteste un 2.6 : que le driver du modem Connexant marche. Là j'ai la dernière version beta (illégale ? peut-être) *gratuite*.

      À ce propos : ya du neuf ? Des personnes arrivent à l'utiliser sur le 2.6 (je veux dire à 56K réel : pas les 14.4k du shareware) ?
      • [^] # Re: Enfin une gestion correcte des touchpads synaptics !

        Posté par . Évalué à 1.

        Je dirais que ça se teste, mais là je pencherai plutôt pour un problème de sensibilité du touchpad qui aurait tendance à faire contact tout seul à un certain endroit.

        J'ai pu observer le problème du Synapsis à plusieurs reprises sur mon portable (un vieux Dell Latitude), et à chaque fois le symptome était le même : curseur qui se "téléporte" en haut à gauche de l'écran, et qui y reste bloqué quelques fractions de secondes (durée variable) avec parfois un clic gauche de la durée du problème.

        Ce qui m'a toujours le plus étonné c'est que ce bug se manifeste même si le touchpad n'est pas utilisé, par exemple en utilisant à la place une souris connectée sur le port PS/2.
    • [^] # Re: Enfin une gestion correcte des touchpads synaptics !

      Posté par . Évalué à 1.

      Bonjour à tous,
      Personnellement je me suis pas mal acharné sur le problème avec des 2.4, 2.6 et même le 2.6.8.1 me fait toujours pareil dans les logs :
      Aug 16 15:59:24 portable kernel: psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched.
      Aug 16 15:59:30 portable kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
      J'ai essayé différentes versions de synaptics et toutes font la même chose... A croire que mon portable a un touchpad "spécial" :(
      Par contre en effet on dirait que le pointeur saute moins, et c'est pas si mal ! Faudra juste penser à virer les logs encombrants un coup de tps en tps :)
  • # Problème cdrecord.prodvd

    Posté par (page perso) . Évalué à 1.

    Bon, j'ai rencontré un problème avec le 2.6.8 : impossible de graver un DVD avec cdrecord.prodvd (oui, je sais, sapusaipalibre mais j'ai pas le choix) avec un graveur IDE (Nec ND 2500).

    En le lançant en tant que root, il plante et en le lançant en temps que user avec cdwrap, il sort un message idiot comme quoi il n'arrive pas à "prevent media removal, SCSI sendcmd error" alors que j'utilise ATAPI...

    J'ai besoin de mon graveur et j'ai pas le temps de chercher donc retour en 2.6.7-ck6...

    Mais si y'en a que ça inspire... :-)
    • [^] # Re: Problème cdrecord.prodvd

      Posté par (page perso) . Évalué à 2.

      Y'a un thread monstrueux en cours avec Jorg Schilling (l'auteur de cdrecord / cdrecord.prodvd) et je sens qu'on est pas sorti de l'auberge pour le gravage...

      http://seclists.org/lists/linux-kernel/2004/Aug/index.html(...)
    • [^] # Re: Problème cdrecord.prodvd

      Posté par . Évalué à 2.

      Pourquoi n'utilise-tu pas les dvd+rw-tools ?
      • [^] # Re: Problème cdrecord.prodvd

        Posté par . Évalué à 2.

        même problème même graveur même avec dvd+rw-tools :)
        je repasse au 2.6.7
        • [^] # Re: Problème cdrecord.prodvd

          Posté par (page perso) . Évalué à 6.

          Argh... J'espère qu'on ne va pas être tenu trop longtemps en otages en 2.6.7 par cette histoire de graveur...

          Ca fait bien logntemps que la situation n'est pas claire du tout concernant le gravage sous Linux et ça c'est nettement empiré avec les graveurs de DVD. Y'a un jour ou il faudra que ça pête. C'est peut-être maintenant que ça va arriver...

          Quelque part, l'absence d'une appli GPL permettant de tout faire en gravage me gène bien plus que l'absence de driver 3D GPL pour les cartes ATI ou NVidia.

          Ces drivers sont closed source mais au moins ils sont suivi par de grosses sociètés qui maintenant y mettent les moyens alors que pour le gravage, ça ne tient qu'a une seule personne : Georg Schilling, qui n'est pas particulièrement coopératif. Il suffit de voir comment ça part en vrille dans LKML, rien que parce qu'il utilise mailx pour poster qui casse systématiquement les threads de discussion ou il participe....
          • [^] # Re: Problème cdrecord.prodvd

            Posté par . Évalué à -2.

            Cette application existe déjà et s'appelle k3b.
            • [^] # Re: Problème cdrecord.prodvd

              Posté par (page perso) . Évalué à 2.

              K3B n'est pas une appli pour graver mais un frontend qui sert à piloter les applis en ligne de commande qui gravent. Et, oh miracle, k3b utilise cdrecord/cdrecordprodvd,readcd et aussi growisofs.

              Retour à la case départ.
              • [^] # Re: Problème cdrecord.prodvd

                Posté par . Évalué à 1.

                oui je sais, mais je croyais répondre à qualqu'un demandant une appli simple et efficace qui fait que tout marche meme si on comprends pas comment ça marche....
                Je peux juste dire qu'avec k3b on grave tout sans problème, y compris les dvd, et donc que ça marche déjà facilement....
          • [^] # Re: Problème cdrecord.prodvd

            Posté par . Évalué à 4.

            Ah, oui, c'est le mec qui a décidé que tout ce que faisaient les programmers noyau c'était du pipeau, et que quoi qu'il arrive, on resterait en émulation SCSI tant qu'il serait le mainteneur de cdrecord?

            C'est lui les messages "l'interface atapi, c'est mal" et tout?
            • [^] # Re: Problème cdrecord.prodvd

              Posté par (page perso) . Évalué à 2.

              Voilà, c'est lui.

              Bon en fait, y'a moyen de s'arranger avec les versions de cdrecord patchées et les forks genre dvdrtools mais ça part un peu dans toutes les directions.
            • [^] # Re: Problème cdrecord.prodvd

              Posté par (page perso) . Évalué à 2.

              J'en sais rien, mais il a l'air d'avoir une de ces mauvaises fois !!
              Ca doit être ses 20 ans de connaissances de différents OS qui font cela!!
              Linus en est à plus de 10, espérons qu'il ne tournera pas ainsi ;-)

              Bonne journée.

              - Christophe
          • [^] # Re: Problème cdrecord.prodvd

            Posté par (page perso) . Évalué à 5.

            Heureusement, il y a libburn en développement au sein de freedesktop.org :

            http://icculus.org/burn/(...)
            • [^] # Re: Problème cdrecord.prodvd

              Posté par (page perso) . Évalué à 3.

              Ah ouais en effet à suivre. Mais comme le dit Jorg lui même cdrecord fonctionne sur plus de 30 plateformes différentes. Alors c'est pas gagné que libburn s'impose sous Linux.
              D'une parce que ce projet _semble_ jeune, de deux parce qu'il faudrait que les distributions changent leurs outils de gravure sous Linux et qu'aujourd'hui un environnement utilisateur dans lequel la gravure de CD-ROM ne fonctionnerait que partiellement serait dommageable.

              Maintenant à la vue de l'API, l'écriture de programme de gravure ne semble pas être d'une difficulté insurmontable.

              Christophe
              • [^] # Re: Problème cdrecord.prodvd

                Posté par . Évalué à 4.

                Je ne pense pas qu'il soit dommageable (du moins dans un premier temps) que cette lib ne fonctionne que sous linux (et peut-etre *BSD, voire meme Le Hurd), le principal probleme viendra du support par les differents front ends qui existent deja (K3B, X-CD-Roast, ...).
                Des que ceux-ci commenceront a supporter ce genre de librairies, les distributions inclueront le support, car il devient optionnel est peut etre utilise a cote des cdrecord & co.
                • [^] # Re: Problème cdrecord.prodvd

                  Posté par . Évalué à 5.

                  > le principal probleme viendra du support par les differents front ends

                  En même temps, je pense que quand libburn sera suffisament fonctionnelle, les différent frontends (existants ou nouveaux) se feront une joie de coder avec une vraie API plutôt qu'en parsant la sortie de cdrecord. D'autant plus si y'a des bindings qui font leur apparition, ce dont je ne doute pas (y'en a déjà au moins pour Ruby je crois).
                  • [^] # Re: Problème cdrecord.prodvd

                    Posté par (page perso) . Évalué à 2.

                    En effet : http://ruby-libburn.rubyforge.org/(...)

                    Et j'espère en effet que cette librairie fera son chemin à la vue de l'humeur de M. cdrecord. Peut-être qu'il a été pousser dans ses retranchements. Mais l'attitude qu'il abore sur le sujet de l'API du sous-système SCSI me fait un peu peur, compte-tenu, qu'il possède une grande connaissance dans le domaine(cdrecord est son bébé) et qu'il serait dommage qu'il arrête de se consacrer à la partie Linux de cdrecord.

                    Maintenant, je pense que je suis un peu parano.

                    --
                    Christophe.
          • [^] # Re: Problème cdrecord.prodvd

            Posté par . Évalué à 2.

            Quelque part, l'absence d'une appli GPL permettant de tout faire en gravage me gène bien plus que l'absence de driver 3D GPL pour les cartes ATI ou NVidia.

            Uh?
            cdrecord est GPL, dvd+rw-tools aussi.
            • [^] # Re: Problème cdrecord.prodvd

              Posté par (page perso) . Évalué à 3.

              Et cdrecord.prodvd qui permet de graver les DVD, non.

              Mais c'est vrai que maintenant, on peut quasiment tout faire avec dvd+rw-tools (à part les DVD Disk-at-once) donc la situation est moins bloquée qu'avant.
            • [^] # Re: Problème cdrecord.prodvd

              Posté par (page perso) . Évalué à 2.

              cdrecord est sous GPL mais il semblerait que la guerre soit déclarée dans LKML :

              http://lkml.org/lkml/2004/8/19/18(...)

              If no one has noticed yet, thanks to the additional license
              restrictions Joerg Schilling has added to cdrecord (due to this
              thread), it may be now moved to non-free in Debian in the near future.
              • [^] # Re: Problème cdrecord.prodvd

                Posté par (page perso) . Évalué à 2.

                Dans la 2.01a37, y'a un test anti Suse et noyau 2.6 et il est précisé qu'on n'a pas le droit d'enlever le test, ce qui me parait contraire à la GPL, non ?

                /*
                * You are not allowed to modify or remove the call to "linuxcheck()".
                * I am sorry that I am forced to do things like this, but defective
                * versions of cdrecord cause a lot of work load to me and it seems
                * to be impossible to otherwise convince SuSE to cooperate.
                * As people contact me and bother me with the related problems,
                * it is obvious that SuSE is violating subsection 6 in the preamble of
                * the GPL.
                *
                * The reason for including a test against SuSE's private
                * distribution environment is only that SuSE violates the GPL for
                * a long time and seems not to be willing to follow the requirements
                * imposed by the GPL. If SuSE starts to ship non defective versions
                * of cdrecord or informs their customers that they would need to
                * compile cdrecord themselves in order to get a working cdrecord,
                * they should contact me for a permission to change the related test.
                *
                * Note that although the SuSE test is effective only for SuSE, the
                * intention to have non bastardized versions out is not limited
                * to SuSE. It is bad to see that in special in the "Linux" business,
                * companies prefer a model with many proprietary differing programs
                * instead of cooperating with the program authors.
                */
                linuxcheck();

                if (flags & F_VERSION)
                exit(0);

                linuxcheck()
                {
                #if defined(linux) || defined(__linux) || defined(__linux__)
                #ifdef HAVE_UNAME
                struct utsname un;

                if (uname(&un) >= 0) {
                /*
                * I really hope that the Linux kernel developers will soon
                * fix the most annoying bugs (as promised). Linux-2.6.8
                * has still much more reported problems than Linux-2.4.
                */
                if ((un.release[0] == '2' && un.release[1] == '.') &&
                (un.release[2] == '5' || un.release[2] == '6')) {
                errmsgno(EX_BAD,
                "Warning: Running on Linux-%s\n", un.release);
                errmsgno(EX_BAD,
                "There are unsettled issues with Linux-2.5 and newer.\n");
                errmsgno(EX_BAD,
                "If you have unexpected problems, please try Linux-2.4 or Solaris.\n");
                }
                }
                #endif
                if (streql(HOST_VENDOR, "suse")) {
                errmsgno(EX_BAD,
                "SuSE Linux is known to ship bastardized and defective versions of cdrecord.\n");
                errmsgno(EX_BAD,
                "SuSE is unwilling to cooperate with the authors.\n");
                errmsgno(EX_BAD,
                "If you like to have a working version of cdrtools, get the\n");
                errmsgno(EX_BAD,
                "original source from ftp://ftp.berlios.de/pub/cdrecord/\n(...)");

                }
                #endif
                }
    • [^] # Re: Problème cdrecord.prodvd

      Posté par . Évalué à 3.

      J'ai réussi à effacer et graver un DVD en tant que root (Fedora Core 2 + 2.6.8.1)

      cdrecord -scanbus dev=ATAPI me donne
      ....
      ....
      0,0,0 0) 'LITE-ON ' 'COMBO LTC-48161H' 'KH0N' Removable CD-ROM
      0,1,0 1) '_NEC ' 'DVD_RW ND-2500A ' '1.07' Removable CD-ROM
      0,2,0 2) *
      0,3,0 3) *
      0,4,0 4) *
      0,5,0 5) *
      0,6,0 6) *
      0,7,0 7) *

      => cdrecord blank=fast dev=ATAPI:0,1,0 (effacement rapide)

      Par contre effectivement, en tant que user, cela se termine avec le même message que celui que tu mentionnes..

      NB : depuis le 2.6.7.1, gros changements dans la labellisation de tout ce qui touche aux unités SCSI (cf disques SATA).
    • [^] # Re: Problème cdrecord.prodvd

      Posté par . Évalué à 1.

      Si c'est le NEC ND2500A , tu peux mettre le firmware NEC ND2510A et ton graveur gravera sur des DVD double couche 9Go en plus des 4.7Go.
      Cherche sur google, plein de gens l'ont fait. Le plus dur est de trouver des DVD 9Go.
      • [^] # Re: Problème cdrecord.prodvd

        Posté par (page perso) . Évalué à 1.

        Oui oui, je sais, j'ai le firmware sur mon disque quasiment depuis que c'est sorti mais comme je ne suis pas encore tombé sur du média DL, je n'ai pas encore appliqué le truc, y'a pas le feu.
    • [^] # Re: Problème cdrecord.prodvd

      Posté par (page perso) . Évalué à 4.

      Plus que ça, j'ai un problème à graver des CDs (audio): le système prend toutes les ressources dispos, swappe comme un fou, et finit par mourir (ou équivalent, même un ssh n'aboutit pas). Le problème n'existait pas avec le 2.6.8-rc2 sur lequel je retourne.
      • [^] # Re: Problème cdrecord.prodvd

        Posté par (page perso) . Évalué à 3.

      • [^] # Re: Problème cdrecord.prodvd

        Posté par (page perso) . Évalué à 3.

        • [^] # Re: Problème cdrecord.prodvd

          Posté par (page perso) . Évalué à 4.

          h oui, pour ton problème, la même chose est décrite dans ces messages :
          http://lkml.org/lkml/2004/8/14/103(...)


          Oui, c'est moi ;)
          • [^] # Re: Problème cdrecord.prodvd

            Posté par (page perso) . Évalué à 4.

            Ah oui, c'est pratique LKML dis donc :-)

            Donc tu aura surement vu la solution (pas encore essayé moi même) :

            http://lkml.org/lkml/2004/8/16/104(...)

            Due to the newly added command filtering, you now need to run cdrecord as
            root. Since cdrecord will drop root privileges before accessing the drive,
            setuid root won't help.

            This means you will have to run cdrecord *and* k3b as root!

            IMHO it is more secure to simply disable filtering, and run the software as non-root.

            This patch restores the behaviour of previous kernels, security issues included:

            --- linux-2.6.8/drivers/block/scsi_ioctl.c~ 2004-08-16 14:16:57.000000000 +0200
            +++ linux-2.6.8/drivers/block/scsi_ioctl.c 2004-08-16 14:36:22.562908552 +0200
            @@ -196 +196 @@
            - if (verify_command(file, cmd))
            +/* if (verify_command(file, cmd))
            @@ -198 +198 @@
            -
            +*/
            • [^] # Re: Problème cdrecord.prodvd

              Posté par (page perso) . Évalué à 1.

              Je me réponds à moi même pour dire que ça n'est pas la peine d'essayer, je l'ai fait et ça ne corrige pas le problème. Je ne peux pas utiliser cdrecord, cdrecord.prodvd et growisofs (donc pas de xcdRoast ou de K3b), que ce soit en user ou en root avec le 2.6.8.1, même modifié avec le patch SCSI ci-dessus.

              Je vais attendre que ça se décante là...
              • [^] # Re: Problème cdrecord.prodvd

                Posté par (page perso) . Évalué à 3.

                Je suis un neuneu !!!

                En fait, j'avais mal appliqué le patch (fait à l'éditeur et j'ai oublié de commenter une des 2 lignes vitales).

                En fait, le patch fonctionne très bien et résoud le problème d'accès au graveur avec toutes les applis de gravage.


                A lire le dernier message d'Alan Cox dans LKML, ce patch n'est qu'une solution temporaire... mais bien utile !

                http://lkml.org/lkml/2004/8/16/130(...)


                Ca y'est, j'ai tout qui fonctionne en 2.6.8, elle aura été chaude cette mise à jour pour un noyau stable !
                • [^] # Re: Problème cdrecord.prodvd

                  Posté par . Évalué à 4.

                  Solution temporaire certes, m'enfin bon, ça fait jamais que remettre les chose dans l'état où elles étaient depuis des lustres avant le 2.6.8.

                  Tous ces embêtements viennent en fait de l'ajout d'un contrôle sur les commandes scsi, pour éviter que des utilisateurs ayant trop de droits (en gros, les utilisateurs du groupe cdrw sur pas mal de distribs) ne les utilisent pour fusiller le graveur. Bon, je veux bien croire que ce soit une avancée pour des machines en libre services, mais pour nos chez-nous respectifs on s'en fout un peu.

                  La solution à plus long termes, c'est d'avoir de mieux identifié l'ensemble des commandes sûres mais nécéssaires à une utilisation normale d'un graveur. La dernière fois que j'ai regardé aujourd'hui la lkml, il y en avait déjà une petite dizaine d'identifiées comme manquantes à la liste qui est dans le 2.6.8. Perso, je les ai rajoutées mais ça n'a pas suffit à retrouver un cdrecord pleinement fonctionel, donc j'ai finallement opté pour la solution temporaire qui désactive tout le contrôle. Au moins, ça marche.
                  • [^] # Re: Problème cdrecord.prodvd

                    Posté par (page perso) . Évalué à 3.

                    Ca ne m'inspire pas trop leur chasse aux identifiants nécessaires au gravage. Je sens qu'ils n'ont pas fini avec ça car, autant on peut imaginer que ça serait possible de mettre ça au point pour les graveurs causant à la norme MMC3 (tous les graveurs modems), autant les plus anciens graveurs qui n'utilisent pas cette norme risquent de se retrouver bloquer.

                    J'espère qu'ils en feront une option de compil (filtrer les commandes SCSI Oui/Non) comme ça, les paranos pouront activer ça si ça leur chante et pas les autres.
                    • [^] # Re: Problème cdrecord.prodvd

                      Posté par . Évalué à 2.

                      > J'espère qu'ils en feront une option de compil

                      Un contrôle dans /proc serait encore plus pratique, genre pour les désactiver on ferait :
                      # echo 0 > /proc/sys/dev/scsi/check_commands
                      Parceque les options de compil, c'est bien, mais c'est pas la panacée pour les gens qui utilisent le noyau de leur distrib (et là, je sais pas quel choix feraient des packageurs de distrib, mais ils ne pourraient pas faire le bon pour tout le monde).

Suivre le flux des commentaires

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