[Xen-devel] FW: Xen 4.1 interrupts not delievered.

["Lin, Ray" <Ray.Lin@xxxxxxx>]

  We experienced the domU interrupt/DMA issue before. The symptom is like the 
/proc/interrupts/irq# of Tachyon chip (FC controller) keep on incrementing, but 
nobody is serving the interrupts. Eventually the count of these unserved 
interrupts reach the max. and are forced to be disabled.  With Konrad's 
dom0/domU configuration, this issue is resolved now.


-Ray
     
-----Original Message-----
From: Bruce Edge [mailto:bruce.edge@xxxxxxxxx] 
Sent: Friday, October 15, 2010 12:01 PM
To: Lin, Ray
Subject: Fwd: Xen 4.1 interrupts not delievered.

On 13/10/2010 08:00, "Sander Eikelenboom" <linux@xxxxxxxxxxxxxx> wrote:

> Hello Keir,
>
> OK let's rephrase, in what cases is it logical that the xen serial 
> console freezes together with dom0 ?
> For example some deadlock causes cpu0 to stall on a heavily loaded system ..
> I think having the serial console available to dump the machines state 
> is quite vital :-(

Oh, there was a fix for serial interrupt routing: xen-unstable:22148 or 
xen-4.0-testing:21342. Are you running a more recent hypervisor than that?
The fix prevents serial interrupt from being migrated away from pcpu0, which 
will not work as there is no vector allocated for it on other pcpus. This kind 
of fits with the bug you're seeing, which doesn't manifest if you leave pcpu0 
unloaded (and hence presumably serial interrupt binding prefers to stay with 
unloaded pcpu0).

 -- Keir

> I have tried the max_cstate=1 together with the latest 
> 2.6.32-xen-next-pvops kernel as dom0 kernel (which Ian's fix to the event 
> channels).
> But with the compile test it freezes just as fast.
> Will try xen before changesets 20072/20073 now, probably with 2.6.31 
> pvops, since 2.6.32 would need a more recent hypervisor.
>
> --
> Sander
>
>
> Wednesday, October 13, 2010, 1:34:58 AM, you wrote:
>
>> On 12/10/2010 18:17, "Konrad Rzeszutek Wilk" <konrad.wilk@xxxxxxxxxx> wrote:
>
>>> A couple of that might fix the problems are:
>>>
>>>  1). Ian's fix to the event channels:
>>> http://xenbits.xen.org/gitweb?p=people/ianc/linux-2.6.git;a=commit;h
>>> =5d30cb2
>>> a8
>>> 5912ffb5f6556d55472c26801eef2ea
>>>  2). Disable IRQ balancing in Xen (and also in Linux kernel). "noirqbalance"
>>>  3). Pin domains, but nothing to Domain 0.
>
>> ITYM cpu 0. Not that this should rightly make any difference that I can see.
>
>> My suspicion would be the per-CPU IDT patches introduced during 4.0 
>> development. Or changes to enable deep C-state sleeps by default. One 
>> or the other causing lost interrupts. I think the latter can be 
>> discounted by
>> max_cstate=1 as a Xen boot parameter. The former would require trying 
>> a build of Xen before and after changesets 20072/20073 -- they are 
>> the ones that did the heavy lifting to implement per-CPU IDTs.
>
>>  -- Keir
>
>>> But it might be worth trying them out?
>
>
>
>

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