[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen dom0 crash in get_phys_to_machine



On Tue, 2010-10-12 at 08:55 +0100, Alan J. Wylie wrote:
> Further to my previous report:
> 
> http://lists.xensource.com/archives/html/xen-devel/2010-10/msg00257.html
> Message-ID: <19629.39326.337589.71778@xxxxxxxxxxx>
> 
> I've added some debugging and have tracked down the crash to the
> recently modified code in arch/x86/xen/mmu.c
> 
> Since the last version of the code that worked for me, mmu.c has been
> modified with a lot of P2M changes. It now crashes in
> get_phys_to_machine().
> 
> Having tracked down the crash and the offending value of pfn, I then
> further modified the code only to print if ( pfn == 0x18C3 ), and also
> to print intermediate values.
> 
> <7>ALANW get_phys_to_machine pfn 000018C3
> <7> topidx 00000000
> <7> mididx 0000000C
> <7> idx 000000C3
> (XEN) d0:v0: unhandled page fault (ec=0000)
> 
> If there is any more debugging that I can do, I'll be only too happy to
> oblige.

FWIW, when I was checking for any call where pfn > max_pfn - and I got:

  p2m_top[0][10][104] max_pfn=0

The p2m seems to have been correctly initialised:

 xen_build_dynamic_phys_to_machine: topidx=0 mididx=375 max_pfn=192512

But then it looks like something is trampling max_pfn and possibly other
important data structures.

I can get a working pvops dom0 by reverting to commit
e6b9b2cbca5093e8e38d3e314e2f6415ad951c60 - with the same config.

git-bisect between that commit and head turned up some nonsense about a
ata_piix change which just added a spinlock
876b3a81850fc237f643a065ea78ce2ad7665767 - so I assume that is a bisect
problem and that this commit is unrelated...

Gianni


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.