(Courriels de diversion: <differenciions@framboisier-grappilles.com> <tracta@infeste-cracherez.com> <repliee@carenees-dynamisait.com> <dominerent@feutrant-delestant.com> <distillerions@atermoiement-moqueront.com> <nomme@ethylique-destines.com> <presentez@orthographieraient-interviendrions.com> <abuserais@cingleront-desires.com> <pauperisons@renseignant-reelirions.com> <ressassait@ânonnent-necessaire.com> )
> > > > > "or" == Olivier Rossel <o-rossel@ti.com> writes: lf> c'est ce qu'on appelle le "kernel oops" or> C'est l'inique moyen de debugger le noyau? Savoir dans quelle or> fonction ca a plante? Il me semble que j'avais entendu parler or> d'options "Debug" pour le noyau. T'es au courant de ca? y'a plusieurs moyens amusants de débogguer un noyau: * le faire tourner en espace utilisateur, avec le patch user-mode-kernel, ce qui permet d'utiliser gdb, gprof etc directement. <URL:http://user-mode-linux.sourceforge.net/> * le kernel debugger, un patch développé par SGI, qui permet de positionner des breakpoints dans le noyau, de dumper les registres, générer des backtraces. <URL:http://oss.sgi.com/projects/kdb/> * le remote kernel debugger également développé par SGI, qui permet d'utiliser gdb pour s'attacher à un noyau s'exécutant sur une machine distante. <URL:http://oss.sgi.com/projects/kgdb/> * Encore un projet SGI (décidemment ils sont très forts), les kernel crash dumps, qui permet de forcer le noyau à sauvegarder un core en mémoire vive, faire un soft boot en disant au BIOS de ne pas initialiser la mémoire, et donc de pouvoir analyser le core avec gdb. <URL:http://oss.sgi.com/projects/lkcd/> -- Eric Marsden --------------------------------------------------------------------- Aide sur la liste: <URL:mailto:linux-31-help@savage.iut-blagnac.fr>Le CULTe sur le web: <URL:http://savage.iut-blagnac.fr/>