Ah, sorry.  Output is attached.

Am 08.09.2013 11:53, schrieb Andrew Cooper:
> On 08/09/2013 00:37, Thimo E. wrote:
>> Hello Andrew,
>>
>> ok, thanks. This is what I assumed.
>>
>> The output of "xl debug-keys iMQ" is empty.
> Sorry - I should have been more clear.  `xl debug-keys` dumps its
> information into the xen dmesg buffer, so `xl dmesg` will capture the
> results.
>
> ~Andrew
>
>> [root@localhost ~]#  dmesg |grep arcmsr
>> [    8.159321] arcmsr 0000:01:00.0: PCI INT A -> GSI 16 (level, low)
>> -> IRQ 16
>> [    8.159413] arcmsr 0000:01:00.0: setting latency timer to 64
>> [    8.170316] arcmsr 0000:01:00.0: get owner: 7ff0
>> [    8.170414] arcmsr 0000:01:00.0: irq 1276 (276) for MSI/MSI-X
>> [    8.170421] IRQ 1276/arcmsr: IRQF_DISABLED is not guaranteed on
>> shared IRQs
>> [    8.170654] arcmsr0: msi enabled
>>
>> [root@localhost /]# cat /proc/irq/1276/spurious
>> count 61007
>> unhandled 8
>> last_unhandled 36736990 ms
>>
>> arcmsr is the driver of the Areca Storage Raid Controller. Used it
>> already before with Xenserver 6.0.2 for years, no problems.
>>
>> THe messages "IRQF_DISABLED is not guaranteed...." and "8 unhandled
>> interrupts" look interesting. I am not a kernel hacker but what I
>> interpret from
>> http://lxr.free-electrons.com/source/kernel/irq/manage.c?v=2.6.32:
>>
>> 1025         if ((irqflags & (IRQF_SHARED|IRQF_DISABLED)) ==
>> 1026 (IRQF_SHARED|IRQF_DISABLED)) {
>> 1027                 pr_warning(
>> 1028                   "IRQ %d/%s: IRQF_DISABLED is not guaranteed on
>> shared IRQs\n",
>> 1029                         irq, devname);
>> ...
>> 738                  * Force MSI interrupts to run with interrupts
>> 739                  * disabled. The multi vector cards can cause stack
>> 740                  * overflows due to nested interrupts when enough of
>> 741                  * them are directed to a core and fire at the same
>> 742                  * time.
>> 743                  */
>> 744                 if (desc->msi_desc)
>> 745                         new->flags |= IRQF_DISABLED;
>>
>> --> "IRQF_DISABLED is not guaranteed on shared IRQs" warning is only
>> printed when irqflags IRQF_SHARED and IRQF_DISABLED are set
>> --> Is that what we see in the kernel oops the stack overflow the
>> comment in lines 738-742 is talking about ?!
>> --> IRQF_SHARED is set, so MSI interrupt 1276 is shared ?! I thought
>> that it is not possible that MSI interrupts are shared. Attached
>> you'll see my /proc/interrupts
>>
>> So what I do now is disabling MSI for the arcmsr driver. Could this be
>> the source of the problem ?! But why is 1276 shared ?!
>>
>> Best regards
>>    Thimo
>>
>> Am 07.09.2013 19:02, schrieb Andrew Cooper:
>>> irq 29 is just an internal Xen number for accounting all interrupts.  It
>>> doesn't mean anything specific regarding hardware etc.  The vector and
>>> affinity would expect to change as dom0s vcpus are moved around by the
>>> scheduler.
>>>
>>> domain-list=0 means that this interrupt is targeted at dom0 (It is a
>>> list because certain interrupts have to be shared my more than 1
>>> domain).  Helpfully, the keyhandler truncates the pirq field, so 276 is
>>> unlikely to be correct.  As it is a dom0 MSI, I am guessing it actually
>>> matches up with interrupt 1276 in /proc/interrupts, if there is one.
>>>
>>> Can you provide the results of `xl debug-keys iMQ`, and attach
>>> /proc/interrupts to this email (just in case the setup has changed after
>>> playing with your BIOS)
>>>
>>> ~Andrew
>>>