linux-kernel - Re: [ 04/16] drm/i915: correctly order the ring init sequence

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:	Thu, 23 Aug 2012 10:10:18 +0200
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Herton Ronaldo Krzesinski <herton.krzesinski@...onical.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, Jani Nikula <jani.nikula@...el.com>,
	Yang Guang <guang.a.yang@...el.com>
Subject: Re: [ 04/16] drm/i915: correctly order the ring init sequence

On Thu, Aug 23, 2012 at 12:44 AM, Herton Ronaldo Krzesinski
<herton.krzesinski@...onical.com> wrote:
> Really sorry about this, but it was a hardware+bios setting problem
> here. I finished investigating what was happening here, and is related to
> the DRAM installed on this machine. The memory installed is DDR3-1333,
> and on bios it was configured as that, but turns out the chipset (G41)
> only supports up to DDR3-1066 (as on specs, although the motherboard
> lists the 1333 as supported, but as "OC", and allows configuring this
> way automatically or manually).
>
> After setting manually back to 1066, I stopped seeing all the weird
> behaviour, like the writes to the start address don't trigger anymore
> setting on the head offset. I'm sorry about that, and really it's a
> brown paper bag time for me :(. The machine worked fine and passed
> through memtest and never gave any problems, this was the first
> time (seems only the video device didn't like the memory setting, and
> the code change probably changed timing in the right way to pop up this
> now, also never had graphics corruption or other noticeable problems).
> I retested kernels that gave problems and they run fine now.

Well, at least we could clear this up.

Greg, please pick up the following patches for 3.0 (if you haven't already):

f01db988ef6f6c70a6cc36ee71e4a98a68901229 and
0d8957c8a90bbb5d34fab9a304459448a5131e06

Note that all kernels that need f01db backported also need
b7884eb45ec98c0d34c7f49005ae9d4b4b4e38f6 (to fix a regression
introduce by the former).

Thanks, Daniel
-- 
Daniel Vetter
daniel.vetter@...ll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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/