linux-kernel - Re: [PATCH] drm/i915: Disable all outputs early, before KMS takeover

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] [day] [month] [year] [list]

Message-ID: <BANLkTi=JPoxZAq4YuWJF3P8MULuwTM9Taw@mail.gmail.com>
Date:	Tue, 5 Apr 2011 18:44:26 +0300
From:	Pekka Enberg <penberg@...nel.org>
To:	Chris Wilson <chris@...is-wilson.co.uk>
Cc:	intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	keith.packard@...el.com, danie.vettel@...ll.ch
Subject: Re: [PATCH] drm/i915: Disable all outputs early, before KMS takeover

On Tue, Apr 5, 2011 at 6:32 PM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
> On Tue, 5 Apr 2011 18:11:37 +0300, Pekka Enberg <penberg@...nel.org> wrote:
>> Hi Chris,
>>
>> On Tue, Apr 5, 2011 at 5:34 PM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
>> > If the outputs are active and continuing to access the GATT when we
>> > teardown the PTEs, then there is a potential for us to hang the GPU.
>> > The hang tends to be a PGTBL_ER with either an invalid host access or
>> > an invalid display plane fetch.
>> >
>> > v2: Reorder IRQ initialisation to defer until after GEM is setup.
>> >
>> > Reported-by: Pekka Enberg <penberg@...nel.org>
>> > Signed-off-by: Chris Wilson <chris@...is-wilson.co.uk>
>> > Tested-by: Daniel Vetter <daniel.vetter@...ll.ch> (855GM)
>>
>> I no longer get a blank screen after boot but flicker got more
>> aggressive during boot (it calms down after I've logged in). I see
>> tons of these in dmesg that don't appear with 2.6.39-rc1:
>
> Well the PGTBL_ER is still there. I'm thinking it might worth a check to
> see if that is asserted even before we start...
>
>> [   10.175843] [drm:intel_update_fbc],
>> [   10.183100] [drm:i915_driver_irq_handler], pipe A underrun
>> [   10.185085] [drm:i915_driver_irq_handler], pipe A underrun
>> [   10.186082] [drm:i915_driver_irq_handler], pipe A underrun
>> [   10.187087] [drm:i915_driver_irq_handler], pipe A underrun
>> [   10.189082] [drm:i915_driver_irq_handler], pipe A underrun
>> [   10.190085] [drm:i915_driver_irq_handler], pipe A underrun
>
> If I'm understanding the dmesg correctly, then these start even before we
> setup the first crtc.
>
> Whether that means we're not completely disabling all outputs or that we
> set a register incorrectly I don't know. Comparing an intel_reg_dumper
> with and without the patch applied might give a clue if it is a register
> that is set differently due to the reordering.
>
> The other question is of course whether you see those in 2.6.39-rc1 as
> well... Probably not since they will correspond with the increased
> flicker.

Actually, I do. I guess that logging is enabled by 'drm.debug=0xe'?
I've included dmesg from latest Linus master.

As for the v2 of the patch:

Tested-by: Pekka Enberg <penberg@...nel.org> (i915)

                        Pekka

Download attachment "dmesg.gz" of type "application/x-gzip" (29227 bytes)