On Tue, Mar 19, 2013 at 4:38 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 19 Mar 2013, Daniel Vetter wrote:
>
>> For reference below the updated commit message.
>>
>> Cheers, Daniel
>>
>> Author: Jiri Kosina <jkosina@xxxxxxx>
>> Date: Tue Mar 19 09:56:57 2013 +0100
>
>>
>> drm/i915: stop using GMBUS IRQs on Gen4 chips
>>
>> Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to
>> using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
>> and above.
>>
>> It turns out though that on many systems this leads to spurious interrupts
>> being generated, long after the register write to disable the IRQs has been
>> issued.
>>
>> Typically this results in the spurious interrupt source getting
>> disabled:
>>
>> [ 9.636345] irq 16: nobody cared (try booting with the "irqpoll" option)
>> [ 9.637915] Pid: 4157, comm: ifup Tainted: GF
>> 3.9.0-rc2-00341-g0863702 #422
>> [ 9.639484] Call Trace:
>> [ 9.640731] <IRQ> [<ffffffff8109b40d>] __report_bad_irq+0x1d/0xc7
>> [ 9.640731] [<ffffffff8109b7db>] note_interrupt+0x15b/0x1e8
>> [ 9.640731] [<ffffffff810999f7>] handle_irq_event_percpu+0x1bf/0x214
>> [ 9.640731] [<ffffffff81099a88>] handle_irq_event+0x3c/0x5c
>> [ 9.640731] [<ffffffff8109c139>] handle_fasteoi_irq+0x7a/0xb0
>> [ 9.640731] [<ffffffff8100400e>] handle_irq+0x1a/0x24
>> [ 9.640731] [<ffffffff81003d17>] do_IRQ+0x48/0xaf
>> [ 9.640731] [<ffffffff8142f1ea>] common_interrupt+0x6a/0x6a
>> [ 9.640731] <EOI> [<ffffffff8142f952>] ? system_call_fastpath+0x16/0x1b
>> [ 9.640731] handlers:
>> [ 9.640731] [<ffffffffa000d771>] usb_hcd_irq [usbcore]
>> [ 9.640731] [<ffffffffa0306189>] yenta_interrupt [yenta_socket]
>> [ 9.640731] Disabling IRQ #16
>>
>> The really curious thing is now that irq 16 is _not_ the interrupt for
>> the i915 driver when using MSI, but it _is_ the interrupt when not
>> using MSI. So by all indications it seems like gmbus is able to
>> generate a legacy (shared) interrupt in MSI mode on some
>> configurations. I've tried to reproduce this and the differentiating
>> thing seems to be that on unaffected systems no other device uses irq
>> 16 (which seems to be the non-MSI intel gfx interrupt on all gm45).
>
> That might be misleading. It's possible that the erroneous IRQs _are_
> being issued but you're simply not aware of them. If the kernel thinks
> that no device is using IRQ 16 then it will leave that IRQ disabled.
I guess I should have phrased it more precisely, but that's exactly
what I expect is happening on my machine: I don't have anything on
irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
the irq is completely disabled. Which obviously makes it impossible
for me to reproduce the issue. To test that theory, is there a quick
way to force-enable a given interrupt, short of just hacking up a 2nd
dummy irq handler in my driver?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
