linux-kernel - Re: [git pull] drm intel only fixes

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: <b7da2f$q4c60f@fmsmga001.fm.intel.com>
Date:	Wed, 12 Jan 2011 23:18:13 +0000
From:	Chris Wilson <chris@...is-wilson.co.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: [git pull] drm intel only fixes

On Wed, 12 Jan 2011 15:05:36 -0800, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Wed, Jan 12, 2011 at 2:40 PM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
> > Just the SNB machine?
> 
> No. I just checked. Reverting that commit on my other machine makes
> that TED video on my Core i5 machine look fine too.
> 
> So it's definitely the same bug on both Sandybridge and Core-i5 (I
> guess that's "Ironlake" in the crazy intel codename naming), just two
> slightly different symptoms. And I worried a bit that my bisect was
> bogus, but with the revert clearing it up on the other machine, I'm
> confident the bisect was good too.
> 
> On my sandybridge machine, the corruption happens already at the gdm
> login screen, which is why I used that one to bisect things. I'm
> including a (bad) photo taken with my cellphone of what the corruption
> looks like - see how the "sandybridge.linux-foundation.org" machine
> name text has been corrupted, and obviously my name (and the "e" in
> Other). And that blue rounded rectangle should contain "Log in as
> torvalds" or something like that, but instead it's clear.

Yes, that looks consistent with using the wrong relocation entry or GTT
offset within the batch.

Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
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/