Journal Machine arrière toute, cap au 2.4.20 !

Posté par  (site web personnel) .
Étiquettes : aucune
0
20
juin
2003
-- Bien messieurs, je pense que nous pouvons célébrer le passage du cap vingt-et-un !
(Les officiers applaudissent.)
(Le mousse ouvre une bouteille de champagne et commence à remplir les coupes.)
-- Gloire au grand Linus !
-- Longue vie à Marcello, le Grand Stabilisateur Cosmique !
-- Mort aux papillons !
(Soudain, une sirène retentit.)
-- Commandant, nous venons de perdre l'accès à l'interréseau !
-- Comment ça, perdre ?! Scott ! Vous m'aviez garanti que votre autoreconnecteur était maintenant complètement opérationnel !
-- Commandant, cette sixième version ne peut pas planter. Il se passe quelque chose de fondamentalement inattendu !
-- Bien. Listez tous les processus, et passez-moi la salle des logs ! Et surtout, gardez un oeil sur la charge moyenne !
(Tous les officiers rejoignent leurs postes, mains sur les claviers, tous sens en alerte.)
-- Commandant, deux démons ppp sont en conflit ! Leurs encapsulateurs atm sont en vadrouille, et plus aucun paquet aal5 ne circule sur le bus universel !
-- Commandant, des pid sauvages ont été repérés en salle varrun !
-- Prenez un airème et allez me nettoyer ça. Scott, ça ne vous dit rien ?
-- Je ne comprends pas, la version six ne peut pas planter. Son système de verrou est incassable !
-- Commandant, ici la salle des logs. Debug et messages s'emballent sous la charge, et nous avons repéré des signaux de détresse dans syslog !
-- Laissez-moi deviner... Des cris de pppd et de pppoa3 dans debug, modem_run qui panique dans messages, et des pannes de bus universel dans syslog ?
-- Euh oui, Commandant. Comment...
-- L'expérience et l'intuition, mon petit.
(Le commandant jette un regard noir à Scott.)
(Scott prend le micro, quelque peu tendu.)
-- Ici Scott. Dîtes-moi ce que vous voyez dans speedtouch.
-- Speedtouch ? Il est assez calme... Oh, attendez, c'est étrange, on dirait qu'un conflit s'est engagé entre plusieurs instances ! Je n'avais pas vu ça depuis la version trois.
Mais ?! Il y a trois instances qui se battent !
-- Trois ? C'est du jamais vu, j'arrive.
(Scott tapote quelques coordonnées sur son seach-dihr personnel et disparaît des regards.)
-- Commandant, nous avons réussi à nous débarrasser des pppd fous. Nous avons dû faire usage du killall. modem_run a été abattu, également.
-- Quelle brutalité ! Utilisez des kill ciblés, la prochaine fois !
-- Nous manquions de temps, Commandant.
-- Commandant, ici Scott. Je suis en train de déchiffrer le speedtouch, c'est pas banal. J'ai une hypothèse, mais j'ai besoin de procéder à quelques expériences. Je requiert une déconnection physique de la raie manta.
-- Accordé. Déconnectez la raie manta.
(Deux hommes de la sécurité se lancent à l'extérieur du vaisseau. Plongeant au dalà de l'unité centrale, ils atteignent rapidement le hub externe.)
-- Déconnection effectuée.
-- Scott ?
-- C'est incroyable, tout bonnement incroyable ! Pourriez-vous reconnecter la raie manta ? Je dois vous prévenir, les démons vont être à nouveau libérés, il va falloir renettoyer.
-- Scott, si vous pensez que ça peut-être utile... Reconnection !
(La raie manta est reconnectée.)
-- Commandant, ici la salle des logs, l'activité a repris du plus belle !
-- Sécurité ! Tuez les démons, et nettoyez varrun !
-- Bien compris !
-- Alors, Scott ?
-- Eh bien, je n'aime pas dire ça, mais j'ai bien peur que le grand Marcello ait modifié la structure fondamentale de cette portion de l'univers.
-- C'est à dire ?
-- Tous les événements hotplug sont détriplés ! Quand la raie manta a été déconnectée, trois removers sont entrés en action ! Bon, ça, c'est pas trop gênant. Le coeur du problème, c'est qu'à la reconnection, trois starters entrent en conflit !
-- Je croyais que votre système de verrou résolvait ce problème.
-- C'est là le plus incroyable ! J'ai lancé quelques enquêteurs sur le terrain, et ils me rapportent qu'il se produit une chose... impossible ! Lorsqu'un starter est lancé, il vérifie si le verrou est présent, mais également s'il n'est pas trop âgé. Or, ce dernier test, qui fonctionnait parfaitement auparavant, échoue quand plusieurs instances du starter tournent en parallèle ! C'est impossible, mais c'est ce qui se produit.
-- Mmm... Bien. Nous ne pouvons nous permettre de continuer notre route sans accès à l'interréseau. Il va falloir avertir les Gardiens du Noyau, ainsi peut-être qu'aller allumer quelques cierges à Saint-Hotplug-sur-Dévaile. Machine arrière toute, cap au 2.4.20 ! Équipage, dès que nous serons de retour au 2.4.20, nous ferons escale à Linuxe-et-Fer ! Vous l'avez bien mérité !

  • # Re: Machine arrière toute, cap au 2.4.20 !

    Posté par  . Évalué à -1.

    Tu n'a plus qu a envoyer ton romand sur la mailing list Kernel..

    mais entre nous le 2.4.21 n'est pas stable.. c'est une branche Devel car 21 !

    Mais perosnnellemen je n ai aps eu de prob.. bon je n ais pas du tout meme matos que toi..

    le seul truc bizarre c'est que le rc8 échouais grave chez moi alors que le 2.4.21 a passé nickel... meme qu ils ont dit qui avais pas de changememt..

  • # Re: Machine arrière toute, cap au 2.4.20 !

    Posté par  . Évalué à 3.

    Mis à part mon commentaire sur la stabilité de la branche sur laquelle repose le noyau résultant de la consommation du produit de la cueillette des modules ...

    Voilà un journaux qu'il est bon, il en faudrait plus des journals du même style ...

  • # Re: Machine arrière toute, cap au 2.4.20 !

    Posté par  . Évalué à 6.

    Tout simplement palpitant !
    Je devrais lire mes logs plus souvent.

  • # Re: Machine arrière toute, cap au 2.4.20 !

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

    Pas beaucoup de rapport, mais j'ai aussi des doutes sur le 2.4.21. Ma machine de travail avait atteind 15 jours d'uptime fin mai (il a fallu que je la redémarre pour extraire un disque dur) avec le 2.4.21rc1. Et depuis impossible de dépasser 2 jours d'uptime sans freeze avec la rc7 et la finale.

    Il n'y a pas eu de modification de ma machine depuis plusieurs mois. Je ne vois que deux explication :
    - un bug dans la rc7 et la finale qu'il n'y avait pas dans la rc1
    - il fait plus chaud maintenant que fin mai, (aggravé par un léger overclocking)

    Il y'a deux jours j'ai nettoyé les ventilateurs de la machine, ce qui m'a permis de gagner quelques degrés de température CPU, et depuis pas de freeze. Je croise les doigts ...

    • [^] # Re: Machine arrière toute, cap au 2.4.20 !

      Posté par  . Évalué à 1.

      > - il fait plus chaud maintenant que fin mai, (aggravé par un léger overclocking)

      La voilà la réponse.

      Faire des tests de fiabilité avec un système overclocké !?!?.

      Utilise aussi memtest86.

      • [^] # Re: Machine arrière toute, cap au 2.4.20 !

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

        D'accord, l'oveclocking n'arrange pas les choses (même si pour moi la machine est 100% stable a ce niveau d'overclocking), mais entre un kernel qui dure 15 jours et l'autre 2 ...
        A moins que le 2.4.21 soit plus sensible à l'overclocking que ses prédecesseurs ? Ca serai bien étonnant ...

  • # L'impossible à la lumière crue du jour

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

    Quand même, c'est pas banal, donc en dehors de toute romanisation...

    Le script hotplug contient ça (entre plein d'autres) :

    MAX_LOCK_AGE=60
    log "currenttime: $currenttime" # récupéré à partir de 'date'
    log "timestamp: $timestamp" # récupéré dans le fichier lock
    if expr $currenttime '-' $timestamp '<' $MAX_LOCK_AGE; then
      log "Found a recent lock, exiting"
      exit 0
    else
      log "Found a stale lock"
    fi
    # Et on vire l'ancien lock, on créé le nouveau, etc.

    Le log contient ça (entre plein plein d'autres) :

    2003-06-20 13:06:02 starter-463: Trying to acquire the lock
    2003-06-20 13:06:02 starter-463: Creating lockfile
    2003-06-20 13:06:03 starter-496: Trying to acquire the lock
    2003-06-20 13:06:03 starter-496: currenttime: 1056107163
    2003-06-20 13:06:03 starter-496: timestamp: 1056107162
    2003-06-20 13:06:03 starter-496: Found a stale lock

    C'est quand même fou. Quand deux starters sont lancés à plusieurs secondes d'écart (sous 2.4.20), il n'y a pas ce problème :

    2003-06-20 10:29:46 starter-421: Trying to acquire the lock
    2003-06-20 10:29:46 starter-421: Creating lockfile
    2003-06-20 10:29:52 starter-489: Trying to acquire the lock
    2003-06-20 13:06:03 starter-496: currenttime: 1056097792
    2003-06-20 13:06:03 starter-496: timestamp: 1056097786
    2003-06-20 10:29:52 starter-489: Found a recent lock, exiting

    • [^] # Re: L'impossible à la lumière crue du jour

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

      2003-06-20 13:06:03 starter-496: currenttime: 1056097792
      2003-06-20 13:06:03 starter-496: timestamp: 1056097786

      Très foireux ce copier/coller, honte à moi ! Bon, j'avais pas envie de rebooter pour regénérer des valeurs et un comportement que je connais bien.

      Bon, il ne me reste plus qu'à aller expier ma faute... en week-end. Anniversaire, fête de la musique, fête du cinéma, yess !

  • # Re: Machine arrière toute, cap au 2.4.20 !

    Posté par  . Évalué à 2.

    EXcellent ce journal...
    Autant l'Entreprise était vieillissante.. autant ce journal fait souffler un p'tit vent frais ;o@

    Mais tout ça me rappelle un peu les mésaventures kernel avec le patch preemt-low-latency sur le 2.4.20 sur x86
    patch -> 3 CD pourris au gravage -> impossible de graver quoique ce soit -> retour au 2.4.20 ... depuis plus de problème, de ce côté au moins...
    Maintenant j'ai juste un souci côté PPC avec la mise en veille sur la mire du login... crash -> perte des consoles -> reboot... mais je soupçonne ce cher pmud...
    Et pis il suffit de se dépêcher de se loguer après tout ;o#

  • # Re: Machine arrière toute, cap au 2.4.20 !

    Posté par  . Évalué à 1.

    Dommage, vraiment dommage.
    Les tests noyau il faut les faire AVANT la sortie offcielle. Durant la phase rc (il y en a eu 8 !) qui a été particuliairement longue :
    rc1 : 14 avril
    finale : 13 juin

    2 mois de test pour rien car TA config avec 2.4.21 ne marche pas.

    Ça mérite un journal ?
    Faut-il que j'alerte les média ?

Suivre le flux des commentaires

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