Dear Arnaud Ebalard, On Sat, 18 Jan 2014 22:49:17 +0100, Arnaud Ebalard wrote: > I started suspecting the introduction of MSI support in Marvell PCIe > host controller driver (FL1009 is on the PCIe bus) and compiled a > a 3.13.0-rc8 w/ CONFIG_PCI_MSI disabled (it was enabled in all my > previous tests): I did not manage to reproduce the issue with this > kernel. As a side note, commits 5b4deb6526bd, 31f614edb726 and > 627dfcc249e2 are > > ATM, I do not know if the problem is related to a bug in introduced MSI > support or some weird incompatibility of that functionality with the > FL1009 which would require some quirk in XHCI stack. > > Thomas, I took a look at the changes but I am not familiar w/ how MSI > work. You may have an idea on what is going on here. I finally got some idea: your kernel 3.13-rc7 lacks a very important fix we did in the irqchip driver MSI handling. You really need to have http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/irqchip/irq-armada-370-xp.c?id=c7f7bd4a136e4b02dd2a66bf95aec545bd93e8db applied to get proper MSI behavior. Without this patch, there is a race condition, and some MSI interrupts might be lost. This commit was merged in v3.14-rc2, and backported to 3.13 and previous stable releases. Can you test after applying this commit? > ps: Thomas, this is completely unrelated but the code below caught my > eye at the beginning of a hunk in 31f614edb726. When CONFIG_PCI_MSI is > disabled, why is irqnr now compared to 1 instead of 0? This is not important. IRQs 0 and 1 are reserved for doorbells, which are only used for IPI (IRQ 0) and MSI (IRQ 1). Therefore, doing irq_find_mapping() for either IRQ 0 or IRQ 1 is not useful. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
