[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |