2012-05-03 19:56:18

by Jiri Slaby

[permalink] [raw]
Subject: Re: i915_driver_irq_handler: irq 42: nobody cared

On 04/11/2012 12:40 PM, Daniel Vetter wrote:
> On Tue, Apr 10, 2012 at 01:34:11PM -0700, Jesse Barnes wrote:
>> On Tue, 10 Apr 2012 22:32:12 +0200
>> Daniel Vetter <[email protected]> wrote:
>>
>>> On Tue, Apr 10, 2012 at 09:52:40PM +0200, Jiri Slaby wrote:
>>>> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>
>>>> I tried 3.2 and 3.3. Although the spurious interrupts were always
>>>> there, they occurred with frequency lower by a magnitude (15 vs. 300
>>>> after X starts). So I bisected that and it lead to a commit which
>>>> fixes bad tiling for me:
>>>> http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=for-jiri&id=79710e6ccabdac80c65cd13b944695ecc3e42a9d
>>>
>>> Pipelined fencing is pretty much just broken and we'll completely rip it
>>> out in 3.5. Does this also happen with 3.4-rc2?
>>
>> Does INTx- stay that way? Or does it frequently read INTx+ if you
>> sample it a lot? If it stays as INTx-, then something other than the
>> GPU is getting stuck (though it's possible this could be related to
>> pipelined fencing, if the fences are programmed to point at some funky
>> memory space).

Hi and sorry for the delay. It stays INTx-. And I tested that with patch
removing fencing.

> Shot in the dark, let's disable msi a bit. Can you try the below patch?

Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
busted, either in the card, the chipset or the kernel. Any idea how to
find out?

thanks,
--
js
suse labs


2012-05-03 21:14:35

by Daniel Vetter

[permalink] [raw]
Subject: Re: i915_driver_irq_handler: irq 42: nobody cared

On Thu, May 03, 2012 at 09:56:08PM +0200, Jiri Slaby wrote:
> On 04/11/2012 12:40 PM, Daniel Vetter wrote:
> > On Tue, Apr 10, 2012 at 01:34:11PM -0700, Jesse Barnes wrote:
> >> On Tue, 10 Apr 2012 22:32:12 +0200
> >> Daniel Vetter <[email protected]> wrote:
> >>
> >>> On Tue, Apr 10, 2012 at 09:52:40PM +0200, Jiri Slaby wrote:
> >>>> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> >>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >>>>
> >>>> I tried 3.2 and 3.3. Although the spurious interrupts were always
> >>>> there, they occurred with frequency lower by a magnitude (15 vs. 300
> >>>> after X starts). So I bisected that and it lead to a commit which
> >>>> fixes bad tiling for me:
> >>>> http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=for-jiri&id=79710e6ccabdac80c65cd13b944695ecc3e42a9d
> >>>
> >>> Pipelined fencing is pretty much just broken and we'll completely rip it
> >>> out in 3.5. Does this also happen with 3.4-rc2?
> >>
> >> Does INTx- stay that way? Or does it frequently read INTx+ if you
> >> sample it a lot? If it stays as INTx-, then something other than the
> >> GPU is getting stuck (though it's possible this could be related to
> >> pipelined fencing, if the fences are programmed to point at some funky
> >> memory space).
>
> Hi and sorry for the delay. It stays INTx-. And I tested that with patch
> removing fencing.
>
> > Shot in the dark, let's disable msi a bit. Can you try the below patch?
>
> Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
> busted, either in the card, the chipset or the kernel. Any idea how to
> find out?

Ok, so MSI is busted. Can you please paste lspci -nn for you intel gpu?
-Daniel
--
Daniel Vetter
Mail: [email protected]
Mobile: +41 (0)79 365 57 48

2012-05-03 21:16:08

by Jiri Slaby

[permalink] [raw]
Subject: Re: i915_driver_irq_handler: irq 42: nobody cared

On 05/03/2012 11:15 PM, Daniel Vetter wrote:
>>> Shot in the dark, let's disable msi a bit. Can you try the below patch?
>>
>> Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
>> busted, either in the card, the chipset or the kernel. Any idea how to
>> find out?
>
> Ok, so MSI is busted. Can you please paste lspci -nn for you intel gpu?

Sure:
00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31
Express Integrated Graphics Controller [8086:29c2] (rev 02)

thanks,
--
js
suse labs

2012-05-03 21:54:28

by Jesse Barnes

[permalink] [raw]
Subject: Re: i915_driver_irq_handler: irq 42: nobody cared

On Thu, 03 May 2012 23:16:02 +0200
Jiri Slaby <[email protected]> wrote:

> On 05/03/2012 11:15 PM, Daniel Vetter wrote:
> >>> Shot in the dark, let's disable msi a bit. Can you try the below patch?
> >>
> >> Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
> >> busted, either in the card, the chipset or the kernel. Any idea how to
> >> find out?
> >
> > Ok, so MSI is busted. Can you please paste lspci -nn for you intel gpu?
>
> Sure:
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31
> Express Integrated Graphics Controller [8086:29c2] (rev 02)

Ok nevermind about the INTx-; now I'm not sure if it means anything or
not in an MSI context (the spec doesn't require it, but I thought our
devices would toggle it if they were sending interrupts).

But since line level works for you I guess it's ok to blacklist your
chipset until we poke some hw folks internally about this.

Thanks,
--
Jesse Barnes, Intel Open Source Technology Center

2012-05-03 23:23:17

by Ben Widawsky

[permalink] [raw]
Subject: Re: i915_driver_irq_handler: irq 42: nobody cared

On Thu, 3 May 2012 14:54:22 -0700
Jesse Barnes <[email protected]> wrote:

> On Thu, 03 May 2012 23:16:02 +0200
> Jiri Slaby <[email protected]> wrote:
>
> > On 05/03/2012 11:15 PM, Daniel Vetter wrote:
> > >>> Shot in the dark, let's disable msi a bit. Can you try the below patch?
> > >>
> > >> Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
> > >> busted, either in the card, the chipset or the kernel. Any idea how to
> > >> find out?
> > >
> > > Ok, so MSI is busted. Can you please paste lspci -nn for you intel gpu?
> >
> > Sure:
> > 00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31
> > Express Integrated Graphics Controller [8086:29c2] (rev 02)
>
> Ok nevermind about the INTx-; now I'm not sure if it means anything or
> not in an MSI context (the spec doesn't require it, but I thought our
> devices would toggle it if they were sending interrupts).
>
> But since line level works for you I guess it's ok to blacklist your
> chipset until we poke some hw folks internally about this.
>
> Thanks,

I occassionally see missed IRQ on 16 (which is my USB) but it has only
started showing up in fairly recent dinq (haven't tried Linus') kernels
(I'd been using this laptop for over a year).


--
Ben Widawsky, Intel Open Source Technology Center