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.
If you have a problem that you suspect is due to a kernel bug, check the file MAINTAINERS to see if there are any specific people associated with some of the problematic kernels. If no one is listed there, the second best thing is to contact me (Torvalds at linux-foundation.org) and possibly other relevant mailing lists or newsgroups.
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.
For all bug reports, please tell me what kernel it is for, how to reproduce the problem, and how to set it up (using common sense). Please let me know if the problem is new. If the problem is out of date, please tell us when you first noticed it.
If the bug results in a message like:
If the bug causes a message similar to the following:
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
Alternatively, duplicate the kernel debugging information on the screen or in the system log exactly. A dump may be confusing to you, but it also contains useful information for debugging. The text on the dump is also important: this will tell you why the kernel dump code was caused (in the example above, it was caused by a bad kernel pointer) Documentation for more information on what dump means It is located at /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:
If you compiled the kernel with CONFIG_KALLSYMS, you can send the dump as is. If this is not the case, you will need to use the ksymoops program to detect the dump (although CONFIG_KALLSYMS is generally recommended). You can download this utility from https://www.kernel.org/pub/linux/utils/kernel/ksymoops/. Alternatively, you can manually perform a dump search.
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.
When debugging a dump like the one above, it's very helpful to be able to find out what the EIP value means. The hexadecimal value itself is not very useful to me or anyone else. It depends on each kernel setup. All you have to do is get the hexadecimal value (0010: ignored) from the EIP line and look it up in the kernel namelist to see the kernel function containing the offending address. The numbers themselves are meaningless because the address information may change due to compile options etc. The problem is that you need the address information to determine which function / code is causing the problem. )
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:
To find the kernel function name, you need to find the system binary associated with the kernel you are having problems with. This is "linux / vmlinux". To extract the namelist and match it with the kernel crashed EIP:
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.
This gives the kernel addresses sorted in ascending order, making it easier to find the function that contains the address in question.
Note that the address displayed in the kernel debugging message does not always exactly match the function address (in fact it is rare). So'grep' is not enough. However, the list shows the start position of each kernel function. Therefore, you can find the desired address by searching for a function that has a starting address that is smaller than the address you are searching for, followed by an address that is larger than that address. And in fact, it might be a good idea to put together a few interesting lines, including "context".
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.
If for some reason you can't do the above (such as using a rep-compiled kernel image), please tell us as much as possible about setup. See the admin-guide / reporting-bugs.rst documentation for more information.
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).
Alternatively, you can use gdb with a running kernel. (It's read-only and you can't change its value or set breakpoints.) To do this, first compile your kernel with -g. To do this, edit arch / x86 / Makefile appropriately and run make clean. You also need to enable CONFIG_PROC_FS (using 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.)
After rebooting with the new kernel, run gdb vmlinux / proc / kcore. You can use all regular gdb commands. The command to find the point where the system crashed is l * 0xXXXXXXXX (replace XXXes with the EIP value).
gdb’ing a non-running kernel currently fails because gdb (wrongly) disregards the starting offset for which the kernel is compiled.
Gdb for kernels that are not currently running will fail because gdb (incorrectly) ignores the start offset where the kernel is compiled.
Originally, it is a part of the Linux Kernel source code, so it will be treated as GPLv2 (recognition that it should be).
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