blob: 05960f8a748e6169822b1954530150502135cde0 [file] [log] [blame]
Linus Torvalds1da177e2005-04-16 15:20:36 -07001NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format
2(from dmesg, etc). Ignore any references in this or other docs to "decoding
Jesper Juhl62a07e62005-11-07 01:01:03 -08003the Oops" or "running it through ksymoops". If you post an Oops from 2.6 that
Linus Torvalds1da177e2005-04-16 15:20:36 -07004has been run through ksymoops, people will just tell you to repost it.
5
6Quick Summary
7-------------
8
9Find the Oops and send it to the maintainer of the kernel area that seems to be
10involved with the problem. Don't worry too much about getting the wrong person.
11If you are unsure send it to the person responsible for the code relevant to
12what you were doing. If it occurs repeatably try and describe how to recreate
13it. That's worth even more than the oops.
14
15If you are totally stumped as to whom to send the report, send it to
16linux-kernel@vger.kernel.org. Thanks for your help in making Linux as
17stable as humanly possible.
18
19Where is the Oops?
20----------------------
21
22Normally the Oops text is read from the kernel buffers by klogd and
23handed to syslogd which writes it to a syslog file, typically
24/var/log/messages (depends on /etc/syslog.conf). Sometimes klogd dies,
25in which case you can run dmesg > file to read the data from the kernel
26buffers and save it. Or you can cat /proc/kmsg > file, however you
27have to break in to stop the transfer, kmsg is a "never ending file".
28If the machine has crashed so badly that you cannot enter commands or
29the disk is not available then you have three options :-
30
31(1) Hand copy the text from the screen and type it in after the machine
32 has restarted. Messy but it is the only option if you have not
Diego Calleja36174492005-11-13 16:07:40 -080033 planned for a crash. Alternatively, you can take a picture of
34 the screen with a digital camera - not nice, but better than
Dave Jonese1f1def2005-11-15 00:09:24 -080035 nothing. If the messages scroll off the top of the console, you
36 may find that booting with a higher resolution (eg, vga=791)
37 will allow you to read more of the text. (Caveat: This needs vesafb,
38 so won't help for 'early' oopses)
Linus Torvalds1da177e2005-04-16 15:20:36 -070039
40(2) Boot with a serial console (see Documentation/serial-console.txt),
41 run a null modem to a second machine and capture the output there
42 using your favourite communication program. Minicom works well.
43
44(3) Patch the kernel with one of the crash dump patches. These save
45 data to a floppy disk or video rom or a swap partition. None of
46 these are standard kernel patches so you have to find and apply
47 them yourself. Search kernel archives for kmsgdump, lkcd and
48 oops+smram.
49
50
51Full Information
52----------------
53
54NOTE: the message from Linus below applies to 2.4 kernel. I have preserved it
55for historical reasons, and because some of the information in it still
56applies. Especially, please ignore any references to ksymoops.
57
58From: Linus Torvalds <torvalds@osdl.org>
59
60How to track down an Oops.. [originally a mail to linux-kernel]
61
62The main trick is having 5 years of experience with those pesky oops
63messages ;-)
64
65Actually, there are things you can do that make this easier. I have two
66separate approaches:
67
68 gdb /usr/src/linux/vmlinux
69 gdb> disassemble <offending_function>
70
71That's the easy way to find the problem, at least if the bug-report is
72well made (like this one was - run through ksymoops to get the
73information of which function and the offset in the function that it
74happened in).
75
76Oh, it helps if the report happens on a kernel that is compiled with the
77same compiler and similar setups.
78
79The other thing to do is disassemble the "Code:" part of the bug report:
80ksymoops will do this too with the correct tools, but if you don't have
81the tools you can just do a silly program:
82
83 char str[] = "\xXX\xXX\xXX...";
84 main(){}
85
86and compile it with gcc -g and then do "disassemble str" (where the "XX"
87stuff are the values reported by the Oops - you can just cut-and-paste
88and do a replace of spaces to "\x" - that's what I do, as I'm too lazy
89to write a program to automate this all).
90
91Finally, if you want to see where the code comes from, you can do
92
93 cd /usr/src/linux
94 make fs/buffer.s # or whatever file the bug happened in
95
96and then you get a better idea of what happens than with the gdb
97disassembly.
98
99Now, the trick is just then to combine all the data you have: the C
100sources (and general knowledge of what it _should_ do), the assembly
101listing and the code disassembly (and additionally the register dump you
102also get from the "oops" message - that can be useful to see _what_ the
103corrupted pointers were, and when you have the assembler listing you can
104also match the other registers to whatever C expressions they were used
105for).
106
107Essentially, you just look at what doesn't match (in this case it was the
108"Code" disassembly that didn't match with what the compiler generated).
109Then you need to find out _why_ they don't match. Often it's simple - you
110see that the code uses a NULL pointer and then you look at the code and
111wonder how the NULL pointer got there, and if it's a valid thing to do
112you just check against it..
113
114Now, if somebody gets the idea that this is time-consuming and requires
115some small amount of concentration, you're right. Which is why I will
116mostly just ignore any panic reports that don't have the symbol table
117info etc looked up: it simply gets too hard to look it up (I have some
118programs to search for specific patterns in the kernel code segment, and
119sometimes I have been able to look up those kinds of panics too, but
120that really requires pretty good knowledge of the kernel just to be able
121to pick out the right sequences etc..)
122
123_Sometimes_ it happens that I just see the disassembled code sequence
124from the panic, and I know immediately where it's coming from. That's when
125I get worried that I've been doing this for too long ;-)
126
127 Linus
128
129
130---------------------------------------------------------------------------
131Notes on Oops tracing with klogd:
132
133In order to help Linus and the other kernel developers there has been
134substantial support incorporated into klogd for processing protection
135faults. In order to have full support for address resolution at least
136version 1.3-pl3 of the sysklogd package should be used.
137
138When a protection fault occurs the klogd daemon automatically
139translates important addresses in the kernel log messages to their
140symbolic equivalents. This translated kernel message is then
141forwarded through whatever reporting mechanism klogd is using. The
142protection fault message can be simply cut out of the message files
143and forwarded to the kernel developers.
144
145Two types of address resolution are performed by klogd. The first is
146static translation and the second is dynamic translation. Static
147translation uses the System.map file in much the same manner that
148ksymoops does. In order to do static translation the klogd daemon
149must be able to find a system map file at daemon initialization time.
150See the klogd man page for information on how klogd searches for map
151files.
152
153Dynamic address translation is important when kernel loadable modules
154are being used. Since memory for kernel modules is allocated from the
155kernel's dynamic memory pools there are no fixed locations for either
156the start of the module or for functions and symbols in the module.
157
158The kernel supports system calls which allow a program to determine
159which modules are loaded and their location in memory. Using these
160system calls the klogd daemon builds a symbol table which can be used
161to debug a protection fault which occurs in a loadable kernel module.
162
163At the very minimum klogd will provide the name of the module which
164generated the protection fault. There may be additional symbolic
165information available if the developer of the loadable module chose to
166export symbol information from the module.
167
168Since the kernel module environment can be dynamic there must be a
169mechanism for notifying the klogd daemon when a change in module
170environment occurs. There are command line options available which
171allow klogd to signal the currently executing daemon that symbol
172information should be refreshed. See the klogd manual page for more
173information.
174
175A patch is included with the sysklogd distribution which modifies the
176modules-2.0.0 package to automatically signal klogd whenever a module
177is loaded or unloaded. Applying this patch provides essentially
178seamless support for debugging protection faults which occur with
179kernel loadable modules.
180
181The following is an example of a protection fault in a loadable module
182processed by klogd:
183---------------------------------------------------------------------------
184Aug 29 09:51:01 blizard kernel: Unable to handle kernel paging request at virtual address f15e97cc
185Aug 29 09:51:01 blizard kernel: current->tss.cr3 = 0062d000, %cr3 = 0062d000
186Aug 29 09:51:01 blizard kernel: *pde = 00000000
187Aug 29 09:51:01 blizard kernel: Oops: 0002
188Aug 29 09:51:01 blizard kernel: CPU: 0
189Aug 29 09:51:01 blizard kernel: EIP: 0010:[oops:_oops+16/3868]
190Aug 29 09:51:01 blizard kernel: EFLAGS: 00010212
191Aug 29 09:51:01 blizard kernel: eax: 315e97cc ebx: 003a6f80 ecx: 001be77b edx: 00237c0c
192Aug 29 09:51:01 blizard kernel: esi: 00000000 edi: bffffdb3 ebp: 00589f90 esp: 00589f8c
193Aug 29 09:51:01 blizard kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
194Aug 29 09:51:01 blizard kernel: Process oops_test (pid: 3374, process nr: 21, stackpage=00589000)
195Aug 29 09:51:01 blizard kernel: Stack: 315e97cc 00589f98 0100b0b4 bffffed4 0012e38e 00240c64 003a6f80 00000001
196Aug 29 09:51:01 blizard kernel: 00000000 00237810 bfffff00 0010a7fa 00000003 00000001 00000000 bfffff00
197Aug 29 09:51:01 blizard kernel: bffffdb3 bffffed4 ffffffda 0000002b 0007002b 0000002b 0000002b 00000036
198Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128]
199Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3
200---------------------------------------------------------------------------
201
202Dr. G.W. Wettstein Oncology Research Div. Computing Facility
203Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com
204820 4th St. N.
205Fargo, ND 58122
206Phone: 701-234-7556
207
208
209---------------------------------------------------------------------------
210Tainted kernels:
211
212Some oops reports contain the string 'Tainted: ' after the program
Randy Dunlap1cc57532005-09-13 01:25:46 -0700213counter. This indicates that the kernel has been tainted by some
214mechanism. The string is followed by a series of position-sensitive
Linus Torvalds1da177e2005-04-16 15:20:36 -0700215characters, each representing a particular tainted value.
216
217 1: 'G' if all modules loaded have a GPL or compatible license, 'P' if
218 any proprietary module has been loaded. Modules without a
219 MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by
220 insmod as GPL compatible are assumed to be proprietary.
221
Randy Dunlap1cc57532005-09-13 01:25:46 -0700222 2: 'F' if any module was force loaded by "insmod -f", ' ' if all
Linus Torvalds1da177e2005-04-16 15:20:36 -0700223 modules were loaded normally.
224
225 3: 'S' if the oops occurred on an SMP kernel running on hardware that
Randy Dunlap1cc57532005-09-13 01:25:46 -0700226 hasn't been certified as safe to run multiprocessor.
227 Currently this occurs only on various Athlons that are not
228 SMP capable.
229
230 4: 'R' if a module was force unloaded by "rmmod -f", ' ' if all
231 modules were unloaded normally.
232
233 5: 'M' if any processor has reported a Machine Check Exception,
234 ' ' if no Machine Check Exceptions have occurred.
235
236 6: 'B' if a page-release function has found a bad page reference or
237 some unexpected page flags.
Linus Torvalds1da177e2005-04-16 15:20:36 -0700238
239The primary reason for the 'Tainted: ' string is to tell kernel
240debuggers if this is a clean kernel or if anything unusual has
Randy Dunlap1cc57532005-09-13 01:25:46 -0700241occurred. Tainting is permanent: even if an offending module is
242unloaded, the tainted value remains to indicate that the kernel is not
Linus Torvalds1da177e2005-04-16 15:20:36 -0700243trustworthy.