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]

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

On Fri, Feb 11, 2011 at 10:21 AM, Mario Kleiner
<mario.kleiner@...bingen.mpg.de> wrote:
> On Feb 8, 2011, at 8:52 PM, Hugh Dickins wrote:
>>  It appears that the
>> underruns, while mysterious and worrisome, have litte or nothing to do
>> with the unflushed text problem which is making 2.6.38-rc unusable.
>>
>> For the moment I've gone back to my patch moving intel_display.c's
>> do_gettimeofday() call into the block where it's needed; though that
>> too disappointed eventually before.  It all rather stinks of something
>> uninitialized somewhere.
>
> Just a remark, the do_gettimeofday() call is placed where it is (Before the
> spin_lock_irqsave() call for the event_lock), so that taking that timestamp
> (which is only needed later for some comparisons) isn't delayed by a
> possible blocking on that lock. Getting the timestamp as early as possible
> after entering that function is needed to make pageflip timestamping more
> robust.
>
> I'm puzzled why calling do_gettimeofday() could cause any harm, even if that
> code gets executed by accident. I stared at the code for a while and
> couldn't see missing initializations or similar. Maybe it would still make
> sense to try to get some ftrace's on how the code there executes, e.g.,
> which path does it actually take or if some piece of code takes an unusual
> and excessive amount of time to execute?

I'm sorry to say that I have now given up on this: it has already
consumed a lot more time than I can afford to give it.  So I've now
just turned CONFIG_DRM_I915_KMS off, which gives me a laptop on which
2.6.38-rc is usable.

If in due course there's a likely patch someone would like me to try,
that I can do.  And from time to time, with new kernels and with
upgraded userspace, I'll give I915_KMS a try again - indeed, for the
moment I still have it in my 64bit kernel.

Before switching KMS off, I did establish that, with Chris's overrun
fix, do_intel_finish_page_flip() - the function whose call to
do_gettimeofday() I moved - is no longer called at all.  So that
modification was just cargo-cult magic by now (though perhaps made a
difference to timings when overruns were happening), and there's no
reason to suspect Mario's vblank patch at all.  Let's assume that if I
attempted a fifth bisection, it would lead me to another (equally
blameless) patch.  Nobody else is complaining: maybe my 965 is broken
and just gets along better with 2.6.38 KMS off.

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/