Re: i2c-i801 driver quit working in 3.8.11

[Jean Delvare <jdelvare-l3A5Bk7waGM@public.gmane.org>]

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.

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.

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.

-- 
Jean Delvare
SUSE L3 Support