All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hugh Dickins <hughd@google.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>,
	Mario Kleiner <mario.kleiner@tuebingen.mpg.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/i915: Suppress spurious vblank interrupts
Date: Tue, 1 Feb 2011 10:46:17 -0800	[thread overview]
Message-ID: <AANLkTim4kL9OjBDiQQ1MBfOCzThxmDonBic11N45NKxj@mail.gmail.com> (raw)
In-Reply-To: <20110201100833.3219687e@jbarnes-desktop>

On Tue, Feb 1, 2011 at 10:08 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Tue, 1 Feb 2011 09:46:43 -0800
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>>
>> Are you still seeing underruns during normal activity?

Yes.  That is, I see the "pipe a underrun" messages when I set drm
debug 7: I'm unaware of any ill-effect from them, unless they are
indeed a factor in my unflushed text issue.

>> I wonder if the
>> ones you were seeing before were only reported at 60Hz due to vblank
>> interrupt processing.  If we failed to clear the underrun status, we'd
>> report one every time we got a vblank interrupt (since the underruns
>> don't report interrupts by themselves).

I was surprised that i915_driver_irq_handler  "Clear the PIPE(A|B)STAT
regs" writes back precisely the pipea_stats it reads in, I'd have
expected to clear something there (and did earlier experiment with
writing back 0: black screen at boot!).  But assumed the protocol is
such that it acknowledges the status bits by writing same back.

>>
>> If so, that may just be a red herring in this case.
>
> More random questions arise from the info provided:
>  - why are we ending up in the flip code at all?  fvwm shouldn't
>   trigger that path...

Right.  I haven't double-checked the logic, but I believe it's because
of bits set in the underrunning pipea_stats.  I did one time modify
the underrun message to print out pipea_stats, over five seconds most
(265) values were 0x80440207
(there were also 14 occurrences of 0x80440007, 5 of 0x80440004 and 3
of 0x80440204).

>  - what's with all the underruns?  it looks like we *do* ack those
>   flags as needed, so apparently they're valid, but they indicate a
>   serious problem with the display pipeline; maybe self-refresh
>   shouldn't be enabled on your system (that would increase memory
>   latency and potentially cause underruns), running with
>   i915.powersave=0 would disable that feature

I just tried i915.powersave=0 but the underruns still appeared.  I
then tried earlier kernels, and was surprised to find no underruns
with 2.6.34, 2.6.36: the underruns appeared with 2.6.37.

>
> The lack of text really does sound like a render cache flushing
> problem, but the other issues are worrying as well, and could be
> compounding things.  And the last time I saw the issue, it was related
> to compositing and required an X server fix.  But supposedly you're not
> using compositing, so...

That's right.

Hugh

  reply	other threads:[~2011-02-01 18:46 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-20 18:12 [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory" Arnd Bergmann
2010-12-20 18:53 ` Chris Wilson
2010-12-20 19:47   ` Arnd Bergmann
2010-12-20 19:52     ` Chris Wilson
2010-12-20 20:52       ` Arnd Bergmann
2010-12-20 21:06         ` Chris Wilson
2010-12-20 21:54           ` Arnd Bergmann
2010-12-20 22:08             ` Dave Airlie
2011-01-20 23:24           ` Frederic Weisbecker
2011-01-21 10:58             ` [PATCH] drm/i915,agp/intel: Do not clear stolen entries Chris Wilson
2011-01-21 16:26               ` Jiri Olsa
2011-01-23  1:12               ` Frederic Weisbecker
2011-01-23 11:01                 ` Chris Wilson
2011-01-23 17:59                   ` Frederic Weisbecker
2011-01-24  7:40                     ` Hugh Dickins
2011-01-24 10:10                       ` Chris Wilson
2011-01-26 21:39                         ` Arnd Bergmann
2011-01-28 22:00                         ` Hugh Dickins
2011-01-29  2:59                           ` Mario Kleiner
2011-01-30  0:28                             ` Hugh Dickins
2011-01-30  4:13                               ` Mario Kleiner
2011-01-30  9:55                                 ` Chris Wilson
2011-01-31 10:57                                   ` [PATCH] drm/i915: Suppress spurious vblank interrupts Chris Wilson
2011-02-01 17:34                                     ` Hugh Dickins
2011-02-01 17:46                                       ` Chris Wilson
2011-02-01 17:46                                       ` Jesse Barnes
2011-02-01 18:08                                         ` Jesse Barnes
2011-02-01 18:46                                           ` Hugh Dickins [this message]
2011-02-01 19:32                                             ` Jesse Barnes
2011-02-02  3:37                                               ` Hugh Dickins
2011-02-02 17:18                                                 ` Jesse Barnes
2011-02-08 19:52                                                   ` Hugh Dickins
2011-02-10 10:16                                                     ` [PATCH] drm/i915/tv: Use polling rather than interrupt-based hotplug Chris Wilson
2011-02-11  6:34                                                       ` Hugh Dickins
2011-02-11 18:21                                                     ` [PATCH] drm/i915: Suppress spurious vblank interrupts Mario Kleiner
2011-02-14 17:41                                                       ` Hugh Dickins
2011-06-18  4:40                                                         ` Hugh Dickins
2011-01-30  8:52                               ` [PATCH] drm/i915,agp/intel: Do not clear stolen entries Chris Clayton
2011-01-21 16:05             ` [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory" Jiri Olsa

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=AANLkTim4kL9OjBDiQQ1MBfOCzThxmDonBic11N45NKxj@mail.gmail.com \
    --to=hughd@google.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.kleiner@tuebingen.mpg.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.