write in 30M

hc

2024-02-20 ea08eeccae9297f7aabd2ef7f0c2517ac4549acc

 kernel/Documentation/admin-guide/bug-hunting.rst
..
..
@@ -49,15 +49,19 @@
49
49
 
50
50
 Despite being an **Oops** or some other sort of stack trace, the offended
51
51
 line is usually required to identify and handle the bug. Along this chapter,
52
-we'll refer to "Oops" for all kinds of stack traces that need to be analized.
52
+we'll refer to "Oops" for all kinds of stack traces that need to be analyzed.
53
53
 
54
-.. note::
54
+If the kernel is compiled with ``CONFIG_DEBUG_INFO``, you can enhance the
55
+quality of the stack trace by using file:`scripts/decode_stacktrace.sh`.
55
56
 
56
-  ``ksymoops`` is useless on 2.6 or upper.  Please use the Oops in its original
57
-  format (from ``dmesg``, etc).  Ignore any references in this or other docs to
58
-  "decoding the Oops" or "running it through ksymoops".
59
-  If you post an Oops from 2.6+ that has been run through ``ksymoops``,
60
-  people will just tell you to repost it.
57
+Modules linked in
58
+-----------------
59
+
60
+Modules that are tainted or are being loaded or unloaded are marked with
61
+"(...)", where the taint flags are described in
62
+file:`Documentation/admin-guide/tainted-kernels.rst`, "being loaded" is
63
+annotated with "+", and "being unloaded" is annotated with "-".
64
+
61
65
 
62
66
 Where is the Oops message is located?
63
67
 -------------------------------------
..
..
@@ -71,7 +75,7 @@
71
75
 Sometimes ``klogd`` dies, in which case you can run ``dmesg > file`` to
72
76
 read the data from the kernel buffers and save it.  Or you can
73
77
 ``cat /proc/kmsg > file``, however you have to break in to stop the transfer,
74
-``kmsg`` is a "never ending file".
78
+since ``kmsg`` is a "never ending file".
75
79
 
76
80
 If the machine has crashed so badly that you cannot enter commands or
77
81
 the disk is not available then you have three options:
..
..
@@ -81,18 +85,18 @@
81
85
     planned for a crash. Alternatively, you can take a picture of
82
86
     the screen with a digital camera - not nice, but better than
83
87
     nothing.  If the messages scroll off the top of the console, you
84
-    may find that booting with a higher resolution (eg, ``vga=791``)
88
+    may find that booting with a higher resolution (e.g., ``vga=791``)
85
89
     will allow you to read more of the text. (Caveat: This needs ``vesafb``,
86
-    so won't help for 'early' oopses)
90
+    so won't help for 'early' oopses.)
87
91
 
88
92
 (2) Boot with a serial console (see
89
93
     :ref:`Documentation/admin-guide/serial-console.rst <serial_console>`),
90
94
     run a null modem to a second machine and capture the output there
91
95
     using your favourite communication program.  Minicom works well.
92
96
 
93
-(3) Use Kdump (see Documentation/kdump/kdump.txt),
97
+(3) Use Kdump (see Documentation/admin-guide/kdump/kdump.rst),
94
98
     extract the kernel ring buffer from old memory with using dmesg
95
-    gdbmacro in Documentation/kdump/gdbmacros.txt.
99
+    gdbmacro in Documentation/admin-guide/kdump/gdbmacros.txt.
96
100
 
97
101
 Finding the bug's location
98
102
 --------------------------
..
..
@@ -104,7 +108,7 @@
104
108
 gdb
105
109
 ^^^
106
110
 
107
-The GNU debug (``gdb``) is the best way to figure out the exact file and line
111
+The GNU debugger (``gdb``) is the best way to figure out the exact file and line
108
112
 number of the OOPS from the ``vmlinux`` file.
109
113
 
110
114
 The usage of gdb works best on a kernel compiled with ``CONFIG_DEBUG_INFO``.
..
..
@@ -165,7 +169,7 @@
165
169
       [<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee
166
170
       ...
167
171
 
168
-this shows the problem likely in the :jbd: module. You can load that module
172
+this shows the problem likely is in the :jbd: module. You can load that module
169
173
 in gdb and list the relevant code::
170
174
 
171
175
   $ gdb fs/jbd/jbd.ko
..
..
@@ -199,8 +203,9 @@
199
203
    You need to be at the top level of the kernel tree for this to pick up
200
204
    your C files.
201
205
 
202
-If you don't have access to the code you can also debug on some crash dumps
203
-e.g. crash dump output as shown by Dave Miller::
206
+If you don't have access to the source code you can still debug some crash
207
+dumps using the following method (example crash dump output as shown by
208
+Dave Miller)::
204
209
 
205
210
      EIP is at 	+0x14/0x4c0
206
211
       ...
..
..
@@ -230,6 +235,9 @@
230
235
          mov        0x8(%ebp), %ebx         ! %ebx = skb->sk
231
236
          mov        0x13c(%ebx), %eax       ! %eax = inet_sk(sk)->opt
232
237
 
238
+file:`scripts/decodecode` can be used to automate most of this, depending
239
+on what CPU architecture is being debugged.
240
+
233
241
 Reporting the bug
234
242
 -----------------
235
243
 
..
..
@@ -241,7 +249,7 @@
241
249
 the ``get_maintainer.pl`` script.
242
250
 
243
251
 For example, if you find a bug at the gspca's sonixj.c file, you can get
244
-their maintainers with::
252
+its maintainers with::
245
253
 
246
254
 	$ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c
247
255
 	Hans Verkuil <hverkuil@xs4all.nl> (odd fixer:GSPCA USB WEBCAM DRIVER,commit_signer:1/1=100%)
..
..
@@ -253,16 +261,17 @@
253
261
 
254
262
 Please notice that it will point to:
255
263
 
256
-- The last developers that touched on the source code. On the above example,
257
-  Tejun and Bhaktipriya (in this specific case, none really envolved on the
258
-  development of this file);
264
+- The last developers that touched the source code (if this is done inside
265
+  a git tree). On the above example, Tejun and Bhaktipriya (in this
266
+  specific case, none really envolved on the development of this file);
259
267
 - The driver maintainer (Hans Verkuil);
260
268
 - The subsystem maintainer (Mauro Carvalho Chehab);
261
269
 - The driver and/or subsystem mailing list (linux-media@vger.kernel.org);
262
270
 - the Linux Kernel mailing list (linux-kernel@vger.kernel.org).
263
271
 
264
272
 Usually, the fastest way to have your bug fixed is to report it to mailing
265
-list used for the development of the code (linux-media ML) copying the driver maintainer (Hans).
273
+list used for the development of the code (linux-media ML) copying the
274
+driver maintainer (Hans).
266
275
 
267
276
 If you are totally stumped as to whom to send the report, and
268
277
 ``get_maintainer.pl`` didn't provide you anything useful, send it to
..
..
@@ -303,9 +312,9 @@
303
312
 and forwarded to the kernel developers.
304
313
 
305
314
 Two types of address resolution are performed by ``klogd``.  The first is
306
-static translation and the second is dynamic translation.  Static
307
-translation uses the System.map file in much the same manner that
308
-ksymoops does.  In order to do static translation the ``klogd`` daemon
315
+static translation and the second is dynamic translation.
316
+Static translation uses the System.map file.
317
+In order to do static translation the ``klogd`` daemon
309
318
 must be able to find a system map file at daemon initialization time.
310
319
 See the klogd man page for information on how ``klogd`` searches for map
311
320
 files.