[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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:

>1025         if ((irqflags & (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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.