Very strange! Seems it is related to different platforms. Maybe potential bugs invoked these troubles in smp environment. :) I will retry to produce them and wish to get it. Thanks. -Xiantao
OTC,Intel Corporation > -----Original Message----- > From: Alex Williamson [mailto:[EMAIL PROTECTED] > Sent: 2006年6月21日 11:11 > To: Zhang, Xiantao > Cc: xen-ia64-devel@lists.xensource.com > Subject: RE: [Xen-ia64-devel] [PATCH]Enable xen0 smp when machine only has2LPs > > On Wed, 2006-06-21 at 10:04 +0800, Zhang, Xiantao wrote: > > Hi Alex, > > I couldn't reproduce your troubles here with this change. Could you > > check with "xm vcpu-list" to see the time of vcpus? I also found xenU > > state "-----", but I think it should be normal, because LPs were > > occupied by xen0 at that time. Only if time of vcpus is increasing, > > domU should be alive. > > Hi Xiantao, > > The vcpu time on my domU was not increasing. The watchdog oops in > the domU when kicking it with xenctx also indicates that domU was > getting no time. FWIW, I saw this on a zx6000, madison system (2-way > box). I was booting a UP dom0 w/ 2GB of memory, and a UP domU w/ 1GB of > memory. DomU is configured with 1 vnif, and only booted to single user > mode. I usually saw the domU hang within about 5 reboots. > > > I am also confused that CONFIG_NR_CPUS was set to 16 in xenU's > > configuration file(linux-defconfig_xenU_ia64), Why not come across > > those troubles before? > > Nobody tests the -xenU kernel on a regular basis anymore. I > typically only test the -xen kernel. > > > Maybe we should come out a better solution for this issue. Anyway it > > is a must to set CONFIG_NR_CPUS to >4 for xen0 and XenU when LPs >4. > > I agree, and I can't explain why such a seemingly simple change > triggered this problem. Thanks, > > Alex > > -- > Alex Williamson HP Open Source & Linux Org. _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
