Forum Linux.noyau Comment débuguer un problème noyau?

Posté par  (site web personnel) .
Étiquettes : aucune
1
21
nov.
2010
Bonjour à tous,

j'ai un problème assez gênant avec mon ordinateur portable: environ une fois sur deux, il plante lors de la mise en veille. Le PC est alors bloqué, avec juste un petit curseur (non clignotant) affiché sur un écran noir. Les touches magiques REISUB ne marchent pas.

Il n'y a rien dans les logs, je suis donc complètement dans le noir. Comment obtenir une trace un peu plus complète de manière à pouvoir faire un rapport de bug utile?

Merci!

  • # pour analyser un pb système

    Posté par  . Évalué à 2.

    rien de mieux que d'avoir sous la main le dump d'un kernel.

    On fait avec certains systèmes proprio mais pas d'inquiétudes, ça existe aussi sous linux :

    http://lkcd.sourceforge.net/

    http://magazine.redhat.com/2007/08/15/a-quick-overview-of-li(...)

    Bon, je n'ai pas l'habitude de faire ça sous Linux, d'ailleurs j'utilise assez peu Linux, en revanche je sais utiliser les moteurs de recherche.

    A toi de voir le candidat le mieux adapté à ton besoin.

    • [^] # Re: pour analyser un pb système

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

      Merci pour ta réponse. C'est bien le genre de solution que je cherche, mais les pages que tu cites sont un peu anciennes...

      C'est pourquoi j’apprécierais que quelqu'un qui a l'habitude de le faire sous linux me recommande une solution actuelle :)

      • [^] # Re: pour analyser un pb système

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

        La solution actuelle pour obtenir un vmcore c'est kdump. Pour analyser le dump, c'est crash(8).
        Tu peux aussi obtenir des backtraces directement avec sysrq-t et sysrq-w (-w est seulement sur RHEL/Fedora je pense) mais si l'userland est freezé, ça va se retrouver sur la console (si elle fonctionne) mais pas dans les logs syslog (ou bien tu peux utiliser netconsole par exemple mais ça devient plus compliqué pour des résultats incertains).

        Voire kdump/kdump.txt et sysrq.txt dans la documentation du noyal.
        Pour crash(8) : http://people.redhat.com/anderson/crash_whitepaper/

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

        • [^] # Re: pour analyser un pb système

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

          Merci pour ta réponse!

          J'ai installé netconsole (non sans mal, il m'a fallu un moment pour trouver "dmesg -n8" et les options du noyau "debug" et "no_suspend_console" pour que ça logue correctement. Il faut aussi faire attention à tout firewall sur la machine cible :)) Maintenant ça logue bien, mais le problème ne se manifeste plus! Je vais attendre quelque jours pour voir s'il ne réapparaît pas soudainement...

          • [^] # Re: pour analyser un pb système

            Posté par  . Évalué à 2.

            bah le probleme se pose peut-etre quand justement tu passes du mode grpahique au mode console (framebuffer) ou quand ca coupe la carte reseau quand tu te mets en veille.

            comme tu ne desactive pas la console (ou la carte reseau) quand tu utilises netconsole, peut-etre que le bug ne se produit plus

            • [^] # Re: pour analyser un pb système

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

              Du coup je suis assez content parce que j'ai résolu mon problème, mais j'aurais quand même bien voulu aller au fond des choses... Tu as une idée?

              • [^] # Re: pour analyser un pb système

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

                kdump+sysrq-c (bis)

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

              • [^] # Re: pour analyser un pb système

                Posté par  . Évalué à 2.

                comme dit dans ma reponse precedente.

                sans activer la netconsole, ca plantait parfois
                avec la netconsole, ca ne plante plus

                du coup il faut voir du coté :
                - de la carte reseau (desactiver le module à la mise en veille, puis le reactiver au retour de mise en veille)
                - de la carte video (bascule en mode console avant mise en veille par exemple)

  • # driver supportant mal la mise en veille/resume

    Posté par  . Évalué à 6.

    ca ressemble à un driver video qui supporte mal le retour de mise en veille.

    tu as verifié en cherchant avec le modele de ta machine, de ta distrib, du driver video ?

    parfois il faut simplement ajouter le nom des modules dans la liste des modules à desactiver avant la mise en veille (et donc à remettre apres)

    et ca permet aux machines de se mettre en veille proprement.

  • # netconsole

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

    netconsole peut aussi t'aider pour récupérer les traces sur un autre PC de ton réseau local Ethernet.

Suivre le flux des commentaires

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