|
|
|
|
|
|
|
|
|
|
xen-devel
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
|
|
|
|
|