Le point commun de toute plateforme exploitée sous Linux, serveur, poste de travail, matériel embarqué, est sans aucun doute le noyau Linux.

Les tests ou la mise en œuvre de telles plateformes conduisent souvent à des messages plus ou moins compréhensibles du noyau tels que des oops, voire des situations de blocage total (panic) du noyau.

La formation au debug kernel propose d'explorer avec le participant les interfaces de communication avec le noyau et comment appréhender les messages reçus.

Elle propose également des outils et des méthodes pour collecter les informations nécessaire à la dernière phase qui consiste en l'analyse du problème rencontré.

Le participant est alors capable soit de corriger le dysfonctionnement soit de transmettre l'ensemble de ces informations au niveau compétent en faisant ainsi gagner du temps sur cette phase d'analyse.

Nos formateurs disposent de toute l'expérience pratique nécessaire, acquise lors de projets chez un éditeur de distribution mais aussi de par leurs contributions au kernel upstream.

Les objectifs

• Connaître les sources d'information relatives au fonctionnement du noyau Linux.
• Savoir collecter de manière exhaustive les informations liées à un dysfonctionnement du noyau.
• Savoir analyser les informations recueillies.

Pré-requis

• Connaissance du système Linux
• Programmation C
• Ordinateur portable sous Linux à apporter

Le programme de la formation Debug Kernel

Jour 1 : Prise en main du noyau et ses outils

• Connaître les différents systèmes de fichiers disponibles pour le debug
  • Systèmes de fichiers virtuels procfs, sysfs, debugfs
  • Stocker des informations de manière persistante avec pstore
    
• Debug user space
  • Récupérer un core dump
  • Utiliser gdb, Détecter des head corruption avec head et alloc
• Erreurs Kernel et dialogue avec le noyau :
  • backtrace
  • warn
  • Kernel tainted,
  • liste des flags,
  • oops
  • panic
  • bug
• Configurer son kernel pour améliorer le débug
  • Informations de debug
  • Activer kdump et kexec
  • Configurer les spin lock, mutex et bien utiliser les locks
  • Options de configurations liées à l'affichage de messages

Jour 2

• Les outils de debug kernel
  • system.map
  • Mettre en place une console série
  • Mise en place d'une netconsole
  • Utiliser qemu pour debugger
  • kgdb (port série)
  • crash / dump
  • De l'importance de l'appareil photo
  • Tracing avec ftrace
  • Quelques paramètres kernel utiles à connaître *Analyser les informations recueillies
  • Identifier les adresses mémoires avec addr2line
  • gdb
  • Un outil d'analyse dédié aux dumps kernel : crash
  • Outil d'aide à l'analyse : printk
  • Définir un format de message avec pr_*
  • Ajouter les noms de driver et devices aux messages avec dev_*
  • printk versus dev_* ?

Le(s) formateur(s)