Forum Linux.debian/ubuntu Problem mv ou make dir blocue en status D (uninterruptible)

Posté par  .
Étiquettes : aucune
0
25
nov.
2008
Régulièrement (maintenant presque 1 fois pas semaine)

lorsque je fait des action sur mes fichiers genre mv ou mkdir,
le processus ce bloque en stat D ou D+ (cf ps).

Quelqu'un aurait-il une idée pour savoir d'ou vient le problème?
est-ce un disque qui lâche ou un contrôleur disk, la ram, carte réseaux ou un bug ds le kernel?

Connaîtriez vous au moins in moyen de savoir quelle évènement attend le processus ?

Ps: j'accède toujours a la machine par un ssh+putty.

Machine:
Debian etch
Dell 512Mo ram
Intel(R) Pentium(R) 4 CPU 2.40GHz
120Go en IDE
500Go en Sata

Merci d'avance

  • # Pénible, les « D ».

    Posté par  . Évalué à 2.

    Ça arrive généralement quand le lock se produit dans une routine du noyau. C'est pas forcément un bug mais c'est par principe ininterruptible.

    Un cas typique est un stall du NFS. Le réseau ne répond plus, mais son traitement se fait en dessous du VFS et est donc masqué aux yeux du processus. Il se peut donc que ça se débloque tout seul, au bout d'un timeout.

    • [^] # Re: Pénible, les « D ».

      Posté par  . Évalué à 1.

      il reste ploquer plusieur jours, le seul moyen ke j'ai trouver de les debloque est un reset du pc le reboot ne marche pas non plus.

      Note:par exemple j'ai fait un mkdir /home/toto/abc/dfg
      Le mkdir reste bloqué
      et maintenant des que je rentre dans le repertoire /home/toto/abc le processus ce bloque luis aussi en "D" du coup ca va en s'enpirant et a la fin le pc est complement geler.

      • [^] # Re: Pénible, les « D ».

        Posté par  . Évalué à 2.

        Ça m'est arrivé aussi : c'est le signe d'un pilote du noyau buggé.

        En ce qui me concerne, c'était le pilote de ma carte Wifi (ACX) expérimental qui était en cause. Je me suis résolu à utiliser ndiswrapper. Dommage, mais stable, et en plus mon iwlist wlan0 scan fonctionne.

        • [^] # Re: Pénible, les « D ».

          Posté par  . Évalué à 1.

          de memoire justilise ke les drivers fourni par debian.
          Exepcter celui du scaner mais il n'est pas branché ... donc pas chargé ?
          Mais apres demontage de mon pc g vu un capa ki avai l'air morte (le haut bonbé).
          Je viens de la changé je vais donc voir si c bien ca le problem...

          • [^] # Re: Pénible, les « D ».

            Posté par  . Évalué à 2.

            Si c'était hardware à ce niveau-là, tu aurais des plantages généralisés, pas des processus D !

            Que les pilotes fournis soient « ceux de Debian » n'est en rien une garantie : c'est le pilote libre qui plantait, dans mon cas. Et le fait que ton scanner ne soit pas branché ni signifie pas non plus que ses pilotes ne seront pas chargés au démarrage.

            Essaie de blacklister les deux et de travailler quelque temps comme çà.

            • [^] # Re: Pénible, les « D ».

              Posté par  . Évalué à 1.

              mon probleme arrive ke tres rarement,
              c la 3eme fois kil me le fais:
              1ere fois aout,
              2eme debut nov
              3 fin nov

              et comme par hazard sur est acces disk gourmant lors de copy de gros fichers (600Mo).

              De plus la capa morte etait juste a coté du controlleur ide et sata + carte reseaux (bref le south bridge).

              enfin d'apres ce ke g vus sur le net une des seul raison de passer un processe en interruptible est kil attent un I/O disk (voir du net).

              Je veux bien te croire, mais bon la panne etant tres rares il va falloir attendre pour la verifier

              • [^] # Re: Pénible, les « D ».

                Posté par  . Évalué à 1.

                Bon c'était pas ca! :( ca a recommencé :(

                etant donné ka laire de la faire que sur un disk et c le seul en JFS,
                Je vais le passé en XFS et je verai :(

  • # pdflush aussi en meme temp

    Posté par  . Évalué à 1.

    Joubliai pdflush bloque en meme temp (stat D)

Suivre le flux des commentaires

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