← Back to branch summary

~ubuntu-branches/ubuntu/utopic/xen/utopic

« back to all changes in this revision

Viewing changes to docs/misc/crashdb.txt

  • Committer: Bazaar Package Importer
  • Author(s): Bastian Blank
  • Date: 2010-05-06 15:47:38 UTC
  • mto: (1.3.1) (15.1.1 sid) (4.1.1 experimental)
  • mto: This revision was merged to the branch mainline in revision 3.
  • Revision ID: james.westby@ubuntu.com-20100506154738-agoz0rlafrh1fnq7
Tags: upstream-4.0.0
Import upstream version 4.0.0

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/misc/crashdb.txt
 
1
Xen crash debugger notes
 
2
------------------------
 
3
 
 
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.
 
7
 
 
8
You need to have crash_debug=y set when compiling , and you also need
 
9
to enable it on the Xen command line, eg by gdb=com1.
 
10
 
 
11
If you need to have a serial port shared between gdb and the console,
 
12
you can use gdb=com1H.  CDB will then set the high bit on every byte
 
13
it sends, and only respond to bytes with the high bit set.  Similarly
 
14
for com2.  If you do this you will need a demultiplexing program on
 
15
the debugging workstation, such as perhaps tools/misc/nsplitd.
 
16
 
 
17
The next step depends on your individual setup.  This is how to do it
 
18
if you have a simple null modem connection between the test box and
 
19
the workstation, and aren't using a H/L split console:
 
20
 
 
21
  * Set debug=y in Config.mk
 
22
  * Set crash_debug=y in xen/Rules.mk
 
23
  * Make the changes in the attached patch, and build.
 
24
  * Arrange to pass gdb=com1 as a hypervisor command line argument
 
25
    (I already have com1=38400,8n1 console=com1,vga sync_console)
 
26
    
 
27
  * Boot the system with minicom (or your favourite terminal program)
 
28
    connected from your workstation via a null modem cable in the
 
29
    usual way.
 
30
  * In minicom, give the escape character (^A by default) three times
 
31
    to talk to Xen (Xen prints `(XEN) *** Serial input -> Xen...').
 
32
  * Press % and observe the messages
 
33
     (XEN) '%' pressed -> trapping into debugger
 
34
     (XEN) GDB connection activated.
 
35
     (XEN) Waiting for GDB to attach...
 
36
  * Disconnect from minicom without allowing minicom to send any
 
37
    modem control sequences.
 
38
  * Start gdb with   gdb /path/to/build/tree/xen/xen-syms  and then
 
39
      (gdb) set remotebaud 38400
 
40
      Remote debugging using /dev/ttyS0
 
41
      0xff124d61 in idle_loop () at domain.c:78
 
42
      78              safe_halt();
 
43
      (gdb)
 
44
 
 
45
There is code which was once intended to make it possible to resume
 
46
after entering the debugger.  However this does not presently work; it
 
47
has been nonfunctional for quite some time.
 
48
 
 
49
As soon as you reach the debugger, we disable interrupts, the
 
50
watchdog, and every other CPU, so the state of the world shouldn't
 
51
change too much behind your back.
 
52
 
 
53
 
 
54
Reasons why we might fail to reach the debugger:
 
55
-----------------------------------------------
 
56
 
 
57
-- In order to stop the other processors, we need to acquire the SMP
 
58
   call lock.  If you happen to have crashed in the middle of that,
 
59
   you're screwed.
 
60
-- If the page tables are wrong, you're screwed
 
61
-- If the serial port setup is wrong, badness happens
 
62
-- Obviously, the low level processor state can be screwed in any
 
63
   number of wonderful ways