WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Reproducible system crash


On 16 Mar 2005, at 18:39, Peter Joanes wrote:

On Wednesday 16 March 2005 16:22, Keir Fraser wrote:
The stack backtrace also indicates that the code at address 0xc010990a
in XenLinux may also be interesting (that is the code point that caused
the crash).
'objdump -d vmlinux' and then grep the output for that address....

Here's what I think is the relevant section:

Not so useful unfortunately. Here's a slightly harder thing to try:

1. Edit linux/include/asm-xen/asm-i386/pgtable-2level.h, and change set_pte_batched() to use xen_l1_pgentry_update rather than queue_l1_pgentry_update. Also, kill current definition of set_pte() and redefine it to the same as the new set_pte_batched().

2. Edit xen/arch/x86/memory.c, at the test that fails for you ('Bad L1 type'). In the error path, before returning 0, add:
    extern void show_guest_stack(void);
    show_guest_stack();

This should cause us to get a backtrace of the guest kernel state when the bad PTE is written. If you send a link to that along with your vmlinux file then we can work out where the _PAGE_GLOBAL bit is coming from.

 -- Keir



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel