linux-kernel - 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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.00.1303210012001.16237@pobox.suse.cz>
Date:	Thu, 21 Mar 2013 00:14:22 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Daniel Vetter <daniel.vetter@...ll.ch>,
	Alan Stern <stern@...land.harvard.edu>,
	Chris Wilson <chris@...is-wilson.co.uk>,
	Greg KH <greg@...ah.com>,
	Harald Arnesen <skogtun.linux@...il.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Peter Hurley <peter@...leysoftware.com>,
	Thomas Meyer <thomas@...3r.de>,
	Shawn Starr <shawn.starr@...ers.com>,
	USB list <linux-usb@...r.kernel.org>,
	linux-acpi@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
	linux-pci@...r.kernel.org, Imre Deak <imre.deak@...el.com>,
	Daniel Kurtz <djkurtz@...omium.org>,
	dri-devel@...ts.freedesktop.org,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Arkadiusz Miskiewicz <a.miskiewicz@...il.com>
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

On Tue, 19 Mar 2013, Yinghai Lu wrote:

> > 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?
> 
> You may try to add another request_irq()
> after i915_load_modeset_init==>drm_irq_install.
> That could install one dummy action for ioapic irq for i915.
> 
> Also you may need to add one quirk that does not disable intx during
> msi enabling like:
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
>                         0x2e22,
>                         quirk_msi_intx_disable_bug);
> 

This seemed to be really promising idea to me, as the DisINTx+ vs INTx+ 
discrepancy is very good hint, but unfortunately, after applying this:

---
 drivers/pci/quirks.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 0369fb6..8508e24 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2643,6 +2643,9 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x1073,
 			quirk_msi_intx_disable_bug);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x1083,
 			quirk_msi_intx_disable_bug);
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2a42,
+			quirk_msi_intx_disable_bug);
 #endif /* CONFIG_PCI_MSI */
 
 /* Allow manual resource allocation for PCI hotplug bridges


The problem is still there ... so the inconsistency between DisINTx+ and 
INTx+ is unfortunately not the whole story.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/