linux-kernel - Re: Linux 3.8-rc4

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:	Wed, 30 Jan 2013 08:35:09 -0700
From:	Shuah Khan <shuahkhan@...il.com>
To:	"Deucher, Alexander" <Alexander.Deucher@....com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 3.8-rc4

On Wed, Jan 30, 2013 at 6:31 AM, Deucher, Alexander
<Alexander.Deucher@....com> wrote:

>>
>> ok. I did more debugging in rv515_mc_stop() and here is what's
>> happening. It has two display controllers and one of them is enabled
>> and the other is in disabled state when AVIVO_D1CRTC_CONTROL is
>> checked. The current code doesn't blank the disabled crtc. However, it
>> needs to be blanked to avoid DMAR faults it appears. I think that is
>> what the original code prior to
>> 6253e4c75d96006c06b9ac8f417eba873de2497b commit was doing:
>>
>> -       WREG32(R_0060E8_D1CRTC_UPDATE_LOCK, 1);
>> -       WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 1);
>> -       WREG32(R_006080_D1CRTC_CONTROL, 0);
>> -       WREG32(R_006880_D2CRTC_CONTROL, 0);
>> -       WREG32(R_0060E8_D1CRTC_UPDATE_LOCK, 0);
>> -       WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 0);
>> -       WREG32(R_000330_D1VGA_CONTROL, 0);
>> -       WREG32(R_000338_D2VGA_CONTROL, 0);
>>
>> Anyways, here is the diff for the change (by no means a patch) I made
>> that fixed the problem:
>
> Unfortunately, that just fixes the problem by causing an additional delay since the wait_for_vblank() and get_frame_count() loops will timeout since the secondary display is disabled.  The previous code disabled the displays completely while the new code just disables the memory request interface so that the display timing stays on to avoid additional flicker at startup or GPU reset.  For some reason on your system there seems to be a delay in getting the memory request interface to stop.
>
> Alex

Right. That makes sense and yes the annoying flicker went away. :) Can
you think of something that can address systems that would need more
time to get the memory request interface to stop such as mine?

-- Shuah
--
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/