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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKocOONWjaYLziXF6WKewqZ=bETwX898kWvGxHZq9N=OYpWQsg@mail.gmail.com>
Date:	Thu, 31 Jan 2013 09:47: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 Thu, Jan 31, 2013 at 9:05 AM, Deucher, Alexander
<Alexander.Deucher@....com> wrote:
>> -----Original Message-----
>> From: Shuah Khan [mailto:shuahkhan@...il.com]
>> Sent: Thursday, January 31, 2013 11:01 AM
>> To: Deucher, Alexander
>> Cc: Linus Torvalds; Linux Kernel Mailing List
>> Subject: Re: Linux 3.8-rc4
>>
>> On Thu, Jan 31, 2013 at 7:56 AM, Deucher, Alexander
>> <Alexander.Deucher@....com> wrote:
>> >> -----Original Message-----
>> >> From: Shuah Khan [mailto:shuahkhan@...il.com]
>> >> Sent: Wednesday, January 30, 2013 4:12 PM
>> >> To: Deucher, Alexander
>> >> Cc: Linus Torvalds; Linux Kernel Mailing List
>> >> Subject: Re: Linux 3.8-rc4
>> >>
>> >> On Wed, Jan 30, 2013 at 8:53 AM, Deucher, Alexander
>> >> <Alexander.Deucher@....com> wrote:
>> >> >> -----Original Message-----
>> >> >> From: Shuah Khan [mailto:shuahkhan@...il.com]
>> >> >> Sent: Wednesday, January 30, 2013 10:35 AM
>> >> >> To: Deucher, Alexander
>> >> >> Cc: Linus Torvalds; Linux Kernel Mailing List
>> >> >> 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?
>> >> >
>> >> > Does adding an additional radeon_mc_wait_for_idle(rdev) call at the
>> end
>> >> of rv515_mc_stop() help?  Can you find out what the minimum delay
>> >> required for your system is?
>> >> >
>> >> > Alex
>> >>
>> >> Adding radeon_mc_wait_for_idle(rdev) call at the end of
>> >> rv515_mc_stop() - didn't help.
>> >>
>> >> I tried with adding udelay() with delay values of 1,10, and 50, and
>> >> 100 at the end of rv515_mc_stop(). 100 is the minimum that fixed the
>> >> DMAR faults.
>> >
>> > I guess we can just add the delay.  I've tried all the ways I know of to get
>> proper feedback from the hardware.
>> >
>> > Alex
>> >
>>
>> Do you want me to send a patch with delay()? Would you like to see the
>> delay specific to this chipset which is RV620? That said if you think
>> of other ideas to try instead of delay, I can continue the debug and
>> testing effort.
>
> I'm planning to merge the attached patch.  I'll let you know if I found out any other things to try.
>
> Alex
>

Tested it on 3.8-rc5 - looks good.

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