ia64/xen-unstable

view docs/misc/crashdb.txt @ 12273:b223ba940ed1

PV-on-HVM: Fix PV-on-HVM drivers need maddr.h included for defn of maddr_t.
Signed-off-by: Takanori Kasai <Kasai.Takanori@jp.fujitsu.com>
Signed-off-by: Tsunehisa Doi <Doi.Tsunehisa@jp.fujitsu.com>
author kfraser@localhost.localdomain
date Tue Nov 07 09:29:53 2006 +0000 (2006-11-07)
parents 677aebca60b9
children 514d450ad729
line source
1 Xen crash debugger notes
2 ------------------------
4 Xen has a simple gdb stub for doing post-mortem debugging i.e. once
5 you've crashed it, you get to poke around and find out why. There's
6 also a special key handler for making it crash, which is handy.
8 You need to have crash_debug=y set when compiling to enable the crash
9 debugger (so go ``export crash_debug=y; make'', or ``crash_debug=y
10 make'' or ``make crash_debug=y''), and you also need to enable it on
11 the Xen command line, by going e.g. cdb=com1. If you need to have a
12 serial port shared between cdb and the console, try cdb=com1H. CDB
13 will then set the high bit on every byte it sends, and only respond to
14 bytes with the high bit set. Similarly for com2.
16 The next step depends on your individual setup. This is how to do
17 it for a normal test box in the SRG:
19 -- Make your test machine crash. Either a normal panic or hitting
20 'C-A C-A C-A %' on the serial console will do.
21 -- Start gdb as ``gdb ./xen-syms''
22 -- Go ``target remote serial.srg:12331'', where 12331 is the second port
23 reported for that machine by xenuse. (In this case, the machine is
24 bombjack)
25 -- Go ``add-symbol-file vmlinux''
26 -- Debug as if you had a core file
27 -- When you're finished, go and reboot your test box. Hitting 'R' on the
28 serial console won't work.
30 At one stage, it was sometimes possible to resume after entering the
31 debugger from the serial console. This seems to have rotted, however,
32 and I'm not terribly interested in putting it back.
34 As soon as you reach the debugger, we disable interrupts, the
35 watchdog, and every other CPU, so the state of the world shouldn't
36 change too much behind your back.
39 Reasons why we might fail to reach the debugger:
40 -----------------------------------------------
42 -- In order to stop the other processors, we need to acquire the SMP
43 call lock. If you happen to have crashed in the middle of that,
44 you're screwed.
45 -- If the page tables are wrong, you're screwed
46 -- If the serial port setup is wrong, badness happens
47 -- We acquire the console lock at one stage XXX this is unnecessary and
48 stupid
49 -- Obviously, the low level processor state can be screwed in any
50 number of wonderful ways