On Thu, Aug 07, 2014 at 06:04:54PM +0200, Jean Delvare wrote: > Hi Guenter, > > Le Thursday 07 August 2014 à 07:19 -0700, Guenter Roeck a écrit : > > On 08/07/2014 01:11 AM, Jean Delvare wrote: > > > Guenter, I can confirm that the i2c-i801 driver only uses regular > > > interrupts. The datasheet does not mention anything about MSI. What > > > makes you think the problem could be related to the lack of MSI support? > > > > Working for a company that does lots of weird and non-standard stuff with PCIe > > creates a state of constant paranoia ;-). For example, INTB / irq23 may be > > used by some other chip and may not be handled properly, masking the interrupt. > > Really, I don't know. I have had instances at work where INTx didn't work > > and I _had_ to use MSI, that is all I can say. > > I had my share of MSI (and MSI-X) drama at work too, but in most cases > the problem was in the MSI/MSI-X handling code and using legacy > interrupts solved the problem (although at the expense of > performance...) > > Anyway, my understanding is that using MSI requires support at the > hardware level, you can't do that for any arbitrary PCI device, can you? > As I said I saw no mention of MSI support for the Intel SMBus device in > the datasheet, so I don't think this is possible, and thus I don't think > this can be the issue. > As far as I recall, MSI support is mandatory in PCIe. > However I found a few interesting interrupt-related bits which the > i2c-i801 driver does not handle properly. I have patches almost ready, > I'll post the soon. > > Speaking of "masking the interrupt", I am debugging another i2c-i801 > issue. On one system at work, I see the following in dmesg: > > [ 601.485791] irq 18: nobody cared (try booting with the "irqpoll" option) > [ 601.489785] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G I 3.12.25-2-default #1 > [ 601.489785] Hardware name: Supermicro X7DW3/X7DWN, BIOS 6.00 08/28/2007 > [ 601.489785] ffff880220d9574c ffffffff815096a7 ffff880220d956c0 ffffffff810ad6ad > [ 601.489785] ffff880220d956c0 0000000000000012 0000000000000000 ffffffff810adb15 > [ 601.489785] 0000000000000000 0000000000000000 0000000000000012 0000000000000000 > [ 601.489785] Call Trace: > [ 601.489785] [<ffffffff810044bd>] dump_trace+0x7d/0x2d0 > [ 601.489785] [<ffffffff810047a4>] show_stack_log_lvl+0x94/0x170 > [ 601.489785] [<ffffffff81005be1>] show_stack+0x21/0x50 > [ 601.489785] [<ffffffff815096a7>] dump_stack+0x41/0x51 > [ 601.489785] [<ffffffff810ad6ad>] __report_bad_irq+0x2d/0xc0 > [ 601.489785] [<ffffffff810adb15>] note_interrupt+0x1a5/0x260 > [ 601.489785] [<ffffffff810ab649>] handle_irq_event_percpu+0xc9/0x1b0 > [ 601.489785] [<ffffffff810ab762>] handle_irq_event+0x32/0x50 > [ 601.489785] [<ffffffff810ae5e1>] handle_fasteoi_irq+0x51/0xf0 > [ 601.489785] [<ffffffff8100439a>] handle_irq+0x1a/0x30 > [ 601.489785] [<ffffffff815198f5>] do_IRQ+0x45/0xb0 > [ 601.489785] [<ffffffff8150faad>] common_interrupt+0x6d/0x6d > [ 601.489785] [<ffffffff8103f0c2>] native_safe_halt+0x2/0x10 > [ 601.489785] [<ffffffff8100b029>] default_idle+0x19/0xb0 > [ 601.489785] [<ffffffff810aab51>] cpu_startup_entry+0xe1/0x270 > [ 601.489785] [<ffffffff8103097a>] start_secondary+0x21a/0x2c0 > [ 601.489785] handlers: > [ 601.489785] [<ffffffffa01ee220>] i801_isr [i2c_i801] > [ 601.489785] Disabling IRQ #18 > > I suppose that the IRQ is shared with another device, for which no > driver is loaded. I wonder if/how I can figure out which device this > is. /proc/interrupts says: > 18: 0 50001 0 49999 0 0 1 0 IO-APIC-fasteoi i801_smbus > and 100000 is the number of unhandled interrupts it takes to trigger the > code which disables the interrupt (note_interrupt in > kernel/irq/spurious.c.) So far so good. > You could just try to enable MSI in the driver. That won't solve the unhandled interrupt problem, but it may help you discover the other interrupt source. What happens if you do not load the i801 driver ? Do you still see an unhandled interrupt ? As for how to find the source of the unhandled interrupt - once you find out, please let me know. I have a similar problem at work. > But what I do not understand is that even after that, the i2c-i801 > driver is still working. It is very slow, it takes 100 ms to complete > each command, which is even more than when using polling. And the fact > that the figures in /proc/interrupts do not increase, mean that IRQ 18 > is really disabled. But it does not hang. However, looking at the code, > it's using wait_event() to wait for the interrupt, so I think it should > hang there is interrupt is disabled. > > Can you (or anyone else) explain this mystery? I am most certainly > missing something, maybe something obvious. > Not me, sorry. Time for some debug messages ? Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
