Journal 2.6.22 a tué HAL...

Posté par  .
Étiquettes :
0
9
juil.
2007
Enfin moi, je vais bien, mais mes développements...

Je tourne avec Fedora 7. J'ai téléchargé le kernel 2.6.22, je le compile et l'installe (tout en gardant le kernel par défaut de Fedora) en utilisant l'ancien fichier de config que j'avais utilisé pour le 2.6.21.4, actualisé pour le 2.6.22 (jsute quelques nouvelles options à actualiser, comme SLAB...).

Je relance l'ordi. Et puis le drame: lorsque j'insère une clé USB, mon périphérique bloc (/dev/sde) est bien détecté par le kernel en lui-même (grâce à dmesg), en revanche, hal (avec lequel je développe) l'ignore totalement (lshal | grep "sd" ne le trouve pas). En revanche, le périphérique système (sg6) est lui bien détecté par le kernel ET hal.

Évidemment, avec le kernel par défaut ou le 2.6.21.4, ça marche.

Donc, voilà, je fais ce petit journal pour vous prévenir, si d'aventures... Étant donné la fraîcheur du 2.6.22, je ne vais pas me casser la tête trop longtemps, retour au 2.6.21.

Une explication ? Qu'est-ce que j'ai loupé ? Est-ce eventfd ?

  • # Tentative d'explication

    Posté par  . Évalué à -9.

    Premièrement, compiler un noyau est compliqué. Il y a tant et tant d'options...
    Deuxièment, il y a peut-être un bug dans le 2.6.22. Ce sont des choses qui arrive et qui arriverons toujours.

    En trois, attend tranquillement. Fedora va probablement sortir rapidement (quelques semaines) un 2.6.22 pour F7.

    Conclusion : Ton journal est sans intérêt.

    • [^] # Re: Tentative d'explication

      Posté par  . Évalué à 10.

      Moi au contraire j'y vois un interet : Eviter a d'autres de subir la meme chose.

      • [^] # Re: Tentative d'explication

        Posté par  . Évalué à -9.

        C'est-à-dire ?
        Et s'il a fait une erreur dans la compilation ? Et si c'est spécifique à son hardware ?
        Pour toi, de son journal, il faudrait conclure qu'il ne faut pas utiliser 2.6.22 dès qu'on a une clés USB.
        La seule conclusion qu'on peut faire de son journal, est qu'il ne doit pas utiliser le 2.6.22. Et absolument que personne ne doit utiliser le 2.6.22 s'il y a une clée USB.

        Note qu'il ne donne pas les caractéristiques de sa clée USB et ni les options du noyau.
        Le 2.6.22 a été testé ! Si toutes les clées USB ne pouvaient pas marcher avec ça se saurait.

        > Eviter a d'autres de subir la meme chose.

        Ma clé USB ne marche pas sous Vista. Évitez Vista si vous ne voulez pas subir la même chose.

        • [^] # Re: Tentative d'explication

          Posté par  . Évalué à 4.

          non, il faut juste conclure qu'il faut se méfier, et que peut être on peut s'attendre à des soucis...
          l'info n'est pas enorme (c'est sur qu'on ne change jamais de kernel pour un tout neuf recompilé maison à l'aveuglette), mais toujours bonne à prendre.

          • [^] # Re: Tentative d'explication

            Posté par  . Évalué à 0.

            > non, il faut juste conclure qu'il faut se méfier, et que peut être on peut s'attendre à des soucis...

            C'est comme ça pour TOUS les noyaux !
            Tu peux donner une version de noyau sans bug ? C'est impossible.

            Si la version X marche pour ta config, passer à une version Y peut poser des problèmes. Que Y soit supérieur à X ou non.

            Ça a toujours été ainsi et ça le restera.

    • [^] # Re: Tentative d'explication

      Posté par  . Évalué à 10.

      En un: recompiler un kernel, je l'ai déjà fait des centaines de fois. Parfois des problèmes, le plus souvent très réussi.

      En deux: le 2.6.22 a quand même eu 7 RC - et ce problème serait passé sous silence ? Ça m'étonnerait. Je cherche toujours ce qu'il manque, et j'espère que d'autres n'auront pas ce problème en les prévenant (ce qui est marqué dans le journal, si tu l'avais lu...) et en donnant la solution (que j'espère trouverà.

      En trois: tout le monde n'utilise pas forcément du pré-consommé.

      • [^] # Re: Tentative d'explication

        Posté par  . Évalué à -4.

        T'inquiète pas, je sais aussi compiler noyau et je ne veux pas disuader les gens de le faire. C'est sympa à faire et "gratifiant" même si ce n'est pas aussi bénéfique qu'on le dit. Je veux que tu sois face à tes responsabilités. Si tu compiles un noyau et qu'il ne marche pas, ça peut venir de toi. Ceci ne te semble pas frappé du bon sens ?

        > j'espère que d'autres n'auront pas ce problème en les prévenant

        Fait un rapport de bug :
        http://bugzilla.redhat.com/
        http://bugzilla.kernel.org/

        > et en donnant la solution

        La solution à quoi ?
        A ton problème, avec ta clée USB (qu'on ne connait pas) et ta configuration de compilation (qu'on ne connait pas).

        Ce n'est pas parce que tu as un problème avec ta clée USB et ta configuration de noyau, que tout le monde va avoir un problème avec sa clée USB et sa configuration de noyau. Tu sera peut-être le seul à avoir ce problème ou alors qu'une poingnée de personne. Ce sont des choses qui arrivent. Et il y a peut-être plus de clée USB qui marchent sur 2.6.22 que sur 2.6.21. Tu n'as peut-être tout simplement pas chance. Tout nouveau noyau introduit des bugs (mais heureusement il en corrige plus qu'il en introduit).

        • [^] # Re: Tentative d'explication

          Posté par  . Évalué à -4.

          Plus bas il y a des http://www.chezmoicamarche.org/ .

        • [^] # Re: Tentative d'explication

          Posté par  . Évalué à 3.

          J'ai encore testé, avec plusieurs options, ça ne passe pas. Il semble que HAL perde un peu les pédales chez moi, alors qu'il est pourtant inchangé (j'ai rajouté 2 règles, mais qui ne touchent pas le sous-système USB, uniquement les périphériques optiques).

          J'ai utilisé le même fichier .config pour le 21.6 et le 22, le 21.6 est ok, pas le 22. Mes clés USB sont tout ce qu'il y a de plus standard (mass storage). J'en ai formaté une en y ajoutant une table de partitions, ça ne change rien (mode bloc, mode partition... rien).

          HAL, en fait, ne semble pas trouver les volumes présents (ce ne sont que des volumes FAT32). Un montage manuel passe, mais pas l'auto-détection.

          Ah oui, j'oublie, je n'utilise ni gnome, ni kde, donc pas de mount-manager, puisque j'utilise ivman (qui est actuellement désactivé, donc le problème ne vient pas de lui).

          Tout ça me fait penser à un problème que j'avais eu il y a 18 mois, lorsque le kernel avait cassé une compatibilité sur l'UMS (déjà). Une de mes clés était alors inutilisable (pas de partition détectée), alors qu'elle l'était parfaitement avec l'ancienne version du kernel.

          Je chercherais sans doute quand j'aurais un peu plus de temps à y consacrer, mais pour l'instant, je reste en 21.6.

          • [^] # Re: Tentative d'explication

            Posté par  . Évalué à 2.

            T'as fait tous ces tests. Très bien.

            Imaginons que tu ais aussi fait un rapport de bug et qu'un développeur ait dit que le problème vient, par exemple, du udev de F7 qui n'a pas été mis à jour pour 2.6.22 et qu'il faut installer le udev de Rawhide (ben oui, il n'y a JAMAIS de garantit de compatibilité ascendante dans Linux même entre versions mineurs !). Dans ce cas, le problème n'est pas Linux 2.6.22, mais F7 (je ne fais en aucun cas de l'ombre à Fedora, c'est une distribution que j'utilise et adore (actuellement j'utilise FC6 et c'est un vrai bonheur)).

            Les choses sont ainsi dans le développement de Linux. Un noyau 2.6.x peut marcher et un 2.6.(x+1) peut ne pas marcher sans que ça soit la faute au noyau. C'est archi connu et c'est pour ça que peu de distribution font des montées en version de noyau même pour des changements de versions mineurs. Fedora fait parti des rares à le faire. Et Fedora le fait avec beaucoup de prudence et d'expertise. Ils sont en mesure de savoir d'où vient le problème et s'il vient du noyau ou non. Et toi ? En tout cas pas moi.

            Tu n'as (et beaucoup) pas aimé mon ton. Mais, s'il te plait, à l'avenir fait un rapport de bug. Dire que pour 2.6.x+1, pour une distribution, pour une configuration, ça ne marche pas est sans intérêt. Les développeurs le savent que ça arrive de façon quasi systématique et ça ne remet en rien en cause la version 2.6.x+1. Par contre ils veulent des rapports de bug ! Et principalement ceux qui font des distributions (enfin d'adapter la distribution aux évolutions du noyau ou remonter le bug en upstream).

            > Je chercherais sans doute quand j'aurais un peu plus de temps à y consacrer, mais pour l'instant, je reste en 21.6.

            Fais un rapport de bug :-)
            Si possible fait un essai avec le noyau rawhide (la version précompilé, optionnellement en le compilant toi même). Tu trouveras sans difficulté un tutorial pour compiler un noyau fedora depuis un rpm si tu ne sais pas le faire. C'est important pour conserver les patchs de la distribution.

            Bien amicalement. Même très amicalement. C'est important les gens qui testent les dernières versions et je me félicite que tu ais cette passion et patience. Par ma part ce n'est pas mon kife actuellement (manque de temps).

            Bien amicalement, bon test.

            • [^] # Re: Tentative d'explication

              Posté par  . Évalué à 1.

              Tu nous fais tout un speech comme quoi son journal est soit-disant inutile, mais par contre après, voyant que tu t'es fait moinsser allègrement, allons-y franco dans la lèche hein ("Bien amicalement. Même très amicalement" ...).

              Par ailleurs j'aime bien les gens qui s'auto-congratulent comme ça. Pourquoi tu te félicites qu'il ait cette passion et cette patience, t'y es pour quelque chose ?

              • [^] # Re: Tentative d'explication

                Posté par  . Évalué à -6.

                Connard.
                Tu peux moinser ce commentaire.

                > Pourquoi tu te félicites

                C'est une expression. Ouvre un dico.

              • [^] # Re: Tentative d'explication

                Posté par  . Évalué à -7.

                Connard.
                Tu peux moinser ce commentaire. Ça t'en fera deux. T'es satisfait ?

              • [^] # Re: Tentative d'explication

                Posté par  . Évalué à 2.

                En même temps, sur le fond, il n'a pas tord. Les gens sont souvent intimidés par l'idée de faire un rapport de bug pour le noyau : c'est dommage. Si vous pensez n'avoir pas assez d'informations à reporter, les développeurs vous indiqueront comment obtenir les informations utiles.

                L'idéal serait peut-être que Grégory fasse un git-bissect, qui permettrai de trouver l'exact patch fautif. Bissecter entre les noyaux 2.6.21 et 2.6.22 (environ 7000 patches) demande 13 recompiles & reboots (+1 pour tester le 2.6.22 avec le seul patche fautif reverté). Un peu long (surtout les recompiles), mais pas insurmontable.

                • [^] # Re: Tentative d'explication

                  Posté par  . Évalué à 0.

                  Et en plus j'avais raison semble-t-il ( http://linuxfr.org/comments/849934.html#849934 ).

                  C'est très très probablement une erreur de configuration du noyau. Le "2.6.22 a tué HAL", devient "ma mauvaise configuration de 2.6.22 a tué HAL" voire "mon incompétence a tué HAL".
                  Bref, journal sans intérêt comme je l'ai dit dans mon premier commentaire.

                  Que ça n'empêche pas ThK de faire des tests. Mais son journal aurait dû être dans la section forum ou un autre site d'aide.

                  Que de moinssage pour avoir dit une quasi "évidence".

                  • [^] # Re: Tentative d'explication

                    Posté par  . Évalué à 1.

                    Ton évidence n'en est pas une, puisque cette option était activée depuis le début - j'avais fait mes recherches auparavant.

      • [^] # Re: Tentative d'explication

        Posté par  . Évalué à -2.

        > En deux: le 2.6.22 a quand même eu 7 RC

        En passant, Linux 2.6 n'a que des RC (politique choisi par Linus depuis quelques mois). Ce ne sont pas de "vrais" Release Candidat car il y a ajout de fonctionnalités. Linux 2.4 a des "vrais" RC.

        • [^] # Re: Tentative d'explication

          Posté par  . Évalué à 6.

          Hmmm, ce sont bel et bien des RC, puisque Linux laisse une fenêtre de deux semaines (environ) pour intégrées les nouvelles fonctionnalités, qui sont développées dans des branches à part.
          Ensuite, une fois la RC1 publiée, il n'y a que des corrections de bugs (cf la news http://linuxfr.org/2007/07/09/22676.html) et une stabilisation.

        • [^] # Re: Tentative d'explication

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

          Ah non, pas d'ajouts de fonctionnalités entre les RC. Les fonctionnalités, elles ont quinze jours pour arriver à compter de la sortie de noyeau. Après, on commence les RC, et les seuls commits autorisés, ce sont les corrections de bugs.
          Linux l'a d'ailleurs rappelé lors de la sortie de la RC2 du 2.6.22 :
          http://lwn.net/Articles/235086/

          • [^] # Re: Tentative d'explication

            Posté par  . Évalué à 1.

            Ça n'a pas toujours été vu...

            De plus, il faut définir RC. car RC1 chez Linux c'est souvent une beta (voire une alpha) dans d'autres projets. T'es OK sur ce point ?

            Pour beaucoup de projet, RC signifie que la version sans la moindre modification est une version finale potentielle. RC signifie, que pour les développeurs et en l'état actuel des tests, c'est une version finale. Qu'il n'y a que des tests utilisateurs qui peuvent changer cet avis. Pour Linux, c'est rarement le cas. Pour le 2.6.22, il semble (je n'ai pas suivi le développement de cette version) que les "vrais" RC étaient RC6 et RC7. Les RC précédentes était des beta/test.

            Pourquoi Linux ne fait que des RC ? J'ai oublié les détails, mais en gros l'objectif est de pousser aux tests. Si ce n'est pas labélisé RC, les gens ont tendance à ne pas tester. Le choix de Linus est très "psychologique".

            RC n'est pas l'unique synonyme de "seulement bugfix". Pour le projet Fedora à partir de test2 (suivit de test3 et parfois test4) il n'y a que des bugfix et ça appelle test et non RC. Il arrive exceptionnellement que Fedora sorte des RC (souvent semi-confidentielle) juste avant le finale pour vérifier qu'une modification de dernière minutes ne pose pas de problème. Et souvant cette RC est identique à la version finale officielle (au paquet fedora-release près).

            Linux a un usage particulier du label RC. Je comprend ce choix.
            Mais le projet Linux n'est pas le seul projet, ne dicte pas tout aux autres projets, etc...

            • [^] # Re: Tentative d'explication

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

              Je pense qu'on est relativement d'accord. Mon propos n'était pas de te contredire, juste d'apporter un précision.

              Les ajouts de fonctionnalités sur les kernel Linux ont lieu uniquement pendant les 15 jours suivants la sortie du noyeau précédent. Après commence le cycle des RC pendant lequel il n'y a plus que des corrections de bugs.

              Mais effectivement, les premières RC correspondent plus à des versions Beta, et n'ont pas pour prétention d'être des "candidats possibles pour la sortie d'une version stable".

  • # Chezmoiçamarche.org

    Posté par  . Évalué à 3.

    Sur ma machine ça marche en tout cas... J'utilise une Debian unstable.

    • [^] # Re: Chezmoiçamarche.org

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

      Pareil. Debian unstable, un kernel 2.6.22 compilé à la main hier soir, et une clef achetée hier aussi. Je viens de l'insérer, et KDE vient de m'ouvrir une fenêtre avec un certain nombre de choix en rapport avec la clef.

  • # Rawhide

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

    Essaye le 2.6.22 de la version développement de Fedora, peut être qu'ils ont un jeu de patch spécifique. Par ailleurs, redhat cherche de plus en plus à diminuer le nombre de patchs qu'il appliquent sur le kernel vanilla, il y en a en gros 150 actuellement, ils comptent diviser ce nombre par 3 en envoyant le plus de patchs possible upstream.

    • [^] # Re: Rawhide

      Posté par  . Évalué à 1.

      Bonne information.
      Mais en passant, la branche Rawhide n'est pas faite pour marcher sur une version stable de Fedora. Si ça marche (et ça arrive souvent) alors tant mieux.

      > Par ailleurs, redhat cherche de plus en plus à diminuer le nombre de patchs qu'il appliquent sur le kernel vanilla

      Red Hat a toujours fait ça contrairement à ce qui se dit. Il n'y a que pour RHEL où il peut y avoir beaucoup de patchs (Red Hat doit assurer la compatibilité binaire et source pour RHEL, ce que Red Hat ne fait pas (ou très peu) pour Fedora).

  • # Je ne peux résister...

    Posté par  . Évalué à -2.

    Désolé, mais..

    Bon, visiblement ça marche (désolé, mais en ce moment, je n'ai plus trop le temps de compiler des kernels, hélas... Mais rassurez-vous : demain matin j'irai me flageller en récitant 42 fois la GNU GPL sur la place publique).

    Je ne peux résister à faire ce jeu de mots pourri : 2.6.22 M'A TUER

    Sinon, pour redevenir sérieux, tu as peut être oublié une option, recompiles-le voir un coup, ça ne fait jamais de mal ;-)

    • [^] # Re: Je ne peux résister...

      Posté par  . Évalué à 1.

      J'avais failli mettre ce titre, mais trop racoleur à mon goût...

      J'ai recompilé, essayé plusieurs options... Ça ne passe pas. Le plus intrigant est que le même fichier .config est utilisé avec le 2.6.21.6 et le 2.6.22. Le 21 passe, le 22 cale.

      Et comme j'ai un peu l'impression d'être le seul à avoir ce problème, j'hésite encore à faire un rapport de bug, déjà que ces pauvres mainteneurs ont assez de boulot comme ça...

      • [^] # Re: Je ne peux résister...

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

        Et si t'essaye de recompiler hal?
        Ou que tu regardes si il se lance bien. Il marche tjs pour le reste?

      • [^] # Re: Je ne peux résister...

        Posté par  . Évalué à 1.

        > Le plus intrigant est que le même fichier .config est utilisé avec le 2.6.21.6 et le 2.6.22. Le 21 passe, le 22 cale.

        Désolé de te le dire, mais c'est une erreur. Linux ne garantit pas qu'un .config adapté pour la version 2.6.x marche pour 2.6.(x+1).
        Il faut donc revoir toute la configuration (avec "make menuconfig" par exemple) et tout contrôler. Pour faire ça bien il faut avoir en tête ce processus pour la version précédante afin de voir les évolutions et faire les adaptions nécessaires.

        > Et comme j'ai un peu l'impression d'être le seul à avoir ce problème, j'hésite encore à faire un rapport de bug

        Fait un essai avec le noyau 2.6.22 rawhide et la version précompilé. Si ça ne marche toujours pas, ton rapport de bug sera le bien venu (oui oui).

        NB : F8 aura un "mass rebuild" (changement de la toolchain et introduction d'incompatibilité). J'ignore si F8 (rawhide) a déjà fait ce "mass rebuild". S'il a déjà été fait, il est possible que le noyau rawhide ne marche pas avec F7 à cause du changement de toolchain, il est possible qu'il ne marche jamais sur F7.

        • [^] # Re: Je ne peux résister...

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

          Je dirais même plus qu'il faut faire un "make oldconfig" avant toute chose quand on copie un .config 2.6.x dans les sources 2.6.(x+1).

          • [^] # Re: Je ne peux résister...

            Posté par  . Évalué à 2.

            Fedora a un autre mécanisme dont j'ai oublié les détails (voir le fichier .spec du noyau qui est riche d'information et particulièrement bien foutu). Le système Fedora était prévu pour être upstream (c'est déjà fait ?).
            Quoiqu'il en soit, un "make oldconfig" n'est pas toujours satisfaisant (bien qu'il peut corriger quelques pépins automatiquement).
            Il faut le dire et redire, il n'y a pas de garantit de compatibilité ascendante dans Linux (aussi bien binaire que source). Linus c'est déjà exprimé au moins 2^73 fois pour expliquer les tenants et aboutissants de cette position. Si un noyau x+1 marche mal alors qu'un x marche bien, c'est "normal" (ou prévisible) s'il n'y a pas eu de réajustement (config noyau et/ou applis proches noyau (lspci, udev, etc)).

    • [^] # Re: Je ne peux résister...

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

      Attention, il faut réciter la GPLv3 maintenant!!!

  • # Solution ?

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

    D'apres
    http://forum.hardware.fr/forum2.php?config=hfr.inc&cat=1(...)

    Il faudrait utiliser CONFIG_USB_DEVICE_CLAS

    Cf http://readlist.com/lists/vger.kernel.org/linux-kernel/70/35(...)

  • # Solution trouvée

    Posté par  . Évalué à 2.

    C'est effectivement HAL (selon Fedora 7) qui était cassé:

    http://forums.fedora-fr.org/viewtopic.php?pid=179663

    Ma compilation du kernel était OK.

Suivre le flux des commentaires

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