Re: [Xen-devel] cpuidle and un-eoid interrupts at the local apic

[Thimo Eichstädt <t.eichstaedt@xxxxxxxxxx>]

Hello Andrew,

I've disabled MSI on that controller, now it is running with level 
triggered IRQs. No crash so far with these settings.
But what I see are a lot of spurious interrupts for every type of IRQ on 
my machine, Here an example:
[root@localhost /]# cat /proc/irq/1276/spurious
count 61007
unhandled 0
last_unhandled 36736990 ms

I can see this for the ethernet irqs, usb, sata and so on.

I've already written it into another mail on Sunday:

>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;

--> When using MSI on the SATA controller the kernel indicates me that 
IRQF_SHARED for that interrupt  is set, so the MSI  is shared ?! I 
thought that it is not possible that MSI interrupts are shared.
--> Is that what we see in the kernel oops the stack overflow the 
comment in lines 738-742 is talking about ?! Espacially because the 
warning in 1028 tells me that IRQF_DISABLED might not be set on shared 
interrupts.
Am 09.09.2013 15:16, schrieb Andrew Cooper:
> So in this case, irq29 is now your SATA controller.
>
> I presume you are still falling over the same basic assertion for the
> pending EOI stack?
>
> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel