Re: [Xen-devel] Xen 4.0 + PVOPS + Intel VTD + USB EHCI = BUG()

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Thu, Jan 28, 2010 at 09:49:16AM -0500, David P. Quigley wrote:
> On Thu, 2010-01-28 at 11:24 +0200, Pasi Kärkkäinen wrote:
> > On Wed, Jan 27, 2010 at 03:22:57PM -0500, David P. Quigley wrote:
> > > On Tue, 2010-01-26 at 14:30 -0500, David P. Quigley wrote:
> > > > I have a small update on the problem. It does seem like it is tied to
> > > > VT-D because I just turned it off in the bios and the dom0 manages to
> > > > boot on top of xen and I can log in. Are there any options for VT-D that
> > > > you would like me to try to help pin point the problem?
> > > > 
> > > > Dave
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > > > http://lists.xensource.com/xen-devel
> > > 
> > > 
> > > So I've managed to get my dom0 booting on top of xen however now I'm
> > > running into a problem where my domU is kernel oopsing on startup. The
> > > traces I've gotten seem to be in the memory allocation functions.
> > > Normally this is a sign of memory corruption. Considering this VM was
> > > working perfectly with the 2.6.31.10 dom0 based on the Novell patches
> > > and xen 4.0 I don't think it is the VM that is the problem (however I
> > > can try starting it under kvm to be certain. Any suggestions on what I
> > > can do to try to hunt down the memory corruption?
> > > 
> > 
> > Hmm.. interesting.
> > 
> > You could try this: Set on_crash="preserve" in /etc/xen/<guest> cfgfile,
> > and when the guest crashes, run in dom0:
> > 
> > /usr/lib/xen/bin/xenctx -s System.map-domUkernelversion <domUid>
> > 
> > If your system is 64bit then xenctx might be under /usr/lib64/
> > That should give you a stack trace of the crashed guest..
> > 
> > -- Pasi
> 
> I'll run that when I get a chance. I managed to get the domU booting. I
> removed all of my debug statements off of the xen-4.0.gz line in my grub
> entry and it worked. I'm not sure if that code is the cause or if it
> just didn't stress a race condition that happens when the system is
> running slower because of debug code.
> 


Hmm.. I remember some discussions that "sync_console console_to_ring" might 
cause problems.
Not sure about that though.

-- Pasi


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