Forum Linux.général Stabilite noyaux 2.6.9

Posté par  .
Étiquettes :
0
26
nov.
2004
Salut,

contexte: portable Acer Aspire, AMD Athlon, debian sarge, gcc-3.4

Avec le noyau 2.6.9 de base, la machine devient quasiment inutilisable lorsque 'slocate' tourne. Le truc zarbi, c'est que tous les processus apparaissent dans l'état 'waiting', et aucun dans l'état 'idle'.

J'ai essayé 2.6.9-ac10, puisque c'est le noyau de Fedora core 3. Après un bon moment, la machine s'est totalement bloquée sous X: image figée, plus de réponses au clavier, à la souris, ou via le réseau.

Il s'agit à chaque fois de noyaux téléchargés depuis www.kernel.org, je n'ai donc pas appliqué les patch spécifiques debian.

D'autres personnes ont elles expérimentés ce genre de désagréments ? Sous 2.6.8.1, no problemo.

Merci

CdM

  • # Noyaux kernel => pb de compilation.

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

    D'une les noyaux distribués par linus torvalds on de moins en moins vocation a etre utilisé 'tel-que'. Ils on délégués aux distributeurs une bonne partie du travail
    de stabilisation des noyaux.

    A mon avis tu a loopé une option genre support DMA ou connerie comme cela,
    mais je ne saurait trop te conseiller d'installer plutot les kernels fournis par debian. Ne serait-ce parce que la distribution postule que certains modules sont present et en tant que modules (meme si c'est moins problematique sur une deb qu'une mdk).

    • [^] # Re: Noyaux kernel => pb de compilation.

      Posté par  . Évalué à 3.

      J'ai oublié de préciser, mais j'ai utilisé chaque fois la même config. Donc, si j'avais raté une étape, cela devrait foirer pour chaque noyaux, ce qui n'est pas le cas.

      CdM

      Q: Why did the mathematician name his dog "Cauchy"?
      A: Because he left a residue at every pole.

  • # Pareil sur Mandrake Cooker

    Posté par  . Évalué à 4.

    Depuis quelques temps déjà, j'avais signalé ce problème sur les Mailing-lists Mandrake : lorsque le disque dur travail, on ne peut quasiment plus rien faire ! J'ai été quasi systématiquement flammé, soit disant que mes disques durs étaient mal configuré, certains allant même jusqu'à balancer que j'étais pas foutu d'utiliser hdparm.

    Mais je persiste, mes disques durs sont très bien configurés, (et ce par défaut, toute optimisation avec hdparm se solde soit par des performances équivalentes, soit moindres), et dès qu'un processus travaille sur le disque dur (msec, slocate, etc.), je constate une très nette dégradation des performances, et ce sur un Athlon 2200+ doté de 1 Go de DDR !

    Bref, cela fait plaisir de voir que je ne suis pas le seul à rencontrer ce problème et que je n'affabule pas :-)

    • [^] # Re: Pareil sur Mandrake Cooker

      Posté par  . Évalué à 2.

      Moi j'ai des soucis avec famd ... il se met à prendre 100 pour cent de cpu quand je télécharge un fichier par exemple ...

      ?

      • [^] # Re: Pareil sur Mandrake Cooker

        Posté par  . Évalué à 2.

        Quel proc stp ?

        Bizarrement, dans le message précédent, le processeur était un AMD Athlon, comme sur mon portable. Et le problème semble invraisemblable pour les autres contributeurs (qui n'ont probablement pas un Athlon).

        Donc: bug possible au niveau de gcc/noyau/cpufreq/powernowd avec la génération de code ou au niveau du CPU dans le cas des Athlon ?

        CdM

        • [^] # Re: Pareil sur Mandrake Cooker

          Posté par  . Évalué à 2.

          Non, ça me le fait aussi sur une autre machine que j'ai sous Cooker et qui est équipé d'un Pentium4 2.0 GHz.

          Je penche plutôt pour une gestion des IDE à chier. D'ailleurs, toutes les erreurs request sense failure: status=0x51 { DriveReady SeekComplete Error } et request sense failure: error=0x04Aborted Command sur une grande majorité de lecteurs CD-Rom ainsi que le très mauvais support du transfert DMA sur les lecteurs DVD sont là pour nous rappeler que le noyau 2.6 n'est pas encore au point.

Suivre le flux des commentaires

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