Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757145Ab3CSQyx (ORCPT ); Tue, 19 Mar 2013 12:54:53 -0400 Received: from mail-ie0-f180.google.com ([209.85.223.180]:58636 "EHLO mail-ie0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756998Ab3CSQyv (ORCPT ); Tue, 19 Mar 2013 12:54:51 -0400 MIME-Version: 1.0 X-Originating-IP: [178.83.130.250] In-Reply-To: References: Date: Tue, 19 Mar 2013 17:54:50 +0100 Message-ID: Subject: Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses From: Daniel Vetter To: Alan Stern Cc: Chris Wilson , Jiri Kosina , Greg KH , Harald Arnesen , Kernel development list , "Rafael J. Wysocki" , Peter Hurley , Thomas Meyer , Shawn Starr , USB list , linux-acpi@vger.kernel.org, Bjorn Helgaas , linux-pci@vger.kernel.org, Yinghai Lu , Imre Deak , Daniel Kurtz , dri-devel@lists.freedesktop.org, Thomas Gleixner , "H. Peter Anvin" , x86@kernel.org, Arkadiusz Miskiewicz Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3401 Lines: 71 On Tue, Mar 19, 2013 at 4:38 PM, Alan Stern wrote: > On Tue, 19 Mar 2013, Daniel Vetter wrote: > >> For reference below the updated commit message. >> >> Cheers, Daniel >> >> Author: Jiri Kosina >> 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] [] __report_bad_irq+0x1d/0xc7 >> [ 9.640731] [] note_interrupt+0x15b/0x1e8 >> [ 9.640731] [] handle_irq_event_percpu+0x1bf/0x214 >> [ 9.640731] [] handle_irq_event+0x3c/0x5c >> [ 9.640731] [] handle_fasteoi_irq+0x7a/0xb0 >> [ 9.640731] [] handle_irq+0x1a/0x24 >> [ 9.640731] [] do_IRQ+0x48/0xaf >> [ 9.640731] [] common_interrupt+0x6a/0x6a >> [ 9.640731] [] ? system_call_fastpath+0x16/0x1b >> [ 9.640731] handlers: >> [ 9.640731] [] usb_hcd_irq [usbcore] >> [ 9.640731] [] 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/