[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] cpuidle and un-eoid interrupts at the local apic
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 >> > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |