Oops, Linux crashes - Revision history

JulienB: /* Links */

2012-02-14T14:18:40Z

Links

← Older revision		Revision as of 16:18, 14 February 2012
Line 277:		Line 277:
	==Links==		==Links==
	* [http://linux.die.net/man/8/ksymoops ksymoops man page]		* [http://linux.die.net/man/8/ksymoops ksymoops man page]
			* http://www.dedoimedo.com/computers/crash-analyze.html#mozTocId34663

JulienB: /* Backtrace & System.map */

2009-05-11T12:41:28Z

Backtrace & System.map

← Older revision		Revision as of 14:41, 11 May 2009
Line 54:		Line 54:
	To make the translation between these memory addresses and the "real" function names, we have to look in the System.map file which stores all the Linux kernel function offset.		To make the translation between these memory addresses and the "real" function names, we have to look in the System.map file which stores all the Linux kernel function offset.
	So to have the functions name just do a:		So to have the functions name just do a:
	[armadeus] $ grep c00256e0 ~~buildroot/build_armv4t/linux-2.6.X.X~~/System.map		<pre class="host">
			[armadeus] $ grep c00256e0 $ARMADEUS_LINUX_DIR/System.map
			</pre>

	As each kernel build could generate a new System.map, you must be sure to do that with the crashing kernel System.map...		As each kernel build could generate a new System.map, you must be sure to do that with the crashing kernel System.map...

JulienB at 12:24, 11 May 2009

2009-05-11T12:24:41Z

← Older revision		Revision as of 14:24, 11 May 2009
Line 1:		Line 1:
	You've just started kernel development and got something like that:		You've just started kernel development and got something like that:

			<pre class="apf">
	Unable to handle kernel NULL pointer dereference at virtual address 00000000		Unable to handle kernel NULL pointer dereference at virtual address 00000000
	pgd = c0004000		pgd = c0004000
Line 26:		Line 27:
	Function entered at [<c019bdb4>] from [<c0197dd0>]		Function entered at [<c019bdb4>] from [<c0197dd0>]
	...		...
			</pre>
	Well don't worry we will try to look at how to interpret this beast.		Well don't worry we will try to look at how to interpret this beast.

Line 39:		Line 41:

	==Backtrace & System.map==		==Backtrace & System.map==
			<pre class="apf">
	Backtrace:		Backtrace:
	Function entered at [<c00256e0>] from [<c019dca0>]		Function entered at [<c00256e0>] from [<c019dca0>]
	Function entered at [<c019dc80>] from [<c0199950>]		Function entered at [<c019dc80>] from [<c0199950>]
			</pre>

	Immediate informations on where the kernel crashes can be deducted from the backtrace analysis. In this backtrace are listed all the functions called before the crash (in reverse order).<br>		Immediate informations on where the kernel crashes can be deducted from the backtrace analysis. In this backtrace are listed all the functions called before the crash (in reverse order).<br>

Jorasse: /* Usage */

2008-12-06T23:39:45Z

Usage

← Older revision		Revision as of 01:39, 7 December 2008
Line 189:		Line 189:

	* launch:		* launch:
	$ ksymoops -V buildroot/~~build_arm~~/linux-2.6.23.1/vmlinux -m buildroot/~~build_arm~~/linux-2.6.23.1/System.map --no-ksyms --no-lsmod \		$ ksymoops -V buildroot/build_armv4t/linux-2.6.23.1/vmlinux -m buildroot/build_armv4t/linux-2.6.23.1/System.map --no-ksyms --no-lsmod \
	-o buildroot/~~project_build_arm~~/armadeus/root/lib/modules/2.6.23.1/ oops.txt		-o buildroot/project_build_armv4t/armadeus/root/lib/modules/2.6.23.1/ oops.txt

	* and after some processing you will get something like that:		* and after some processing you will get something like that:

Jorasse: /* Backtrace & System.map */

2008-12-06T23:37:05Z

Backtrace & System.map

← Older revision		Revision as of 01:37, 7 December 2008
Line 51:		Line 51:
	To make the translation between these memory addresses and the "real" function names, we have to look in the System.map file which stores all the Linux kernel function offset.		To make the translation between these memory addresses and the "real" function names, we have to look in the System.map file which stores all the Linux kernel function offset.
	So to have the functions name just do a:		So to have the functions name just do a:
	[armadeus] $ grep c00256e0 buildroot/~~build_arm~~/linux-2.6.X.X/System.map		[armadeus] $ grep c00256e0 buildroot/build_armv4t/linux-2.6.X.X/System.map

	As each kernel build could generate a new System.map, you must be sure to do that with the crashing kernel System.map...		As each kernel build could generate a new System.map, you must be sure to do that with the crashing kernel System.map...

JulienB: /* Backtrace & System.map */

2008-11-05T17:54:07Z

Backtrace & System.map

← Older revision		Revision as of 19:54, 5 November 2008
Line 51:		Line 51:
	To make the translation between these memory addresses and the "real" function names, we have to look in the System.map file which stores all the Linux kernel function offset.		To make the translation between these memory addresses and the "real" function names, we have to look in the System.map file which stores all the Linux kernel function offset.
	So to have the functions name just do a:		So to have the functions name just do a:
	[armadeus] $ grep c00256e0 buildroot/~~build_arm_nofpu~~/linux-2.6.X.X/System.map		[armadeus] $ grep c00256e0 buildroot/build_arm/linux-2.6.X.X/System.map

	As each kernel build could generate a new System.map, you must be sure to do that with the crashing kernel System.map...		As each kernel build could generate a new System.map, you must be sure to do that with the crashing kernel System.map...

JulienB: /* Usage */

2008-07-21T16:41:15Z

Usage

← Older revision		Revision as of 18:41, 21 July 2008
Line 61:		Line 61:

	===Usage===		===Usage===
	* copy your Oops text output to a text file (''oops.txt'') on your Host		* copy your Oops text output to a text file (''oops.txt'') on your Host (for example):
	Unable to handle kernel NULL pointer dereference at virtual address 00000002		Unable to handle kernel NULL pointer dereference at virtual address 00000002
	pgd = c09d4000		pgd = c09d4000

JulienB: Add ksymoops

2008-07-21T16:39:56Z

Add ksymoops

Show changes

JulienB: /* Backtrace & System.map */

2007-10-21T17:36:41Z

Backtrace & System.map

← Older revision		Revision as of 19:36, 21 October 2007
Line 46:		Line 46:
	Immediate informations on where the kernel crashes can be deducted from the backtrace analysis. In this backtrace are listed all the functions called before the crash (in reverse order).<br>		Immediate informations on where the kernel crashes can be deducted from the backtrace analysis. In this backtrace are listed all the functions called before the crash (in reverse order).<br>
	In our example we can deduce that kernel has:		In our example we can deduce that kernel has:
	* crashed at (pc)		* crashed at 0xc0025720 (pc)
	* faulty function starts at 0xc00256e0 and was called by a function starting at 0xc019dc80		* faulty function starts at 0xc00256e0 and was called by a function starting at 0xc019dc80

	To make the translation between these memory ~~addreses~~ and the "real" function names, we have to look in the System.map file which stores all the Linux kernel function offset.		To make the translation between these memory addresses and the "real" function names, we have to look in the System.map file which stores all the Linux kernel function offset.
	So to have the functions name just do a:		So to have the functions name just do a:
	[armadeus] $ grep c00256e0 buildroot/build_arm_nofpu/linux-2.6.X.X/System.map		[armadeus] $ grep c00256e0 buildroot/build_arm_nofpu/linux-2.6.X.X/System.map

	As each kernel build could generate a new System.map, you must be sure to do that with the crashing kernel System.map...		As each kernel build could generate a new System.map, you must be sure to do that with the crashing kernel System.map...

JulienB: /* Backtrace & System.map */

2007-10-21T17:35:59Z

Backtrace & System.map

← Older revision		Revision as of 19:35, 21 October 2007
Line 43:		Line 43:
	Function entered at [<c00256e0>] from [<c019dca0>]		Function entered at [<c00256e0>] from [<c019dca0>]
	Function entered at [<c019dc80>] from [<c0199950>]		Function entered at [<c019dc80>] from [<c0199950>]

			Immediate informations on where the kernel crashes can be deducted from the backtrace analysis. In this backtrace are listed all the functions called before the crash (in reverse order).<br>
			In our example we can deduce that kernel has:
			* crashed at (pc)
			* faulty function starts at 0xc00256e0 and was called by a function starting at 0xc019dc80

			To make the translation between these memory addreses and the "real" function names, we have to look in the System.map file which stores all the Linux kernel function offset.
			So to have the functions name just do a:
			[armadeus] $ grep c00256e0 buildroot/build_arm_nofpu/linux-2.6.X.X/System.map

			As each kernel build could generate a new System.map, you must be sure to do that with the crashing kernel System.map...