https://www.kernel.org/doc/html/latest/admin-guide/README.html
Docs » The Linux kernel user’s and administrator’s guide » Linux kernel release 5.x ＜ http://kernel.org/ ＞
If something goes wrong
If you have problems that seem to be due to kernel bugs, please check the file MAINTAINERS to see if there is a particular person associated with the part of the kernel that you are having trouble with. If there isn’t anyone listed there, then the second best thing is to mail them to me (torvalds at linux-foundation.org), and possibly to any other relevant mailing-list or to the newsgroup.
Si vous avez un problème que vous pensez être dû à un bogue dans le noyau, vérifiez le fichier MAINTAINERS pour voir s'il y a des personnes spécifiques associées à certains des noyaux problématiques. Si personne n'y figure, la deuxième meilleure chose est de me contacter (Torvalds sur linux-foundation.org) et éventuellement d'autres listes de diffusion ou groupes de discussion connexes.
In all bug-reports, please tell what kernel you are talking about, how to duplicate the problem, and what your setup is (use your common sense). If the problem is new, tell me so, and if the problem is old, please try to tell me when you first noticed it.
Pour tous les rapports de bogue, veuillez me dire à quel noyau il est, comment reproduire le problème et comment le configurer (en utilisant le bon sens). Veuillez me faire savoir si le problème est nouveau. Si le problème est obsolète, veuillez nous en informer lorsque vous l'avez remarqué pour la première fois.
If the bug results in a message like:
Si le bogue provoque le message suivant:
unable to handle kernel paging request at address C0000010
Oops: 0002
EIP: 0010:XXXXXXXX
eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx
esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx
ds: xxxx es: xxxx fs: xxxx gs: xxxx
Pid: xx, process nr: xx
xx xx xx xx xx xx xx xx xx xx
or similar kernel debugging information on your screen or in your system log, please duplicate it exactly. The dump may look incomprehensible to you, but it does contain information that may help debugging the problem. The text above the dump is also important: it tells something about why the kernel dumped code (in the above example, it’s due to a bad kernel pointer). More information on making sense of the dump is in Documentation/admin-guide/bug-hunting.rst
Vous pouvez également dupliquer exactement les informations de débogage du noyau à l'écran ou dans le journal système. dump peut être déroutant pour vous, mais il contient également des informations utiles pour le débogage. Le texte sur le vidage est également important: cela vous dira pourquoi le code de vidage du noyau a été causé (dans l'exemple ci-dessus, il a été causé par un pointeur de noyau incorrect). Documentation pour plus d'informations sur ce que signifie le vidage. Il se trouve dans /admin-guide/bug-hunting.rst.
If you compiled the kernel with CONFIG_KALLSYMS you can send the dump as is, otherwise you will have to use the ksymoops program to make sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred). This utility can be downloaded from https://www.kernel.org/pub/linux/utils/kernel/ksymoops/ . Alternatively, you can do the dump lookup by hand:
Si vous compilez le noyau avec CONFIG_KALLSYMS, vous pouvez envoyer le vidage tel quel. Si ce n'est pas le cas, vous devrez utiliser le programme ksymoops pour détecter le vidage (bien que CONFIG_KALLSYMS soit généralement recommandé). Vous pouvez télécharger cet utilitaire à partir de https: // www.kernel.org / pub / linux / utils / kernel / ksymoops /. Vous pouvez également effectuer manuellement une recherche de vidage.
In debugging dumps like the above, it helps enormously if you can look up what the EIP value means. The hex value as such doesn’t help me or anybody else very much: it will depend on your particular kernel setup. What you should do is take the hex value from the EIP line (ignore the 0010:), and look it up in the kernel namelist to see which kernel function contains the offending address.
Lors du débogage d'un vidage comme celui ci-dessus, il est très utile de pouvoir découvrir ce que signifie la valeur EIP. La valeur hexadécimale elle-même n'est pas très utile pour moi ou pour quiconque. Cela dépend de chaque configuration du noyau. Tout ce que vous avez à faire est d'obtenir la valeur hexadécimale (0010: ignoré) de la ligne EIP et de la rechercher dans la liste de noms du noyau pour voir quelle fonction du noyau contient l'adresse incriminée. Les nombres eux-mêmes n'ont aucun sens, car les informations d'adresse peuvent changer en raison des options de compilation, etc. Le problème est que vous avez besoin des informations d'adresse pour déterminer quelle fonction / quel code est à l'origine du problème. )
To find out the kernel function name, you’ll need to find the system binary associated with the kernel that exhibited the symptom. This is the file ‘linux/vmlinux’. To extract the namelist and match it against the EIP from the kernel crash, do:
Afin de trouver le nom de la fonction du noyau, vous devez trouver le binaire système associé au noyau en question. C'est "linux / vmlinux". Pour extraire la liste de noms et la faire correspondre avec l'EIP en panne du noyau:
nm vmlinux | sort | less
This will give you a list of kernel addresses sorted in ascending order, from which it is simple to find the function that contains the offending address. Note that the address given by the kernel debugging messages will not necessarily match exactly with the function addresses (in fact, that is very unlikely), so you can’t just ‘grep’ the list: the list will, however, give you the starting point of each kernel function, so by looking for the function that has a starting address lower than the one you are searching for but is followed by a function with a higher address you will find the one you want. In fact, it may be a good idea to include a bit of “context” in your problem report, giving a few lines around the interesting one.
Cela donne les adresses du noyau triées par ordre croissant, ce qui facilite la recherche de la fonction qui contient l'adresse en question.
Veuillez noter que l'adresse affichée dans le message de débogage du noyau ne correspond pas toujours exactement à l'adresse de la fonction (en fait c'est rare). Donc «grep» ne suffit pas. Cependant, la liste montre la position de départ de chaque fonction du noyau. Par conséquent, vous pouvez trouver l'adresse cible en recherchant une fonction qui a une adresse de départ plus petite que l'adresse que vous recherchez et est suivie d'une adresse plus grande que cette adresse. Et en fait, ce pourrait être une bonne idée de rassembler quelques lignes intéressantes, y compris «contexte».
If you for some reason cannot do the above (you have a pre-compiled kernel image or similar), telling me as much about your setup as possible will help. Please read the admin-guide/reporting-bugs.rst document for details.
Si, pour une raison quelconque, vous ne pouvez pas faire ce qui précède (comme utiliser une image de noyau compilée par un représentant), veuillez nous en dire autant que possible sur la configuration. Consultez la documentation admin-guide / reporting-bugs.rst pour plus d'informations.
Alternatively, you can use gdb on a running kernel. (read-only; i.e. you cannot change values or set break points.) To do this, first compile the kernel with -g; edit arch/x86/Makefile appropriately, then do a make clean. You’ll also need to enable CONFIG_PROC_FS (via make config).
Vous pouvez également utiliser gdb avec un noyau en cours d'exécution. (Il est en lecture seule et vous ne pouvez pas changer sa valeur ou définir des points d'arrêt.) Pour ce faire, compilez d'abord votre noyau avec -g. Pour ce faire, éditez correctement arch / x86 / Makefile et exécutez make clean. Vous devez également activer CONFIG_PROC_FS (en utilisant make config).
After you’ve rebooted with the new kernel, do gdb vmlinux /proc/kcore. You can now use all the usual gdb commands. The command to look up the point where your system crashed is l *0xXXXXXXXX. (Replace the XXXes with the EIP value.)
Après le redémarrage avec le nouveau noyau, exécutez gdb vmlinux / proc / kcore. Vous pouvez utiliser toutes les commandes gdb normales. La commande pour trouver le point où le système s'est écrasé est l * 0xXXXXXXXX (remplacez XXXes par la valeur EIP).
gdb’ing a non-running kernel currently fails because gdb (wrongly) disregards the starting offset for which the kernel is compiled.
Gdb pour les noyaux qui ne sont pas en cours d'exécution échouera car gdb (à tort) ignore le décalage de début où le noyau est en cours de compilation.
À l'origine, il fait partie du code source du noyau Linux, il sera donc traité comme GPLv2 (reconnaissance qu'il devrait l'être).
https://www.kernel.org/doc/html/latest/index.html
Licensing documentation
The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing
Recommended Posts