Re: Re: VM hung after running sometime

[wei song <james.songwei@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2765 bytes --]

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@gmail.com>

> 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@eu.citrix.com>
>
> On 21/09/2010 06:02, "MaoXiaoyun" <tinnycloud@hotmail.com> 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@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3896 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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