diff options
author | sos22@douglas.cl.cam.ac.uk <sos22@douglas.cl.cam.ac.uk> | 2005-02-10 17:06:57 +0000 |
---|---|---|
committer | sos22@douglas.cl.cam.ac.uk <sos22@douglas.cl.cam.ac.uk> | 2005-02-10 17:06:57 +0000 |
commit | 5b46877a442b83fbae48a9210e1d5658999af7c8 (patch) | |
tree | ea524e4b42a01df183aa502aa623c1b050ab51ae | |
parent | 5c5ffc1ac1d7f57bc65e1307ed47e2dff9baf034 (diff) | |
download | xen-5b46877a442b83fbae48a9210e1d5658999af7c8.tar.gz xen-5b46877a442b83fbae48a9210e1d5658999af7c8.tar.bz2 xen-5b46877a442b83fbae48a9210e1d5658999af7c8.zip |
bitkeeper revision 1.1166 (420b94b19VPINEpnyrORsIwqTctjAA)
Add in a very brief description of how it's supposed to work.
-rw-r--r-- | .rootkeys | 1 | ||||
-rw-r--r-- | docs/misc/crashdb.txt | 36 |
2 files changed, 37 insertions, 0 deletions
@@ -18,6 +18,7 @@ 41c0c4116itF389v0CEWcmzue6zJkA docs/misc/VMX_changes.txt 4022a73cgxX1ryj1HgS-IwwB6NUi2A docs/misc/XenDebugger-HOWTO 412f4bd9sm5mCQ8BkrgKcAKZGadq7Q docs/misc/blkif-drivers-explained.txt +420b949cy9ZGzED74Fz_DaWlK7tT4g docs/misc/crashdb.txt 40d6ccbfKKBq8jE0ula4eHEzBiQuDA docs/misc/xen_config.html 410a4c2bAO_m_l4RsiiPHnZ4ixHWbQ docs/misc/xend.tex 3f9e7d564bWFB-Czjv1qdmE6o0GqNg docs/src/interface.tex diff --git a/docs/misc/crashdb.txt b/docs/misc/crashdb.txt new file mode 100644 index 0000000000..ebf5e9f9b9 --- /dev/null +++ b/docs/misc/crashdb.txt @@ -0,0 +1,36 @@ +Xen crash debugger notes +------------------------ + +Xen has a simple gdb stub for doing post-mortem debugging i.e. once +you've crashed it, you get to poke around and find out why. There's +also a special key handler for making it crash, which is handy. + +You need to have crash_debug=y set when compiling to enable the crash +debugger (so go ``export crash_debug=y; make'', or ``crash_debug=y +make'' or ``make crash_debug=y''), and you also need to enable it on +the Xen command line, by going e.g. cdb=com1. If you need to have a +serial port shared between cdb and the console, try cdb=com1H. CDB +will then set the high bit on every byte it sends, and only respond to +bytes with the high bit set. Similarly for com2. + +The next step depends on your individual setup. This is how to do +it for a normal test box in the SRG: + +-- Make your test machine crash. Either a normal panic or hitting + 'C-A C-A C-A %' on the serial console will do. +-- Start gdb as ``gdb ./xen-syms'' +-- Go ``target remote serial.srg:12331'', where 12331 is the second port + reported for that machine by xenuse. (In this case, the machine is + bombjack) +-- Go ``add-symbol-file vmlinux'' +-- Debug as if you had a core file +-- When you're finished, go and reboot your test box. Hitting 'R' on the + serial console won't work. + +At one stage, it was sometimes possible to resume after entering the +debugger from the serial console. This seems to have rotted, however, +and I'm not terribly interested in putting it back. + +As soon as you reach the debugger, we disable interrupts, the +watchdog, and every other CPU, so the state of the world shouldn't +change too much behind your back. |