Re: [Xen-devel] Re: VM hung after running sometime

[wei song <james.songwei@xxxxxxxxx>]

I also noticed that  there are only one port(number 2) bind to vcpu1, I wonder that what this port use to do?
(XEN) [2010-09-21 17:09:04] Domain 3 polling vCPUs: {}
(XEN) [2010-09-21 17:09:04] Event channel information for domain 3:
(XEN) [2010-09-21 17:09:04]     port [p/m]
(XEN) [2010-09-21 17:09:04]        1 [0/1]: s=3 n=0 d=0 p=42 x=1
(XEN) [2010-09-21 17:09:04]        2 [0/1]: s=3 n=1 d=0 p=43 x=1
(XEN) [2010-09-21 17:09:04]        3 [0/0]: s=3 n=0 d=0 p=41 x=0
(XEN) [2010-09-21 17:09:04]        4 [0/1]: s=2 n=0 d=0 x=0
(XEN) [2010-09-21 17:09:04]        5 [0/0]: s=6 n=0 x=0
(XEN) [2010-09-21 17:09:04]        6 [0/0]: s=2 n=0 d=0 x=0
(XEN) [2010-09-21 17:09:04]        7 [0/0]: s=3 n=0 d=0 p=44 x=0
(XEN) [2010-09-21 17:09:04]        8 [0/0]: s=3 n=0 d=0 p=45 x=0

regards,

2010/9/21 wei song <james.songwei@xxxxxxxxx>

I also met this issue, especially running high work load on HVM vms with xen 4.0.0 + pvops 2.6.31.13xen. I noticed port 1 of VCPU1 always be blocked on this port, the system of vcpu0 is normal but stopped on vcpu1.   Jeremy, could you please take a look on this issue? Could you give some idea on it?

thanks,
James

2010/9/21 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>

On 21/09/2010 06:02, "MaoXiaoyun" <tinnycloud@xxxxxxxxxxx> wrote:

> Take a look at domain 0 event channel with port 105,106, I find on port 105,
> it pending is
> 1.(in [1,0], first bit refer to pending, and is 1, second bit refer to mask,
> is 0).
>
> (XEN)      105 [1/0]: s=3 n=2 d=10 p=1 x=0
> (XEN)      106 [0/0]: s=3 n=2 d=10 p=2 x=0
>
> In all, we have domain U cpu blocking on _VPF_blocked_in_xen, and it must set
> the pending bit.
> Consider pending is 1, it looks like the irq is not triggered, am I  right ?
> Since if it is triggerred, it should clear the pending bit. (line 361).

Yes it looks like dom0 is not handling the event for some reason. Qemu looks
like it still works and is waiting for a notification via select(). But that
won't happen until dom0 kernel handles the event as an IRQ and calls the
relevant irq handler (drivers/xen/evtchn.c:evtchn_interrupt()).

I think you're on the right track in your debugging. I don't know much about
the pv_ops irq handling path, except to say that this aspect is different
than non-pv_ops kernels which special-case handling of events bound to
user-space rather more. So at the moment my best guess would be that the bug
is in the pv_ops kernel irq handling for this type of user-space-bound
event.

 -- Keir

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

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