Re: cpuidle and un-eoid interrupts at the local apic

["Thimo Eichstädt" <t.eichstaedt@digithi.de>]

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
>