Documentation: admin-guide: update bug-hunting.rst
Update Documentation/admin-guide/bug-hunting.rst: - add a small section on "Modules linked in" and their possible flags; - delete all references to ksymoops since it is no longer applicable; - fix spello, grammar, and punctuation; - note that get_maintainers.pl only provides recent patchers if it is run inside a git tree; - add mention of scripts/decode_stacktrace.sh; Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: greg@wind.rmcc.com Link: https://lore.kernel.org/r/c629a9ef-3867-c3d1-f6c9-2c3b0e4ac68a@infradead.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
parent
17444d9b0b
commit
4eb9241127
@ -49,15 +49,19 @@ the issue, it may also contain the word **Oops**, as on this one::
|
|||||||
|
|
||||||
Despite being an **Oops** or some other sort of stack trace, the offended
|
Despite being an **Oops** or some other sort of stack trace, the offended
|
||||||
line is usually required to identify and handle the bug. Along this chapter,
|
line is usually required to identify and handle the bug. Along this chapter,
|
||||||
we'll refer to "Oops" for all kinds of stack traces that need to be analized.
|
we'll refer to "Oops" for all kinds of stack traces that need to be analyzed.
|
||||||
|
|
||||||
.. note::
|
If the kernel is compiled with ``CONFIG_DEBUG_INFO``, you can enhance the
|
||||||
|
quality of the stack trace by using file:`scripts/decode_stacktrace.sh`.
|
||||||
|
|
||||||
|
Modules linked in
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
Modules that are tainted or are being loaded or unloaded are marked with
|
||||||
|
"(...)", where the taint flags are described in
|
||||||
|
file:`Documentation/admin-guide/tainted-kernels.rst`, "being loaded" is
|
||||||
|
annotated with "+", and "being unloaded" is annotated with "-".
|
||||||
|
|
||||||
``ksymoops`` is useless on 2.6 or upper. Please use the Oops in its original
|
|
||||||
format (from ``dmesg``, etc). Ignore any references in this or other docs to
|
|
||||||
"decoding the Oops" or "running it through ksymoops".
|
|
||||||
If you post an Oops from 2.6+ that has been run through ``ksymoops``,
|
|
||||||
people will just tell you to repost it.
|
|
||||||
|
|
||||||
Where is the Oops message is located?
|
Where is the Oops message is located?
|
||||||
-------------------------------------
|
-------------------------------------
|
||||||
@ -71,7 +75,7 @@ by running ``journalctl`` command.
|
|||||||
Sometimes ``klogd`` dies, in which case you can run ``dmesg > file`` to
|
Sometimes ``klogd`` dies, in which case you can run ``dmesg > file`` to
|
||||||
read the data from the kernel buffers and save it. Or you can
|
read the data from the kernel buffers and save it. Or you can
|
||||||
``cat /proc/kmsg > file``, however you have to break in to stop the transfer,
|
``cat /proc/kmsg > file``, however you have to break in to stop the transfer,
|
||||||
``kmsg`` is a "never ending file".
|
since ``kmsg`` is a "never ending file".
|
||||||
|
|
||||||
If the machine has crashed so badly that you cannot enter commands or
|
If the machine has crashed so badly that you cannot enter commands or
|
||||||
the disk is not available then you have three options:
|
the disk is not available then you have three options:
|
||||||
@ -81,9 +85,9 @@ the disk is not available then you have three options:
|
|||||||
planned for a crash. Alternatively, you can take a picture of
|
planned for a crash. Alternatively, you can take a picture of
|
||||||
the screen with a digital camera - not nice, but better than
|
the screen with a digital camera - not nice, but better than
|
||||||
nothing. If the messages scroll off the top of the console, you
|
nothing. If the messages scroll off the top of the console, you
|
||||||
may find that booting with a higher resolution (eg, ``vga=791``)
|
may find that booting with a higher resolution (e.g., ``vga=791``)
|
||||||
will allow you to read more of the text. (Caveat: This needs ``vesafb``,
|
will allow you to read more of the text. (Caveat: This needs ``vesafb``,
|
||||||
so won't help for 'early' oopses)
|
so won't help for 'early' oopses.)
|
||||||
|
|
||||||
(2) Boot with a serial console (see
|
(2) Boot with a serial console (see
|
||||||
:ref:`Documentation/admin-guide/serial-console.rst <serial_console>`),
|
:ref:`Documentation/admin-guide/serial-console.rst <serial_console>`),
|
||||||
@ -104,7 +108,7 @@ Kernel source file. There are two methods for doing that. Usually, using
|
|||||||
gdb
|
gdb
|
||||||
^^^
|
^^^
|
||||||
|
|
||||||
The GNU debug (``gdb``) is the best way to figure out the exact file and line
|
The GNU debugger (``gdb``) is the best way to figure out the exact file and line
|
||||||
number of the OOPS from the ``vmlinux`` file.
|
number of the OOPS from the ``vmlinux`` file.
|
||||||
|
|
||||||
The usage of gdb works best on a kernel compiled with ``CONFIG_DEBUG_INFO``.
|
The usage of gdb works best on a kernel compiled with ``CONFIG_DEBUG_INFO``.
|
||||||
@ -165,7 +169,7 @@ If you have a call trace, such as::
|
|||||||
[<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee
|
[<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee
|
||||||
...
|
...
|
||||||
|
|
||||||
this shows the problem likely in the :jbd: module. You can load that module
|
this shows the problem likely is in the :jbd: module. You can load that module
|
||||||
in gdb and list the relevant code::
|
in gdb and list the relevant code::
|
||||||
|
|
||||||
$ gdb fs/jbd/jbd.ko
|
$ gdb fs/jbd/jbd.ko
|
||||||
@ -199,8 +203,9 @@ in the kernel hacking menu of the menu configuration.) For example::
|
|||||||
You need to be at the top level of the kernel tree for this to pick up
|
You need to be at the top level of the kernel tree for this to pick up
|
||||||
your C files.
|
your C files.
|
||||||
|
|
||||||
If you don't have access to the code you can also debug on some crash dumps
|
If you don't have access to the source code you can still debug some crash
|
||||||
e.g. crash dump output as shown by Dave Miller::
|
dumps using the following method (example crash dump output as shown by
|
||||||
|
Dave Miller)::
|
||||||
|
|
||||||
EIP is at +0x14/0x4c0
|
EIP is at +0x14/0x4c0
|
||||||
...
|
...
|
||||||
@ -230,6 +235,9 @@ e.g. crash dump output as shown by Dave Miller::
|
|||||||
mov 0x8(%ebp), %ebx ! %ebx = skb->sk
|
mov 0x8(%ebp), %ebx ! %ebx = skb->sk
|
||||||
mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt
|
mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt
|
||||||
|
|
||||||
|
file:`scripts/decodecode` can be used to automate most of this, depending
|
||||||
|
on what CPU architecture is being debugged.
|
||||||
|
|
||||||
Reporting the bug
|
Reporting the bug
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
@ -241,7 +249,7 @@ used for the development of the affected code. This can be done by using
|
|||||||
the ``get_maintainer.pl`` script.
|
the ``get_maintainer.pl`` script.
|
||||||
|
|
||||||
For example, if you find a bug at the gspca's sonixj.c file, you can get
|
For example, if you find a bug at the gspca's sonixj.c file, you can get
|
||||||
their maintainers with::
|
its maintainers with::
|
||||||
|
|
||||||
$ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c
|
$ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c
|
||||||
Hans Verkuil <hverkuil@xs4all.nl> (odd fixer:GSPCA USB WEBCAM DRIVER,commit_signer:1/1=100%)
|
Hans Verkuil <hverkuil@xs4all.nl> (odd fixer:GSPCA USB WEBCAM DRIVER,commit_signer:1/1=100%)
|
||||||
@ -253,16 +261,17 @@ their maintainers with::
|
|||||||
|
|
||||||
Please notice that it will point to:
|
Please notice that it will point to:
|
||||||
|
|
||||||
- The last developers that touched on the source code. On the above example,
|
- The last developers that touched the source code (if this is done inside
|
||||||
Tejun and Bhaktipriya (in this specific case, none really envolved on the
|
a git tree). On the above example, Tejun and Bhaktipriya (in this
|
||||||
development of this file);
|
specific case, none really envolved on the development of this file);
|
||||||
- The driver maintainer (Hans Verkuil);
|
- The driver maintainer (Hans Verkuil);
|
||||||
- The subsystem maintainer (Mauro Carvalho Chehab);
|
- The subsystem maintainer (Mauro Carvalho Chehab);
|
||||||
- The driver and/or subsystem mailing list (linux-media@vger.kernel.org);
|
- The driver and/or subsystem mailing list (linux-media@vger.kernel.org);
|
||||||
- the Linux Kernel mailing list (linux-kernel@vger.kernel.org).
|
- the Linux Kernel mailing list (linux-kernel@vger.kernel.org).
|
||||||
|
|
||||||
Usually, the fastest way to have your bug fixed is to report it to mailing
|
Usually, the fastest way to have your bug fixed is to report it to mailing
|
||||||
list used for the development of the code (linux-media ML) copying the driver maintainer (Hans).
|
list used for the development of the code (linux-media ML) copying the
|
||||||
|
driver maintainer (Hans).
|
||||||
|
|
||||||
If you are totally stumped as to whom to send the report, and
|
If you are totally stumped as to whom to send the report, and
|
||||||
``get_maintainer.pl`` didn't provide you anything useful, send it to
|
``get_maintainer.pl`` didn't provide you anything useful, send it to
|
||||||
@ -303,9 +312,9 @@ protection fault message can be simply cut out of the message files
|
|||||||
and forwarded to the kernel developers.
|
and forwarded to the kernel developers.
|
||||||
|
|
||||||
Two types of address resolution are performed by ``klogd``. The first is
|
Two types of address resolution are performed by ``klogd``. The first is
|
||||||
static translation and the second is dynamic translation. Static
|
static translation and the second is dynamic translation.
|
||||||
translation uses the System.map file in much the same manner that
|
Static translation uses the System.map file.
|
||||||
ksymoops does. In order to do static translation the ``klogd`` daemon
|
In order to do static translation the ``klogd`` daemon
|
||||||
must be able to find a system map file at daemon initialization time.
|
must be able to find a system map file at daemon initialization time.
|
||||||
See the klogd man page for information on how ``klogd`` searches for map
|
See the klogd man page for information on how ``klogd`` searches for map
|
||||||
files.
|
files.
|
||||||
|
Loading…
Reference in New Issue
Block a user