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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.LSU.2.00.1102010909270.1586@sister.anvils>
Date:	Tue, 1 Feb 2011 09:34:12 -0800 (PST)
From:	Hugh Dickins <hughd@...gle.com>
To:	Chris Wilson <chris@...is-wilson.co.uk>
cc:	Mario Kleiner <mario.kleiner@...bingen.mpg.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

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.

So I don't yet have a lot of confidence that your patch will work out
better in the long run than what I tried at the weekend (when moving
do_intel_finish_page_flip's do_gettimeofday back into the work->event
block worked well until the evening).  If I had time, I'd experiment
further - but I don't have time, so I'll just keep running with your
patch to gather more confidence in it.

So far, so (fairly) good.

Thanks,
Hugh
--
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/