[Xen-devel] Re: Paging oopses

[stevegt@xxxxxxxxxxxxx]

Some thoughts: the only thing I can think of that I might be doing
differently than any of you is that I'm running the NFS root server on
another node, a standard Linux machine, with the traffic going through a
lightly-loaded 100Mb switch.  Nevertheless, I still get occasional NFS
timeouts, as you'll see in the console log.  These haven't worried me,
but if you find that these paging oopses are happening in mmap code,
that might be worth noting.

Steve


On Fri, Feb 20, 2004 at 10:23:26PM -0800,  wrote:
> Hi All, bad news.
> 
> After running several guests for most of the past week on the 12 Feb
> build of 1.2, built with GCC 3.3.2, with 64Mb of RAM and NFS roots, I
> finally got another paging oops.  The entire console log, xen and
> xenolinux binaries, and System.map, are at:
> 
>       http://t7a.org/tmp/oops1-n2h54/
> 
> Let me know if there's anything else I can do.  
> 
> Steve
> 
> 
> On Wed, Feb 11, 2004 at 10:35:15PM +0000, Keir Fraser wrote:
> > > - install ksymoops/System.map on those nodes so that we can get
> > >   meaningful oops output if it does happen again (per earlier mail from
> > >   Ian and Bin)
> > 
> > Number-one priority for debugging is having access to the kernel
> > object file (it's the 'vmlinux' file at the root of the build
> > tree). Given that, and the precise version of Xen/Xenolinux that you
> > built, I can have a fair stab at unpicking what happened. If the crash
> > is in Xen itself then the Xen image file is what I need ('xen' file at
> > teh root of the Xen build tree).
> > 
> > Symbolic backtraces are nice but definitely of secondary importance.
> > 
> > > The reason I'm doing this in a chroot is that I'm thinking of setting up
> > > an automated Xen regression test environment under Xen, daily pulls,
> > > that sort of thing.  This NFS root would be a build server for that
> > > environment.  Is anyone already working on something like this?
> > 
> > We have a regression test here in the lab, but:
> >  1. It uses some SPEC benchmarks, so it's not publically distributable.
> >  2. It's based on an old Redhat -- a more up-to-date filesystem would
> >  be good.
> >  3. We don't have enough spare machines to do a really large test.
> > 
> > Your setup sounds liek it could be much better!
> > 
> >  -- Keir
> > 
> > 
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
> 
> -- 
> Stephen G. Traugott  (KG6HDQ)
> UNIX/Linux Infrastructure Architect, TerraLuna LLC
> stevegt@xxxxxxxxxxxxx 
> http://www.stevegt.com -- http://Infrastructures.Org 

-- 
Stephen G. Traugott  (KG6HDQ)
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@xxxxxxxxxxxxx 
http://www.stevegt.com -- http://Infrastructures.Org 


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel