linux-kernel - Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 1 Feb 2011 09:46:43 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Chris Wilson <chris@...is-wilson.co.uk>,
	Mario Kleiner <mario.kleiner@...bingen.mpg.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

On Tue, 1 Feb 2011 09:34:12 -0800 (PST)
Hugh Dickins <hughd@...gle.com> wrote:

> On Mon, 31 Jan 2011, Chris Wilson wrote:
> 
> > Hugh Dickins found that characters in xterm were going missing and oft
> > delayed. Being the curious type, he managed to associate this with the
> > new high-precision vblank patches; disabling these he found, restored
> > the orderliness of his characters.
> > 
> > The oddness begins when one realised that Hugh was not using vblanks at
> > all on his system (fvwm and some xterms). Instead, all he had to go on
> > were warning of a pipe underrun, curiously enough at around 60Hz. He
> > poked and found that in addition to the underrun warning, the hardware
> > was flagging the start of a new frame, a vblank, which in turn was
> > kicking off the pending vblank processing code.
> > 
> > There is little we can do for the underruns on Hugh's machine, a
> > Crestline [965GM], which must have its FIFO watermarks set to 8.
> > However, we do not need to process the vblank if we know that they are
> > disabled...
> > 
> > Reported-by: Hugh Dickins <hughd@...gle.com>
> > Signed-off-by: Chris Wilson <chris@...is-wilson.co.uk>
> 
> Thanks a lot for devising this, Chris, I really appreciate it.
> 
> But so far I can't be more enthusiastic than "seems to be a good
> improvement most of the time" - though I've not spent long on this
> laptop since putting it on to -rc3.
> 
> I've not seen it go wrong on x86_64, but my first boot with it on
> i386 behaved just as badly as before; thereafter it's not gone wrong
> yet (and I had to double-check boot.omsg to make sure I'd really been
> running what I thought I was running the first time).  I'm relying
> upon it to type this mail, which I wouldn't have managed before.
> 
> As you know (I went off-list to send more info at the weekend), this
> behaviour is very elusive, probably depends on more than one issue,
> comes and goes with irrelevant patches and config changes and reboots.

Are you still seeing underruns during normal activity?  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).

If so, that may just be a red herring in this case.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/