Forum Linux.debian/ubuntu samba kernel lock up

Posté par  .
Étiquettes :
1
20
nov.
2012

Bonjour,

J'ai pris l'habitude, quand je veux regarder un film, de directement le lire sur le partage réseau samba de mon NAS.

J'étais vraiment content de ce système et tout fonctionnait très bien.
Ensuite j'ai décidé de faire un upgrade.
J'étais sous ubuntu 11.10 et je suis passé à 12.10.

Je remarque maintenant que de manière complètement aléatoire la lecture s'arrête.
Ce n'est pas vraiment un simple crash puisque d'après ce que je comprends c'est le noyau qui ne réponds jamais à un appel système et le processus reste bloqué dans cet état d'attente de la réponse système.
C'est gênant parce que la seule manière de résoudre le problème (aka tuer le processus) c'est de redémarrer la machine. Rien d'autre ne passe même pas "sudo kill -9 pid_du_vilain_mplayer ".

Je pense que c'est un problème lié au partage samba parce que le lockup c'est manifesté aussi bien avec totem, smplayer et vlc. Et uniquement sur des fichiers en réseau.

Est ce que quelqu'un à une idée de comment je pourrais trouver le problème et ce que je pourrais faire pour améliorer la situation.

Merci

  • # probleme similaire ici

    Posté par  . Évalué à 3.

    avec firefox, pour aller chercher une piece jointe qui se trouve sur le NAS

    il faut aller la chercher dans /run/user/monuser/gvfs/smb-share:server=stockage,share=mon-partage

    et là, ca part en cacahouete.

    alors je ne sais pas pourquoi c'est nommé comme ca mais c'est peut-etre la syntaxe du chemin qui pose probleme…

    • [^] # Re: probleme similaire ici

      Posté par  . Évalué à 2.

      Effectivement j'ai remarqué que le lien avait changé et que toute la partie après server était assez bizarre et problèmogène mais dans ce cas je ne comprend pas pourquoi ça fonctionne pendant une demi heure de film puis ça se plante tout d'un coup.
      Je regarde certain film sans problème et d'autre je n'arrive même pas à les lancer.
      Ce n'est pas un problème dans le nom de fichier parce que le problème touche des fichiers avec des nom qui ne contienne que de l'ascii bien standard.

  • # Solution de contournement

    Posté par  . Évalué à 3.

    sudo mount -t cifs ...
    
    
  • # backtrace or it didn't happen

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

    D'après ce que tu racontes, on a l'impression que tu as un mplayer qui se met en état D et n'en sort pas. Ça serait bien de commencer par vérifier sur quoi il bloque exactement. Selon le noyau, tu dois pouvoir obtenir un backtrace au niveau kernel via /proc/$pid/stack ou sysrq-t. Une fois que tu as confirmé que c'est Samba (et non le driver de la carte réseau, le device de swap ou des neutrinos), tu peux essayer d'obtenir une capture réseau (en commençant à capturer avant que le problème n'aparaisse) avec tcpdump par exemple. Après il s'agit de regarder à quel moment ça coince exactement et de déterminer si le problème est au niveau serveur ou client. Une fois cela fait, tu peux commencer à lire le code correspondant pour essayer de fixer le bug.

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

    • [^] # Re: backtrace or it didn't happen

      Posté par  . Évalué à 0.

      Ouf merci.

      Je finissais pas croire que je n'arriverais jamais à avoir le mot de la fin.

      Quelle commande exactement je dois faire tourner pour obtenir une stacktrace d'un processus ? Apparemment il faut gdb c'est ça ?

      Après je ne suis pas certain d'avoir des résultats tout de suite vu que pour le moment ça à l'air très aléatoire.

      Merci bcp

      • [^] # Re: backtrace or it didn't happen

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

        Quelle commande exactement je dois faire tourner pour obtenir une stacktrace d'un processus ? Apparemment il faut gdb c'est ça ?

        gdb c'est pour l'userland. Ça risque de pas beaucoup aider ici.

        Selon le noyau, tu dois pouvoir obtenir un backtrace au niveau kernel via /proc/$pid/stack ou sysrq-t.

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

        • [^] # Re: backtrace or it didn't happen

          Posté par  . Évalué à 0.

          sysrq-t n'est pas installé par défaut chez moi on dirait mais apparemment un simple cat sur /proc/$pid/stack suffit.

          Waiting for the bug ….

          • [^] # Re: backtrace or it didn't happen

            Posté par  . Évalué à 0.

            Bon tout vient à point à qui sait attendre.

            Alors dans un premier temps c'est totem qui a planté et j'ai essayé de relancer la vidéo dans vlc et smplayer mais ils se sont tous plantés à l'ouverture du fichier.

            Voici les différentes informations que j'ai pu extraire.

            la stack de totem
            la stack de vlc
            la stack de smplayer

            Ensuite, après un redémarrage totem c'est à nouveau planté au début de la vidéo (quelques secondes tout au plus) mais smplayer à fonctionné sans soucis.

            Ici il y a toutes les informations que j'ai essayé d'extraire de /proc/$pid/…
            la stack de totem autre crash
            fichier sched
            le fichier io
            le fichier maps

            J'ai également le pagemap, exe et environ mais c'est un peu plus compliqué à partager pcq ça affiche bcp de null dans les pastes. Si tu en as besoin je ferai les conversions nécessaires.

            Merci beaucoup pour vos lumières.

Suivre le flux des commentaires

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