linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shawn Starr <shawn.starr@rogers.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>,
	Jiri Kosina <jkosina@suse.cz>, Daniel Vetter <daniel@ffwll.ch>,
	Greg KH <greg@kroah.com>,
	Harald Arnesen <skogtun.linux@gmail.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Peter Hurley <peter@hurleysoftware.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Thomas Meyer <thomas@m3y3r.de>,
	USB list <linux-usb@vger.kernel.org>,
	linux-acpi@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, Yinghai Lu <yinghai@kernel.org>,
	Imre Deak <imre.deak@intel.com>,
	Daniel Kurtz <djkurtz@chromium.org>,
	dri-devel@lists.freedesktop.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Arkadiusz Miskiewicz <a.miskiewicz@gmail.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)))
Date: Sun, 24 Mar 2013 15:44:59 -0400	[thread overview]
Message-ID: <1941778.XPux1HxP8Z@segfault.sh0n.net> (raw)
In-Reply-To: <CAKMK7uGnZFaLQaZtoQ0Fz0ViNNjBvmf0Ak=qPmdAcm2mRBD7rA@mail.gmail.com>

On Tuesday, March 19, 2013 04:12:18 PM Daniel Vetter wrote:
> On Tue, Mar 19, 2013 at 10:03 AM, Chris Wilson <chris@chris-wilson.co.uk> 
wrote:
> >> > How about just using:
> >> >   if (!HAS_GMBUS_IRQ(dev_priv->dev)) gmbus4_irq_en = 0;
> >> > 
> >> > and the existing wait loop?
> >> 
> >> I explicitly wanted to avoid touching GMBUS4 register, as the real cause
> >> of the failure is not clear.
> >> 
> >> But, as Yinghai Lu points out, the problem is most likely caused by
> >> interrupt disabling not working properly (see his very good point
> >> regarding DisINTx+ and INTx+ discrepancy), so zeroing the register out
> >> should work .... and it indeed does in my case, hence the (tested) patch
> >> below.
> >> 
> >> I think it's a 3.9-rc material, and I am all open to debug this further
> >> for 3.10 so that the race is closed and gmbus irqs can be used on Gen4
> >> platform properly.
> > 
> > Agreed. Using the IRQ for GMBUS is just a performance feature that can
> > be deferred until after we determine the root cause - and hope that the
> > failure is somehow peculiar to GMBUS.
> 
> Ok, I've merged this patch. But some further investigation points at a
> much more severe dragon hiding here: The MSI interrupt for the intel
> gfx is commonly in the 40+ range, but the interrupt vector with the
> spurious interrupts is 16. Which is the irq of the intel gfx when MSI
> is disabled!
> 
> So it looks like gmbus on the intel gfx is capable of generating
> non-MSI interrupts in parallel to the MSI interrupts (since apparently
> gmbus still works, so we get the interrupts we expect). I have no idea
> how that could happen. Hence adding a bunch of people with more clue
> than me.
> 

Hello folks,

I am using Linus git master and built an rpm for 3.9.0-rc4 which has Jiri's 
patch. I confirm this patch returns the GMA 4500 to working behavior as in 
3.8.

Thanks everyone.
Shawn

> For reference below the updated commit message.
> 
> Cheers, Daniel
> 
> Author: Jiri Kosina <jkosina@suse.cz>
> 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).
> 
>     I have no idea how that even can happen.
> 
>     To avoid tempting this elephant into a rage, just disable gmbus
>     interrupt support on gen 4.
> 
>     v2: Improve the commit message with exact details of what's going on.
>     Also add a comment in the code to warn against this particular
>     elephant in the room.
> 
>     Signed-off-by: Jiri Kosina <jkosina@suse.cz> (v1)
>     Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
>     References: https://lkml.org/lkml/2013/3/8/325
>     Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

      parent reply	other threads:[~2013-03-24 19:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-19 15:12 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))) Daniel Vetter
2013-03-19 15:38 ` 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 Alan Stern
2013-03-19 16:54   ` Daniel Vetter
2013-03-19 18:18     ` 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 respo Alan Stern
2013-03-20 16:29       ` Jiri Kosina
2013-03-20 17:23         ` Alan Stern
2013-03-20 23:21           ` [PATCH] dummy-irq: introduce a dummy IRQ handler driver (was 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 respo)) Jiri Kosina
2013-03-20 23:37             ` Greg KH
2013-03-21 14:45             ` Daniel Vetter
2013-03-31 19:55               ` Jiri Kosina
2013-04-01 18:30                 ` Daniel Vetter
2013-03-19 19:14     ` 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 Yinghai Lu
2013-03-20 23:14       ` Jiri Kosina
2013-03-24 19:44 ` Shawn Starr [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1941778.XPux1HxP8Z@segfault.sh0n.net \
    --to=shawn.starr@rogers.com \
    --cc=a.miskiewicz@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=djkurtz@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=greg@kroah.com \
    --cc=hpa@zytor.com \
    --cc=imre.deak@intel.com \
    --cc=jkosina@suse.cz \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=peter@hurleysoftware.com \
    --cc=rjw@sisk.pl \
    --cc=skogtun.linux@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.de \
    --cc=thomas@m3y3r.de \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).