[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xm pause causing lockup
I haven't tracked down the problem yet, but I thought the following was sufficiently interesting to post: kmacy@curly while (1) while? xm list while? sleep 5 while? end Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 507 0 r---- 67.9 xen-vm2 1 128 1 r---- 4.0 9601 Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 507 0 r---- 68.1 xen-vm2 1 128 1 r---- 4.0 9601 Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 507 0 r---- 68.3 xen-vm2 1 128 1 r---- 4.0 9601 Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 507 0 r---- 68.5 xen-vm2 1 128 1 r---- 4.0 9601 Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 507 0 r---- 68.7 xen-vm2 1 128 1 r---- 4.0 9601 Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 507 0 r---- 68.9 xen-vm2 1 128 1 r---- 4.0 9601 xen-vm2 is always shown as running, but its time is not increasing. -Kip On 4/13/05, Kip Macy <kip.macy@xxxxxxxxx> wrote: > On 4/13/05, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote: > > Probably easiest way to trace this is with printk's in Xen. The guts of > > the work is done by domain_pause_by_systemcontroller() in xen/sched.h. > > This in turn calls domain_sleep() in common/schedule.c. > > I traced through that code a while back when trying to decide what to > call from the int3 handler. > > A particularly > > interesting place to look will be teh synchronous spin loop at the end > > of domain_sleep -- if the paused domain isn't descheduled for some > > weird reason then the spin loop would never exit and domain0 would > > hang. > > Good point. It will be interesting to see. > > I sometimes wonder if I should keep some of the buggy versions of > FreeBSD around for regression testing as they trigger some interesting > behaviours in xen and xend. > > -Kip > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |