Re: [Xen-devel] xm pause causing lockup

[Kip Macy <kip.macy@xxxxxxxxx>]

To further check this I added:
 printk("%s %d %d %d %d %d\n", __FUNCTION__, op->cmd, op->mfn, count,
success_count, domid);
to HYPERVISOR_mmuext_op and something similar to mmu_update.


HYPERVISOR_mmu_update 0xc0200ba0 1 0 32752
HYPERVISOR_mmu_update 0xc0200ba0 1 0 32752
HYPERVISOR_mmuext_op 7 -1069543424 1 0 32752
HYPERVISOR_mmu_update 0xc0200ba0 1 0 32752
HYPERVISOR_mmu_update 0xc0200ba0 1 0 32752
HYPERVISOR_mmuext_op 7 -955666432 1 0 32752
HYPERVISOR_mmuext_op 1 25359 1 0 32752
<lockup>

I'm not sure where I could add printks to
get_page_and_type_from_pagenr without making DOM0 take forever to
boot. Suggestions are welcome. Alternatively you could do me a favor
and just run my FreeBSD binary locally.


On 4/14/05, Kip Macy <kip.macy@xxxxxxxxx> wrote:
> I think there may be a bug in your page pinning validation logic - the
> lockup occurs when stepping through xen_pgd_pin. I don't know if I'm
> really passing in 0, as register locals can quickly get overwritten,
> but it is certainly worth checking.
> 
> Breakpoint 15, pmap_pinit (pmap=0xc06900c0) at
> ../../../i386-xen/i386-xen/pmap.c:1206
> 1206                    xen_pgd_pin(ma);
> (gdb)
> Continuing.
> 
> Breakpoint 8, xen_pgd_pin (ma=0x0) at
> ../../../i386-xen/i386-xen/xen_machdep.c:490
> 490         op.cmd = MMUEXT_PIN_L2_TABLE;
> (gdb) s
> 491         op.mfn = ma >> PAGE_SHIFT;
> (gdb)
> 492         xen_flush_queue();
> (gdb)
> 
> Breakpoint 4, xen_flush_queue () at 
> ../../../i386-xen/i386-xen/xen_machdep.c:431
> 431         if (XPQ_IDX != 0) _xen_flush_queue();
> (gdb)
> 432     }
> (gdb)
> xen_pgd_pin (ma=0x630f) at hypervisor.h:72
> 72      {
> (gdb)
> 76          __asm__ __volatile__ (
> (gdb)
> 
> 
> On 4/14/05, Kip Macy <kip.macy@xxxxxxxxx> wrote:
> > 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